With the recent news that Microsoft Edge now has 100% accessibility support for HTML5, this post looks at what “accessibility supported” means, and where it fits into the bigger accessibility picture.
Accessibility comes in many forms and all of them are important. For the purposes of this post however, the term “accessibility” is used to mean the ability of an assistive technology like a speech recognition tool or screen magnifier to access content in the browser.
For a feature of HTML (or any other web technology) to be considered accessible, three things have to happen:
1. The browser must support the feature
This means that the browser recognises the feature and provides the expected visual rendering and/or behaviour. When the W3C releases a new version of HTML, it makes sure that each element, attribute and API is supported in at least two browsers. This gives developers a reasonable degree of confidence that the features of W3C HTML will work in the wild.
2. The browser must expose the feature to the platform accessibility API
This is what is meant by “browser accessibility support”. In addition to supporting a feature as described above, the browser must also expose information about the feature’s role, name, properties and states to the platform accessibility API.
The level of HTML5 accessibility support in popular browsers is tracked on html5accessibility.com. These are publicly available tests and results that are updated as new browser versions are released.
3. The assistive technology must obtain and use information about the feature using the platform accessibility API
When a feature is accessibility supported by the browser, the assistive technology must use the information exposed to the platform accessibility API. This information is used by assistive technologies in different ways – by a screen reader to tell someone what kind of feature they are using, or by a speech recognition tool to let someone target a particular object for example.
In other words the browser is responsible for supporting a feature and exposing it to the platform accessibility API, and the assistive technology is responsible for utilising that information to help people access content in the browser. If either the browser or the assistive technology do not fulfill their responsibilities, then accessibility support is not complete.
In practice this means that different combinations of browsers and assistive technologies offer different levels of accessibility support. For example, Edge now has 100% accessibility support for HTML5, and Narrator (the integrated Windows screen reader) takes full advantage of this – meaning that Edge is extremely usable with the Narrator screen reader. In contrast, other screen readers have yet to take advantage of the accessibility information exposed by Edge, and so for now that browser remains largely unusable with those products.
According to html5accessibility.com, Chrome, Firefox and Safari all expose less information about HTML5 than Edge. However most screen readers make good use of that information, so all three browsers are usable with screen readers on the relevant platform.
The goal is for all browsers to hit the 100% benchmark set by Edge, and for all assistive technologies to make full use of that information. When complete accessibility support becomes a given, people are then free to choose their browser and/or assistive technology based on features and capability instead.