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

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

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 <div> and <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.

5 thoughts on “Knowing when to break the rules”

Read comments

  1. Mike Gifford says:

    I’ve been disappointed that existing validators have been so slow in adopting W3C standards like ARIA that are mature enough that they are providing benefits to users now. Although still not finalized, the changes being discussed for HTML5, ARIA & RDFa are pretty minor at this point.

    We’ve decided to launch our site with all three, simply because they work now and will be future compatible. Hopefully the validators will catch up, in the mean time I’ll post what work arounds I can find here in a Drupal discussion group.

    Thanks for posting this article. I definitely concur that it’s time to break the rules with validation, at least for now.

  2. Many people still seem to believe that if a page fails to validate it can’t be accessible, or even more dangerously that if a page validates it must be accessible. As you say, the aim should always be for validation if possible but there are good solidly grounded exceptions, and there are other examples of invalid code which have no impact at all on accessibility.

  3. John Faulds says:

    I’ve been doing exactly this for a little while now. Validation is a tool; if you know why your pages are invalid and know the consequences of including invalid markup, then there’s no problem.

  4. Brian Richwine says:

    WCAG 2.0 actually allows for pages not to validate when invalid markup is being used to increase functionality/accessibility. It must always be well formed, though!

    They did this knowing that the standards are slow to keep up with the technology.

    If a page validates except for the use of ARIA attributes, I read WCAG 2.0 to say that this is OK.

  5. I completely agree! It can be really hard for some people to accept this, as you know.

    One issue some people will bring up is that with all those ARIA “errors” mixed in, it can be a lot harder to pick out the real errors, which is one of the purposes of validation. This is a good point, I think. But I still think the developer’s extra work of having to weed through ARIA errors is worth the users’ accessibility benefit of adding ARIA.

Hi there! We've closed the comments after a week of spirited discussion on this post. If there's something we've missed, please reach out and let us know.