Accessibility ‘Gaps’ in MVPs
A common refrain I see from companies is a variation of “Accessibility is a core principle!” They will include it in messaging, brag about their team, talk about how great this thing will be “for accessibility”.
Then they share an MVP or public beta or feature-behind-flags and it has few to no accessibility considerations. It falls down with a keyboard. It has awful contrast. It is exposed to accessibility APIs as a hole.
Point out this mismatch and you are told that you are dunking on the people. You become the buzzkill. You are the one making accessibility a chore by expecting the company to stand by its own promise.
Bait and Switch
This two-faced approach to accessibility from companies works great for them. They can claim to be focused on it, and then cast anyone who demonstrates otherwise as the villain. Nowhere does the company consider that the thing they proposed was fundamentally broken from the start. Built on a false promise and flawed premises.
Yet they go out and exclaim they are making a thing for accessibility, maybe even believing it. But never truly embracing it, staffing it, testing it, specifying it.
This harms the community as a whole. It makes those who rely on these products lose faith in the company. It makes the personalities who shill the features into unintentional liars. It makes accessibility look like a feature limiter. It makes practitioners look like bullies.
Bad Faith
Sarah Higley shared what I thought was a nice summary:
I think a good-faith example of a v0 thing is it lacking features, or still having bugs — even accessibility bugs.
A bad-faith “just isn’t ready” is a thing whose very design has fundamental unaddressed accessibility concerns.
Simply, if your MVP does not have accessibility factored in, it is not viable. If you claim accessibility is a core principle but your version 0 does not include it, then it is not a core principle.
Stop lying to us. Perhaps more importantly, stop lying to yourself.
This You?
This post is a meta post. It is not about any particular company or product. It represents the deep fatigue of more than two decades of watching the same bait and switch, claims of misunderstandings, assertions of hassling.
That being said, if this post offends you in some way then I guess it is about you.
5 Comments
Reply As a frontend dev who worked in those types of companies I think their internal culture should reflect what they tell publicly. I rarely see frontend folks being promoted or congratulated by their team lead for solving a11y problems, there is nothing to win if you invest time on this. So people won’t even try to spend time on this since it won’t help their career.
In response to . Reply I see your point. But is becoming a better developer/designer not worth investing the time? Accessibility is part of the medium, part of the web. It’s about quality.
Personally I think it is an easy excuse to ditch accessibility. Why do we need to care about accessibility? Not to get promoted or to get congratulated, but to make sure there is equal access.
Reply This situation can play out in some really toxic ways. I’m in an a11y QA team at a sizeable corporation. A product I was assessing was particularly bad and ultimately not fixable due to poor technology choices made by the dev teams. The solution was to change the technology, but the Tech Director was not going to admit they had made a mistake. However, they also had Senior Execs above them proclaiming that “accessibility is a core principle!”.
Caught in the middle, the Director turned back on the a11y QA team to try and discredit us with weird and wonderful lies, and blocking our reports from reaching the eyes of Product Owners. I sat in never ending meetings to challenge statements like “why should we follow WCAG? We should follow our own accessibility rules”. It ended up getting to truely corporate-psychopath levels of toxic behaviour. The product is launching inaccessible.
I guess this speaks more to the internal culture at my company but is perhaps a reminder that when a company launches an inaccessible product after declaring they are all about accessibility – there may have been an a11y caught in the middle trying to fight the good fight.
Reply As a design engineer, I’ve seen this Jekyll/Hyde scenario play out at a few places I’ve worked. I’ve always seen it as, Product and stakeholders don’t want to seem like bad guys so they say, Of course we want accessible apps – it’s the right thing to do! but when it comes to putting their money where their mouth is, We have a tight deadline and it’s OK to not release a final product – we’re agile! We’ll tackle accessibility in the next sprint/as part of tech debt (this never happens).
As an engineer, it’s often hard to know if a company truly cares about a11y or not. So much of it’s usually lip service. And I’ve tried to build accessible work, but it’s hard to do when a stakeholder’s demanding custom dropdowns and the like ASAP, a11y be damned. How do you navigate that?
In response to . Reply There is no single good answer to that question. It depends on the constraints of technology decisions, process, personalities, support, power dynamics, and so much more.
Sometimes it is a guerilla fight — identify accessibility bugs or fixes that map to a stakeholder directly but without noting them as accessibility fixes; create an “accessibility” tag in public repos and assign it; write CSS that relies on proper markup and/or ARIA use for states and properties; document WCAG violations in internal correspondence as a CYA for later leveraging when a complaint comes in (and, if it goes south, legal discovery); find an ally somewhere in the org; work questions into the interview process that can indicate if someone cares; etc.
Leave a Comment or Response