HTML5 Accessibility Chops: ARIA & validation

Posted on Thursday, 2 June 2011 by Steve Faulkner

I tweeted the other day, suggesting people switch to the HTML5 doctype as the use of ARIA is conforming in HTML5. As things stand, if ARIA roles, states and properties are used on HTML elements with a doctype other than <!DOCTYPE html> a developer will get unhelpful error messages when using an HTML validator simply because the DOCTYPE they are using does not recognise ARIA attributes as valid. This is not likely to change. So make the switch!

FUD error messages

Using ARIA with any flavour of HTML works equally well. It does not make one iota of difference to ARIA support in browsers or assistive technology, whether you use:

this HTML 4.01 doctype

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

or this XHTML 1.0 strict doctype

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

or this HTML5 doctype

<!DOCTYPE html>

at the top of your <html lang="en"> file. What using a DOCTYPE other than the HTML5 doctype will do is cause you much pain and consternation if you run your code through the W3C HTML validator, as you will get an error reported for each use of an ARIA attribute. You will not be told whether your use of the ARIA attribute in a given context is correct or whether the value you are using for a particular attribute is incorrect, you will only be told that it is an error… pretty useless.

The following are both reported as errors when checked against HTML 4, not helpful since one is not a specified  role value and the other is.

<div role="dribble">

<div role="main">

The HTML 4.0 error message:

there is no attribute “ROLE”

Now if the HTML5 doctype is used the results are much more useful:

Bad value dribble for attribute role on element div.

If a developer is using ARIA to improve the accessibility of the HTML content and interaction she wants to know whether she is using ARIA in a way which works, not that, due to the archane rules of doctypes, she is not allowed to use it.

Work in progress

Be aware that none of the available HTML5 conformance checkers have a fully implemented or up to date set of ARIA conformance rules, so you may get some funky results. If you do Please report any bugs you find.

Like much of HTML5, the implementation of conformance checking is a work in progress and there is still much to do. This work is being done by Henri Sivonen and Mike tm Smith, their collective efforts can be tested on the Nu Markup Validation Service.

Sting in the tail

If you use attributes such as summary or longdesc, while these are valid in HTML <5 and XHTML , they are currently obsoleted in HTML5,

For example, if you have an image such as this:

<img src="bit.jpg" alt="poot" longdesc="pooter">

you will get an unhelpful error message, rather than being informed that the longdesc value is incorrect as it needs to be an URL:

The longdesc attribute on the img element is obsolete. Use a regular a element to link to the description.

Like ARIA attributes in HTML 4, obsoleted attributes still work in browsers and AT when using the HTML5 doctype, you just get told not to use them, rather than whether you are using them so they will work.


About Steve Faulkner

Steve is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at Vision Australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C HTML Working Group and the W3C Protocols and Formats Working Group. He is an editor of several specifications at the W3C including HTML 5.1, Using WAI-ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility

Comments

Comments for this post are closed.

Recent Posts

See all posts in the blog archive

Thanks for all your help. Your people are solving problems that we thought were unsolvable months ago. Other companies we called upon just kept telling us to “dumb down” the site and we were ready to do so until we worked with TPG.

Ken Isaacson, Vice President, Major League Baseball Advanced Media