> Ultimately, a11y is so painful and costly for us to get right that it takes up a major chunk of our development efforts these days, and we all hate working on them.
Honestly, I expect this question would be difficult to answer in short time or without context. I think it'd be good discussion subject for a blog post. But: what are some examples of the pain and what would you change to simplify?
Not OP, but have done two large site UX overhauls in recent history, and my team/company takes accessibility _very_ seriously.
The biggest pain point for me has been the lack of a "Ground Truth" static-analysis-esque tool. We're provided some accessibility-issue-highlighting tooling, and there are some open source as well, but it's very common to get a11y tickets where the tool won't pick up the underlying issue, or will say "there's an issue" but not what the correct threshold is for fixing it (e.g. border contrast/density) so there's a bit of trial and error in there too.
If we had something similar to the "green squiggles" in IDEs, with, in my perfect world, the "right click->see suggestions ->auto-fix" flow that I can now get in code, addressing these issues would be SIGNIFICANTLY similar.
This is only one facet however, although it brushes against other issues in this space (inconsistent behavior of screen readers, occasionally not having sufficient specialized hardware to even test the scenario fully, often having to "negotiate" accessibility fixes with the designers who gave the original layouts, etc.)
Also, a final thing that I'm always curious is "just me" or not, but tab-ordering-fixes have seemed far more painful to handle (in dynamic/scalable layout scenarios) than I would have thought going in. The two options I know of for dealing with it are "assign the order" and "adjust your HTML/Z" layout, and the former is a very blunt hammer while the latter sometimes seems to be at odds with other requirements of the layout. (but this could very well be my naivete in frontend, thus this ramble)
Agreed. I've been happy to see aXe getting more visibility so it's easy to do at least the basic smoke testing similarly to other kinds of static analysis but it's definitely an area which is open for much greater improvement.
Getting things to be accessible (in practice: not just what some tool spits out in a report, but making the app/site useful to a real user with disabilities using a real browser of some sort) is not that bad as long as everyone's on board (if the designer wants everything drag & drop in red and green tones, you're kind of screwed).
Catering to screen readers is hard for the same reason supporting any non-60%+ user base browser is (uncommon mobile browsers, IE, whatever). All browsers have bugs and quirks, and having less eyes on things makes finding bugs hard. Debugging in a browser you don't use as frequently is always going to be significantly more challenging. When its not a "standard" one, it can be hell.
As another poster mentioned, a lot of the automated tools spit out a lot of false positives, and that adds to the burden.
Honestly, I expect this question would be difficult to answer in short time or without context. I think it'd be good discussion subject for a blog post. But: what are some examples of the pain and what would you change to simplify?