WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Why was software (user agents and authoring tools) left out of the recent SANPRM for the ADA by the DOJ?

for

From: Brooks Newton
Date: May 19, 2016 12:38PM

Hi Jonathan,

I think we are on the same sheet here. It makes perfect sense to move any and all responsibilities for accessibility from site owners to software, if and when the software can handle the responsibility consistently and effectively. Why depend on individual site owners and their production staff to do these things accessibly, when the tasks can be handled in a centralized, standardized accessible fashion through the operating system, user agent and/or assistive technology. I just re-read the UAAG 2.0 this week, which is available at https://www.w3.org/TR/UAAG20/ . This is a brilliantly crafted document, which assigns several accessibility tasks to the user agent that have previously been the responsibility of site owners / developers. Features the UAAG recommends as built-in functionality of browsers include things like form submission confirmation, a mechanism to avoid keyboard traps, capacity to zoom page content (as you mentioned), as well as other features such as user agent settings that disable media that plays automatically on page load. UAAG 2.0 also recommends that user agents provide some functionality that has previously been relegated to assistive technology, such as the capacity to traverse content via structural markup. If I've gotten this wrong W3C folks, please advise. I agree with Sharron Rush's earlier post that policymakers need to consider incorporating parts of the UAAG and ATAG into our laws and regulations. Good call, Sharron. I'm going to re-read ATAG 2.0 this weekend. https://www.w3.org/TR/ATAG20/

All of the user agent features I mentioned earlier complement or even replace requirements that have previously been in the content owner's bucket of accessibility responsibilities. That's cool by me. Let the software do what it does best. I'm sure this kind innovation through automation is a welcome source of support that content owners, designers and developers need. Just as we as accessibility practitioners should encourage a shift from hand review to machine review for issues that software handles accurately on a consistent basis, so to should we be accepting and encouraging of centralized software handling some of the heavy lifting that had previously been relegated to meticulous and fallible custom coding by site developers.

If we are in fact going to rely upon user agents and other forms of software to take over some of the accessibility responsibilities that we have long served up on site owners plates, then we need some type of formal assurance that the software manufacturers recognize this shift and accept the responsibility. In my opinion, that means there needs to be a shared legal responsibility between content owners and the software that allows the Web work for all of us. It's time we consider regulating some of the critical accessibility functions we are asking software to handle. This will free up developers to focus on accessibility responsibilities that software alone cannot yet handle. It will also give site owners the assurance that their money spent on accessibility fixes/features won't be wasted because the software isn't holding up its end of the bargain. Any content owners out there agree? Have I angered OS/UA/AT software developers past the point of return? What are your thoughts and concerns?

Last note in this post: I think my favorite Success Criterion in UAAG 2.0 is S.C. 4.1.2, Expose Accessible Properties - Here's the UAAG reference for this Success Criteria - https://www.w3.org/TR/2015/NOTE-UAAG20-Reference-20151215/#sc_412

If we could put browser manufacturers on the hook for honoring accessibility markup consistently, it would go a long way in giving site owners, designers and developers the support they need to build-out our online future accessibly. At the present, an awful lot of well-intentioned WAI-ARIA code goes unrecognized or improperly rendered by user agents, and is thus worthless in making advanced content accessible now. Actually, it is worse than worthless. If we were all honest with ourselves and with our clients, we would recommend presenting certain content in a simplified, old school HTML way instead of encouraging site owners to use newfangled, sporadically supported WAI-ARIA markup instead. How nice will it be when all of our elegant, cleanly coded recommended accessibility fixes actually work? In other words, I seriously look forward to a time when site content has a real chance to meet performance objectives versus achieving mere compliance with a technical standard...compliance that in no way guarantees actual access to users who live with disabilities that impact Web / mobile browsing. Holding software accountable for some of the accessibility responsibilities will take us a long way toward the goal of actual versus theoretical accessibility.

Over and Out,

Brooks Newton