It is easy to make a basic web form, e-commerce site, or blog post accessible. But the web is largely becoming a space for arbitrarily-complex, fully-interactive applications. Today's web is full of products with:
- complex information architecture, with nuanced relationships between nodes communicated by position, spacing, boundaries and other visual cues
- real-time data updates that transform the document in arbitrarily complex ways
- screens where nearly every square inch is actionable, and these actions transform the document in arbitrarily complex ways
- controls that are not simply a button or text link, but regions full of structured content embedded within them.
- screens that respond to inputs in real-time in arbitrary complex ways
- rich graphics that eschew the traditional document model, with its established accessibility guidelines, altogether
To make such an application accessible requires:
1.) auditing all the visual cues, writing supplementary text if necessary, and adding the ARIA properties to communicate these cues
2.) communicating all document transformation to the user, either by navigating focus to the new content, or communicated to the user some other way. In the case of real-time updates, this also can't obstruct the normal usage of the site.
This is certainly possible at a small scale, but very hard to do consistently by an organization if engineers and designers on each product team don't have a solid understanding of how screen-readers work or the ARIA spec. It is also hard to have any quality control on this without having someone actually test every product on a screen reader.
Unfortunately, few engineers (and even fewer designers) have this expertise. Many years ago, I did a 12-week, 70-hour-a-week web development bootcamp, and, of those 800+ hours, exactly 0 hours and 0 minutes were spent on web accessibility. To be honest, I doubt the instructors even knew anything on the subject.
Sure, it would be easier to build an accessibility web by just simplifying product requirements. But I have had little-to-no success doing this as an IC engineer.
Turning an existing application into a accessible one is a huge issue, but only if it was built without accessibility in mind.
That is a bit like saying "todays applications do all sorts of potentially dangerous operations and need to be integrated with social media etc. Making all that secure is certainly possible at a small scale, but very hard to do consistently by an organization if engineers and designers on each product team don't have a solid understanding of IT security work or the OWASP top 10. It is also hard to have any quality control on this without having someone actually pen-testing every product."
Yes, accessibility is work. But not optional. If you build non-accessible websites you are just bad at your job.
I agree with you. But we’ve had decades to get better at accessibility, and yet it’s practically mostly worse today than with desktop apps in 1999.
A forcing function is needed. Those wheelchair ramps didn’t get built because architects and real estate developers thought it was fun and interesting.
I don't disagree, and I am not trying to argue that these laws aren't a good thing. But I'm also not sure the lawsuits are going to make a big difference.
My last company, despite facing an actual accessibility lawsuit, was willing to let all 3 of the engineers with the most accessibility expertise walk (including myself) rather than allow a long-term WFH policy.
- complex information architecture, with nuanced relationships between nodes communicated by position, spacing, boundaries and other visual cues
- real-time data updates that transform the document in arbitrarily complex ways
- screens where nearly every square inch is actionable, and these actions transform the document in arbitrarily complex ways
- controls that are not simply a button or text link, but regions full of structured content embedded within them.
- screens that respond to inputs in real-time in arbitrary complex ways
- rich graphics that eschew the traditional document model, with its established accessibility guidelines, altogether
To make such an application accessible requires:
1.) auditing all the visual cues, writing supplementary text if necessary, and adding the ARIA properties to communicate these cues
2.) communicating all document transformation to the user, either by navigating focus to the new content, or communicated to the user some other way. In the case of real-time updates, this also can't obstruct the normal usage of the site.
This is certainly possible at a small scale, but very hard to do consistently by an organization if engineers and designers on each product team don't have a solid understanding of how screen-readers work or the ARIA spec. It is also hard to have any quality control on this without having someone actually test every product on a screen reader.
Unfortunately, few engineers (and even fewer designers) have this expertise. Many years ago, I did a 12-week, 70-hour-a-week web development bootcamp, and, of those 800+ hours, exactly 0 hours and 0 minutes were spent on web accessibility. To be honest, I doubt the instructors even knew anything on the subject.
Sure, it would be easier to build an accessibility web by just simplifying product requirements. But I have had little-to-no success doing this as an IC engineer.