My friend Nicolas Steenhout has published an article about the impossibility of specificity in accessibility recommendations.

It is excellent, and I strongly recommend reading it before continuing here.

The reason we often cannot be super specific has its roots in three areas:

• The web is a complex environment. Anything can be done in hundreds of different ways, depending on the underlying technologies, frameworks, and sometimes business constraints. Recommending the one straightforward HTML/CSS/sprinkle of JavaScript/server-side solution might be a specific answer, but not necessarily a good answer for the circumstances the page is in.
• Disabled people are not uniform. They have different needs depending on their disabilities but also based on their individual preferences. That’s why we, for example, argue to leave content interpretation to screen readers as much as possible instead of dictating how something is said. That also means, as Nic mentions in his article, that there are many, many combinations of tools that users use. And even if they use the same tools, the settings can be quite different.
• Technology is inaccessible, so making something accessible is more complicated than it should be. I researched combo boxes and selects for a client yesterday and saw <select>, <selectlist> and handmade ARIA combo boxes. Which of those you use, depends on your need. <select> is simple and covers many areas, <selectlist> will cover more functionality and finally allow us to style options (at the expense of not being supported in a shipping browser to date), so the complicated ARIA combo box it is. It is not something I want to recommend, but it depends on the need of the client to what solution is suitable.

Expectation management

Nic mentions that some client teams see this as bait-and-switch. We tell them there are clear, internationally agreed standards for testing accessibility, so they expect that for every issue there is a technique to meet the success criterion. Indeed, the W3C does provide a list of techniques to meet success criteria. And look at that, there are many ways to meet these criteria.

A two-sided expectation management needs to happen. First, clients need to be aware what their goals for accessibility are. Nic has a good, IMHO, bad example in his post:

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

What does “works well” mean? How well? Perfectly? What are the differences that are allowed?

I love making things easy to use for everyone as well. But that often makes the goal not a line, but a zone. Nobody knows if what they are doing is enough to meet the expectations, frequently their own expectations.

Concentrate on what is important and testable, so WCAG 2.2. There will still be enough wiggle room, but it is a goal you can work towards. It’s a minimum, but you can achieve more from a strong foundation.

And then you can move on and say, “OK, now let's make a list of screen reader interactions that we are unhappy with in the following screen readers and ask our users what they expect.” This gives you a list to work through and check off. Real concrete progress instead of mushy goals.

The other expectation that needs to be managed is especially critical when interacting with developers and designers. As outlined above, nothing is set in stone and frequently there are no simple good answers that work for you. You also might not have learned any of that “accessibility stuff” and now you’re responsible. We’re here to help. Tell us what you’re struggling with, and we can make sure to better explain and be more concrete for your individual situation.

Occasionally, the best way to help developers with their accessibility problem is to talk to project managers or designers and change the process to be easier to implement.

We’re partners in making a product accessible, and when we say “it depends”, we don’t mean “it is impossible to know”, but “let’s figure out how we can fix this most efficient, together”.