Short Note on ARIA, Dragon and Standards
— Denis Boudreau (@dboudreau) November 16, 2013
Accessibility is a social contract
Accessibility advocates ask developers and browser vendors to do their part to make HTML content accessible. A technological framework for this is provided via web standards including: HTML, WAI-ARIA and WCAG. If Assistive Technology vendors do not work with developers and browser vendors by making use of the information provided through standardized interfaces for making HTML content accessible, it’s the user that gets screwed, but not by the developer or the browser vendor as they are fulfilling their part of the social contract.
A Misunderstanding of ARIA
ARIA is a tool that allows developers to represent the role, states and properties of HTML content in accessibility APIs. It is the job of browser to support the connections between an ARIA attribute and it’s representation in an accessibility API (and browsers implementers have stepped up). It is the job of the developer to add the ARIA attributes (and scripted behaviour) to HTML when they build custom controls. It is the job of an assistive technology to make use of these standard platform accessibility APIs to convey information about content to users. The three parties involved: developer, browser and assistive tech all have a responsibility. If developers and browsers fulfill their responsibilities by coding and exposing the information according to web standards, it is incumbent on the assistive technology to make use of this information, otherwise their users suffer.
Requirements on applications as per the Section 508 refresh (503.3 is relevant to Dragon):
503.3 Alternative User Interfaces. Where an application provides an alternative user interface that functions as assistive technology, the application shall use platform and other industry standard accessibility services to provide the alternate user interface. [emphasis mine]