The Section 508 Refresh contains a provision that places responsibility on assistive technology vendors to make use of accessibility information made available via platform accessibility APIs. I suggest this is a very good thing.
Level playing field
In our shared quest to provide user interfaces that are usable by all, accessibility practitioners (such as myself) have an expectation that developers (those who build the web) and browser vendors (those that provide access to the content of the web) will build their products according to agreed standards and guidelines. If they do not then their products will be unusable by some. None of the current standards relating to accessibility appear to place any responsibility on assistive technology vendors to ensure that their products use the agreed and implemented standards, I suggest that this is a very bad thing and does not serve users well. The Section 508 refresh includes a provision to remedy this imbalance of responsibility. We cannot continue to ask much of developers and browser vendors without assistive technology vendors doing their part.
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.
An example
Developers code a control and label it, using a method initially defined in HTML 4.1 (1999). i.e. it has been a conforming standard method for 15 years. They have done the right thing.
<label>email <input type="text"></label>Browsers have implemented accessibility support for this method. The accessible name for the input element in the example is exposed by browsers via platform accessibility APIs. In testing conducted in 2012, all browsers that implemented accessibility support exposed the information correctly. They have done the right thing.
All of the assistive technology tested announced the correct label text. They have done the right thing.
Buggy is buggy regardless of source – no free pass
Browser vendors who do not implement standardized accessibility support and developers who do not code for accessibility are called out (regularly). Assistive technology vendors whose products do not convey information to users, provided using standardized coding patterns and exposed via standardized accessibility interfaces, are broken and must be fixed. They are doing the wrong thing.
Comments
+100 to that! At Mozilla, we’re striving to make all the info available via a11y platform APIs, and encourage AT vendors to use those platform APIs instead of getting at what we call the iSimpleDOM to do their own HTML interpretation. I also wrote a blog post to that effect called Why Accessibility APIs Matter, which I stand by firmly even two years after it was written.
I agree with this post. I have been blind a little over 12 years and I just received a bachelors degree in CIS specializing in web development and administration. I am new to the whole web accessibility field, from the coding side anyways. From the reading I have done it looks like the standards are there on the browser side of things but there seems to be no real standards on the assistive tech side. It seems like the screen readers can do things just any way they choose. This is bad because it makes it so much harder for developers to make their content accessible on multiple platforms. It also seems to be a major component in sighted developers to not even want to try most times.
In general, I totally agree. We have always strived to ensure that NVDA uses information exposed from accessibility APIs above all else. Furthermore, you seem to imply that AT vendors are not called out for bugs in accessibility API support. I disagree, at least as far as NVDA is concerned. We receive a fairly constant stream of bug reports and do our best to address them.
This article also completely fails to take into account that it’s nowhere near as simple as just taking what an accessibility API exposes and throwing it at the user. If it were that simple, my job would be a great deal easier. 🙂 A great example of this is the continuing controversy regarding how to handle aria-label(ledby). It is exposed as the “name” by most accessibility APIs, but how should an AT handle it? Should it override the content, extend the content or be ignored? In order to satisfy what authors generally expect and use cases currently in the wild, there is no single answer to this question. It depends on what the element is (control, landmark, container, etc.), how the user is currently navigating, etc. No specification addresses this, despite the fact that many seem to believe that ATs are violating some specification when ATs fail to do what the author expects in a particular case, even when doing so would break other use cases where other authors expected a different result.
Hi James,
I guess this is why NVDA and Firefox is such a powerful combination.
I suggest that NVDA is unique among AT vendors, for example you have an open bug tracker and work openly with browser implementers, web developers and users, to improve NVDA.
I agree, I wrote with a broad brush and used a simple example, but it is the case that some AT’s do not support even relatively simple, long standardized features of HTML even though the information about the feature is exposed interoperably via accessibility APIs.
Myself and others have been working on defining what information is exposed as an accessible name for HTML elements, your feedback on this would be much appreciated.