Accessibility-specific tech requirements? It depends!

There are so many "moving parts" to accessibility that it's hard to define specific technical requirements.

One of the folks I work with has ongoing frustration with accessibility findings. They think we're changing the rule of the game all the time.

Sketch by Nic Steenhout. All rights reserved.

One answer that seems particularly aggravating to them is "this solution doesn't work across all assistive technologies".

This relates in some way to what I was talking about in “Accessibility is a continuum”.

Accessibility specifics

They want specifics.

The reality is that very few digital accessibility outfits test using all combinations of assistive technologies. In fact, it seems pretty standard in the industry to audit using NVDA/Chrome, and not touch Jaws. Sometimes test with VoiceOver. Very few test using speech input.

It would be impossible to test using all combinations of assistive technologies. Heck! Even testing with NVDA, it would be impossible to test the way all disabled end users are relying on NVDA - every single individual uses their assistive technology differently. It depends on their level of experience. And their preferences.

And this is just the same as everyone else. Try using your colleague's computer. I bet you'll find it's setup differently. Apps and files located in different places. Setting changed from what you like.

So when we're asked for specifics, it can be really hard to give them.

And it's understandably super frustrating for the team on the receiving end of this. I was told:

"Again, we come back to the problem of trying to understand exactly what criteria we're trying to meet. We should specify explicitly what assistive technologies, and if they are in scope for our product".

Working to the standards

Sometimes it feels like the only thing we can do is to say "work to the standards", where we mean the Web Content Accessibility Guidelines (WCAG). But even that is a frustrating answer for many people, because there aren't that many binary answers here. Some things are clear fails - like not having an alt attribute on an img element. Other things are less clear - like the quality of the alternate text on an image. And this is just on the very first Success Criteria of the guideline. There are 56 Level AA Success Criteria in WCAG 2.2. That level of WCAG is typically what organizations are trying to conform to, rather than also looking at the 31 Level AAA Success Criteria.

When you also consider the complexity of the variety of mix of assistive technologies into this... It becomes very hard to define specific and definitive answers sometimes.

Minimum requirements?

As an organization, you can (and should) define minimum requirements. Like "we must meet WCAG 2.2. AA, and we must make sure what we build works well in NVDA with Chrome, VoiceOver with Safari on both MacOS and iOS, and TalkBack on Android". But even that isn't clear cut! As I said earlier, WCAG is complex. And the way the assistive software is setup will impact behavior and interactions with websites and applications. And then there's different versions of the app - not everyone upgrades their screen readers immediately to the latest version.

In the end, it depends

Sooo, yeah. I actually don't know how to give specifics sometimes. I know my typical answer of "It Depends" isn't satisfactory. But it's the reality of so much of what we do in accessibility.

How would YOU answer such requests for specifics?