(X)HTML and ARIA validation – practical results vs. purity win?

If your (X)HTML is valid and your ARIA is valid, your document is valid, so don’t worry about it. No harm, no foul.

Jared Smith, from WebAim, posted his excellent slides on the accessibility of Rich Internet Applications presented at Accessing Higher Ground Conference. In them he maintains that if your (X)HTML is valid and your ARIA is valid then you need not worry about passing validation tools which currently have varying or no support.

This poses problems for developers who want to validate their code whilst making pages as accessible as possible. As Mathew Smith (@smithytech) commented:

I’ve been retro-fitting the ARIA stuff with JavaScript to get round the validation problem. Best not to care about validation?

John Foliot’s pragmatic response was:

@smiffy problem is that the validators aren’t wired for ARIA, but removing ARIA for validation is worse. Practical results vs. purity = win!

The Mighty Steve Faulkner has already gone into detail about this in how can I validate (X)HTML and ARIA so I wont repeat what’s been expertly covered but I’m curious to know what this means to you: working on websites in the real world how does this impact your design decisions and code choices? Does validation go out the window or does pragmatism prevail?

(Twitter is lovely but useless at tracking threads – if you have comments why not be old skool and leave a comment here).

27 thoughts on “(X)HTML and ARIA validation – practical results vs. purity win?

  1. My two bits here – The problem lies not in the developer or the accessibility consultant, over the years it is “We” who have told our clients that look for valid code. Now this has become a noose around our necks at times.

    For clients, its easy to be rest assured of the work that is being delivered and now we need to somewhere balance this for them!

  2. As a screenreader-using developer I want code that’s as close to valid and as close to accessible as humanly possible. I guess I’d sell this to clients by committing to write valid code and then add lots of lovely accessibility extras which, although technically will break the validation, will still result in clean, well-formed, accessible code that’ll meet (exceed?) user expectations. Would that be a convincing argument?

  3. Yes, Accessibility > Compliance.

    I’d violate Level A WCAG requirements, use 10 level deep tables, and use the most ugly, non-compliant HTML you’ve ever seen if it resulted in a better experience for real users. Fortunately, I don’t have to (most the time). Our current site uses one line of invalid CSS to get around IE’s hasLayout navigation bug. Whoop-dee-frickin-doo. Yet people call us out on it all the time.

    This issue with ARIA, as has been pointed out, is really a validator issue, not a standards issue. The biggest problem with implementing ARIA now is all the e-mails we get from ignorants about the code supposedly being invalid.

  4. Accessibility for sure… I try to reach nirvana with both. Accessibility & purity, but if I have to sacrifice one, it would be valid code before I even thought about sacrificing accessibility options.

  5. It seems that to some I’ve painted myself into a corner (although I would disagree LOL). I’ve long argued for code validation (http://john.foliot.ca/are-we-still-arguing-about-validation/), in fact even advocating for draconian results of invalid code (for which folks like Mark Pilgrim have condemned me – no matter). To be very, very clear, validation is important – it is our best shot at interoperability, accessibility, internationalization and more.

    But our industry moves at a very rapid rate, whilst standards wrangling is a slow (painfully so) process that requires that numerous voices have their say, and that everyone who has a horse in any given race has a chance at the speakers queue.

    Which brings us to ARIA, an emergent specification that has been in the making for nearly a decade (yes, almost 10 years!) which bridges inaccessible ‘dynamic’ HTML for users of Adaptive Technology. While it is still not an official specification at this writing, it is relatively stable, being implemented by all the major browsers now, incorporated in the leading JavaScript libraries and being added by advanced, caring web developers today, and is over-all quite usable to the majority users of Adaptive Technology who keep their software up-to-date. But to use all this goodness, you must create documents that do not meet a ‘technical’, mechanical parsing of your code base. To create valid web pages today, you must omit all of this great stuff, simply because no single validator today will ‘forgive’ the use of an advanced technology that was created after the HTML 4 / XHTML 1 specification was written. It’s not really hard to see where this is a situation which is truly unintended, but harmful in the grander scheme of things.

    So… Creating valid code, and then adding newer technologies such as ARIA on top of the code benefits more than it hurts, because invalid code doesn’t hurt anyone – at least, not invalid in this sense – whilst *not* adding ARIA is a demonstrable fail that need not be.

  6. There’s a difference between technically invalid, and catastrophically invalid code. Chucking a few ARIA attributes on top of your perfectly valid code isn’t going to break anything except the validator.

    If you’ve got a tag soup nightmare to begin with though, you should probably head for the nearest validator armed with a strong coffee and plenty of time to fix things.

  7. Pingback: mpaciello (Mike Paciello)

  8. Pingback: jared_w_smith (Jared Smith)

  9. Thanks for stimulating the discussion. I agree validation is a tool not an end in itself as the previous comments have oulined well. As mentioned, sometimes it is better from an accessibility perspective not get too worried that a pages does not fully pass according to an online testing tool, the whole ARIA story being the most striking example. As we know, the requirement for valid code is an advisory technique under WCAG 2.0 – the aim of ‘Robust’ is to make sure your stuff works with different devices and certainly in many cases the use of valid code is likely to increase the likelihood of this happening, but not always.

  10. Pingback: johnfoliot (John Foliot)

  11. Successful validation (a green checkmark) is somthing that is easily understood by every customer once you have convinced him that standard compliance really matters. So the issue in fact is the lacking support of current validators. But how can we encourage and help the authors of validators to support ARIA with their tools?
    The Firefox add-on HTML Validator by Marc Gueury is my favorite tool. Unfortunately it still lacks support for ARIA as well as for HTML5. Would love to see both included, even if optional.

  12. So it looks like we’re all coming at it from the same place albeit with a few additional comments.

    I did spot this on Lars Gunther’s blog that’s worth a read Pedagogic validation of HTML. Thanks to Laura Carlson for pointing this one out to me.

    And thanks all for your comments.

  13. I’d go for accessibility to meet the needs of real people over satisfying some rules coded into an outdated validation program every time. If a client is savvy enough to understand the significance of validation, it should be a simple matter to convince them of the folly of avoiding new and improved techniques for the sake of conforming to the best practices of five years ago.

    On the question of adding ARIA roles and properties via scripting, it all depends on whether it makes sense or not; there is certainly no point specifying an ARIA role in markup for an element that only adopts that role when a script is applied.

    A recent example from Steve Faulkner on the W3C’s HTML list is of a link that defaults to taking the user to a login page, but which will, when scripting is enabled, allow them to log in via an Ajaxy pseudo-dialog. In such a case, I would argue that the link should not have an ARIA role specified in markup, as its linky semantics are already made available to assistive technologies by User Agents; the script that binds to the link’s activation events (click, or whatever) should itself add the ARIA role of “button”, as it is only when the script is available that the role of the link is altered to be that of a button.

  14. Pingback: six03 - Validation or Accessibility?

  15. Well from my point of view, validation can be a true pain..Especially if you’re a new coder in the neighbourhood. I say accessibility always overpowers..as long as what they see is flawless why bother with validity?

  16. [未来链]自助友情链接系统,智能化的免费友情链接交换,友情链接联盟,友情链接网,友情,链接,中国最大_最早最专业的友情链接网站

  17. ARIA Best Practices suggest adding ARIA-related attributes via scripting. That way the document validates and has the necessary attributes.
    Plus it’s unobtrusive. No sense in having those attributes if scripting is disabled anyway.

    Having said that, I have no experience with any screen reader, so I can only speak theoretically. Keep that in mind while firing up the flamethrower.

  18. Thanks for the links.

    The validation tools are great for two purposes:

    1) Green checkmark as Heribert mentioned so that customers, particularly customers who have mandates but no real means to verify accessibility, feel comfortable that at least ‘better effort’ has gone into a site to make it accessible.

    2) Validation feedback to help, something that people seem to keep forgetting, the developers who have never done accessibility and need a way to measure their progress and guide them towards a more accessible site from the ‘better effort’ point of view.

    Obviously, validation won’t measure that a site is perfect for accessibility (or for the non-accessible users), but the validation tool will help progress towards ‘the moon’. You need measurable steps to make sure progress is moving forward — without some basic ‘hot’ or ‘cold’ way of getting their, you are walking in the dark!

  19. Pingback: My New, More Accessible Blogger Template | Terrill Thompson

  20. Pingback: JavaScript Reference Links | kabayview.com

  21. Your blog is pretty interesting to me and your subject matter is very relevant. I was browsing around and came across something you might find interesting. I was guilty of 3 of them with my sites. “99% of website managers are doing these 5 errors”. http://bit.ly/ts0ScL You will be suprised how fast they are to fix.

Comments are closed.