Based on current estimates, HTML 5 will not become an official standard until 2022 (not a typo). However, browsers are expected to support most of it long before then. This is quite fortunate from an accessibility standpoint, as HTML 5 fixes or erodes a lot of the major accessibility barriers that disabled web users currently face. But what’s even better is that web authors won’t have to do anything extra to enable most of this added accessibility. It will come standard with the proper use of HTML 5.

Let me be clear, there will still be a need for ARIA, and most of the web accessibility best practices won’t be going anywhere anytime soon, but it seems likely that web authors will have fewer things to worry about when it comes to accessibility, and web sites that weren’t designed with accessibility in mind will be more likely to just work.

Here are some of the immediately obvious benefits to accessibility that HTML 5 will bring.

The ContentEditable Attribute

This attribute allows one to make the contents of a particular tag editable, also known as “edit-in-place”. This attribute is already supported in many browsers, and it seems to work well with Jaws. When taken together with the fact that I can’t recall ever seeing an edit-in-place implementation using JavaScript that was accessible, I recommend using the contenteditable attribute as soon as it becomes practical to do so.

The Header, Footer, Nav, Section, Article, and Aside Tags

It recently became possible for web authors, via the use of a span tag and ARIA landmark roles, to tell disabled users “this section of the document is the header,” or “this section is for navigation.” Before that, we had to use clunky “skip to XXX” links. Now, if you wrap the various parts of your page in header, article, and similar tags, you should get the same functionality that the ARIA landmark roles give, but for free, without any extra effort on the part of the web author beyond writing semantically correct HTML (I.E. not wrapping the footer of a page in a header tag). And, as has been seen time and time again, free accessibility tends to be widely implemented accessibility.

SVG Support

While SVG is currently supported by many browsers, HTML 5 broadens that support. The reason SVG support is good for accessibility is that SVG images are vector images (meaning that they are mathematically defined), and so they can theoretically scale infinitely without a loss of quality. This is important for those who use magnification, as these folks often view web pages enlarged up to 16 times or more, which can obviously make typical images for the web look terrible.

Audio and Video Elements

With apologies to the fine folks at Adobe who are doing a lot of great work on accessibility, the sooner flash audio and video players are gone from the web, the better it will be for accessibility. Yes, such players can be made reasonably accessible, but the fact is that most aren’t. I’m convinced, based on past experience, that if we can move the player logic out of a browser plug-in and into the browser itself, we adaptive tech users will have a much better shot at being able to access it.

Drag and Drop

This is also something which I can’t recall ever seeing implemented accessibly. However, it is likely that if this logic can be handled directly by the browser, and not by a JavaScript hack, then screen reader manufacturers will have a pretty good chance of being able to make it accessible via the browser’s API.

Advanced Form Features

HTML 5 will support some new types of form controls (like date/time pickers, sliders, and so on) and will also add new functionality to the traditional form controls (such as autocomplete and client-side validation). These have traditionally been implemented in JavaScript, with varying levels of accessibility (usually poorer than not). However, here again, we have a situation where moving this logic into the browser will make things much more consistent from site to site, and thereby enable screen readers to provide access.

Conclusion

In case you haven’t noticed, the theme here is consistency. The problem with making (for example) autocompletion work with JavaScript is that everyone does it differently. The browser doesn’t know, hence the adaptive technology doesn’t know, that your form field uses autocompletion. At best, it simply knows that we have a text entry field with some JavaScript attached to onchange events. So, since the screen reader doesn’t know that the field offers autocompletion functionality, it doesn’t know that it should present anything differently to the user.

A historical parallel for all this is layout tables. Several years ago, everyone was using tables for layout, because the technology of the time didn’t offer any good alternative. But then CSS came along and layout tables became (for the most part) obsolete. This change was of course a big boon to disabled users, because then a table could go back to just being a table, and there is now much less confusion for screen reader users. With HTML 5, we should see similar advancements, where more elements will be used for their intended purposes.