💾 Archived View for sporiff.dev › 2022 › 11 › 28 › a11y captured on 2024-08-31 at 11:42:28. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-08-18)
-=-=-=-=-=-=-
Posted on 2022-11-28
There's been a bit of chatter on the Fediverse lately about a quote from post.social's CEO. The quote reads:
Focus is what you are not doing - this means that we are not focused on things like dark mode, iOS/Android apps, DM's, private accounts, power user tools (managing large follower base), activity pub [sic], accessibility, video (you can embed 3rd party players like Youtube for now) etc. We want to do it all but first, let's get everyone in.
This message is troubling. To be clear, I don't think that Post's designers haven't considered accessibility in their designs. They're probably tearing their hair out at this announcement. But the optics of the CEO of a company saying that accessibility isn't something the company is focusing on "first" are very poor.
It goes without saying that accessibility in design is extremely difficult. So many different ability sets need to be taken into account and so many tools need to be provided. At a base level, all UI designs must follow web accessibility guidelines, all UX copy must follow best practice, and all tools must be considered for assistive technologies. This is a huge overhead, so it's unsurprising when startups feel like they can't focus on it while building their core offering for the market.
Here's the thing though: accessibility design doesn't get easier the longer you leave it. It will only ever get harder to implement as time goes on. As you build new tools and features, you are adding to a growing list of things to backport accessibility design into. Saying that you will "prioritise it later" shows a staggering lack of understanding, and possibly even a modicum of contempt for disabled users who want to use what you make.
I speak from some experience. In my life, I've worked on a few different software and documentation projects which all suffered from some kind of accessibility setbacks. Funkwhale is a really good example of this. The project was built initially by a single person who was still learning web design. As such, accessibility wasn't built in from the start. When we had our accessibility audit we were given a few easy things to fix such as aria labeling and improved contrast ratios, but it was clear from user feedback that the entire interface and UX need to be built again to make them properly accessible.
In documentation, accessibility comes down to web design and to proper use of semantic HTML. The number of times I've picked colleagues up for breaking convention by skipping headers, using formatting incorrectly, or not using the proper markup for semantic HTML is too high to count. These things matter, particularly when you're considering people who use text as their primary means of communication. No, not everything can be a video or a series of screenshots. This is accessibility thinking, and it increases your workload enormously.
Yes.
To expand on this a bit, it is never worth leaving someone out of your product for something as solvable as accessibility design. You, as a platform holder or tool designer, have a responsibility to enable everyone to use what you build. It's going to be tough, especially if you didn't start the project thinking of your design patterns. The sooner you start, the easier it will be.