London Web Standards is pleased to present a guest blog post from Sandi Wassmer.

Over the past few weeks, I have been asked the same question several times, albeit in a few different guises, but what it boils down to is this:

Is HTML5 accessible?

Apart from the fact that no specification as such, can be deemed accessible or not, what has become evident is that there seems to be a rapid proliferation within the web design and development community of the misnomer that if you build a website using HTML5, it somehow becomes uber-auto-accessible. Although this would be a fabulous feat and the specification is certainly providing a fantastic foundation for accessibility through the inclusion of native functionality that has previously been the domain of 3rd party technologies or has simply not been achievable without considerable tweaking, we need to stop this situation from getting out of hand before it in any way tarnishes the existing and future fabulousity of HTML5.

As with all emerging technologies under development, encouraging early adoption and garnering community support are essential to its success, but of equal importance is a responsibility for these early adopters to understand both the possibilities and the limitations of the technology and to work in a spirit of open learning, knowledge sharing and understanding.

W3C Specifications are inherently accommodating and flexible in that they allow anyone to participate in their development, but no claims can be made about their fundamental performance. The quality of the code and its impact on a site’s accessibility are the responsibility of the developers and designers using these specifications appropriately, incorporating best practices, guidelines, like the WCAG, and ensuring appropriate user engagement and testing are undertaken. And as the use of other specifications and programming languages are required to build the complex dynamic websites that are now the norm, HTML5 is not standalone.

And so it follows that accessibility is not just about front-end code. It is also about good design and giving consideration to how a website’s users interact with the UI overall, as well as each discrete feature, and how the front-end interprets and handles the data that is output from the back-end. As all of these additional considerations are outside of the scope of HTML5, I am concerned that these are in danger of falling through the cracks if people think that HTML5 on its own provides a singular route to accessibility conformance.

But that’s not all. In addition to this, although all modern browsers currently provide a reasonable level of support for some of the important HTML5 features – such as the new semantic elements, HTML5 forms, Canvas, and other APIs – there are considerable workarounds required for certain features to work in IE8 and below, and for other browsers and devices that don’t support the use of certain technologies, such as JavaScript and Flash.

So, what does this all mean for jobbing designers and developers? Well, it is simply a case of “Whoa Nelly!”. Although HTML5 is pretty groovy in my books, it alone does not ensure accessibility, and we need to consider all of the factors that influence and contribute to it.

You didn’t really think it was going to be that easy now, did you?

Sandi Wassmer

Sandi Wassmer is the Managing Director and Co-Founder of Copious, a digital agency specialising in building Inclusive Websites and is leading the move to integrating great design, accessibility, usability, web standards, user experience and other best practices under the umbrella of Inclusive Design.

Sandi is a regular public speaker and has presented right here at London Web Standards, as well as other key industry events, such as @media and Future of Web Design. She is also involved in a variety of advocacy activities, including writing a weekly blog for Action for Blind People and participation in the UK Government’s eAccessibility Forum.

In my opinion HTML5 makes it easier to write accessible pages. ARIA validates; there are more semantics available; <details>, the native disclosure widget, native widgets such as the new form input types and native video are all potentially built-in rather than bolt-on accessibility.

But the author still has to know what he or she is doing. The HTML5 tools are more sophisticated than the HTML4 tools, but you still need to know which tool to employ and how to do it to make a quality product.

Using <canvas> for everything, for example, when SVG would be better is a fine example of someone mis-using a tool.