We have lots of rules to follow in web design and development and we need to know which ones to break and when. Validation is one of the “rules” that I’m giving you permission to break, when you add ARIA to your applications.
I’m such a rebel (at least in my mind, I am)
I started teaching people about ARIA in 2006 at Web Directions South in Sydney Australia. I was delivering a full day workshop on building accessible web apps, and showed an example that essentially boiled down to this:
<span x2:role="role:checkbox" aaa:checked="true"> Include decorative fruit basket </span>
That’s a simplified version of a W3C example that used namespacing (that’s what the
x2: and the
aaa: are before the role and checked attributes). The syntax for ARIA has changed since then so that we no longer require namespacing. Today we’d end up with something a bit simpler like:
<span role=”checkbox” aria-checked="true"> Include decorative fruit basket </span>
I still use this example in my workshops today because it illustrates a number of great points—like, if you’re using
role=”checkbox” instead of a native checkbox, you’d better have a really good reason.
From the very first time I used that example, I had people saying to me: “but that won’t validate.”
What about validation?
They were right, you know. We should all be writing valid code. I suggested to them that they could break the rules for validation anyway.
“We require our code to be valid” they said.
Fantastic! This is exactly where we should be aiming.
I’m not exaggerating when I tell you that I had this very conversation with someone just last month in a full-day training session. I told them flat out, break the rules.
We’re not talking about throwing out all the rules here. I’m specifically talking about ARIA. ARIA adds programmatic accessibility where it just didn’t exist before. It allows us to programmatically specify what an interface component is beyond the collection of markup and CSS that it is comprised of. We can say “This is a slider” or “this is a tree” or this is a set of tabs (even though each them might be just a collection of
<span> elements). If you want more of a primer on ARIA, I wrote a brief primer in my article on A List Apart: ARIA and Progressive Enhancement.
Now then, you can add ARIA to HTML5 and you can even validate with some of the newer validation services. validator.nu and even the w3c’s validator have support for validation for HTML5 + ARIA (just remember, HTML5 and ARIA still aren’t completely specified and implemented yet, so there are quite likely some issues that may crop up when you’re validating).
But what if you’re not using HTML5 and your web app is HTML 4.01? or XHTML 1.0? Then what?
You can switch your DOCTYPE to HTML5 so that your app/documents are recognized as such, and would therefore allow ARIA’s role and other attributes to be valid.
Or—and this is where I get a bit crazy—you can just leave your DOCTYPE alone. Leave it as HTML 4.01. Leave it as XHTML 1.0. Add ARIA anyway. Break the rules.
Adding ARIA adds accessibility
Because the potential good that you’re creating by adding in accessibility like this outweighs the problems that are created by not having valid code because you added ARIA. What problems are created by adding ARIA’s role and other attributes to HTML 4.01 or XHTML 1.0 documents? Precisely none. Why not?
If a browser doesn’t understand an element or an attribute, it just ignores it.
The browsers ignore role and other ARIA attributes. Assistive technology such as screen readers that run on top of those browsers, use the ARIA attributes for good, not evil. It doesn’t matter if they’re using it with HTML5, HTML 4.01 or XHTML 1.0.
Use ARIA with whatever version of (X)HTML you’re using. Even if it doesn’t validate.
If breaking a rule like validation by adding ARIA means that your interface becomes more accessible then do it.
Yep, I’m a rebel.