WCAG 2.0 parsing error bookmarklet

Posted on Thursday, 2 February 2012 by Steve Faulkner

While reading Jared Smith’s excellent article WCAG Next I was drawn to the following statement “next to impossible to evaluate” in reference to the checking of WCAG 2.0 success criterion 4.1.1 Parsing.

It is true (as far as I know) that there is no currently available dedicated service or software for checking 4.1.1 Parsing. What I do and advise clients to do is use the W3C validation service to check their code as the checks required for parsing criterion conformance are a subset of the checks that are made when validating HTML code.

Identifying relevant errors and warnings

A problem with using a standard HTML validator to check for this subset is that many other conformance errors and warnings are also reported and while these may or may not be important to fix, they are not a requirement within the scope of the success criterion. What I have been doing is checking pages against the HTML5 doctype as this minimizes the occurance of errors and warnings that are unrelated to parsing, but still a page can contain many non parsing errors, making it difficult to identify the relevant results.

I have also had discussions with Mike Smith (W3C Nu Markup Validation Service) and Henri Sivonen (Validator.nu) about providing a method to filter conformance results to display only parsing issues. There are apperently some design reasons why this would be difficult (not impossible) from a backend code perspective, so I thought a reasonable place to start would be with a client side script that filtered the display of results from a validator.

Parsing error bookmarklet

The WCAG parsing only bookmarklet is an experimental script that loops through the results displayed when using W3C Nu Markup Validation Service. It looks for certain text strings in the results output and if it does not find them in the text for a particular result it hides that result using CSS display:none.

Check results other than the followoing are filtered:

  • Elements have complete start and end tags
  • Elements are nested according to their specifications
  • Elements do not contain duplicate attributes
  • Any IDs are unique
  • Unquoted attributes (under certain circumstances)
  • Duplicate attributes
  • Mismatched quotes on attributes
  • Attributes not space seperated
  • Mismatched element start and end tags
  • malformed attributes

Trying out the parsing only bookmarklet

  1. save the WCAG parsing only as a bookmark.
  2. open the W3C Nu Markup Validation Service in your browser
  3. validate a page (test page)
  4. activate the bookmarklet
  5. To view the unfiltered list of results again – refresh the page
  6. you can download the parsing.js code
  7. HTML conformance checking and result filtering is also built in to the Web Accessibility Toolbar 2012


This is an experiment only, due to various constraints the method used to filter the results is not the most robust as it relies upon text string matching.

Note: this experiment would not have been possible without the help of my friends and colleagues Hans Hillen and Gez Lemon, who although they thought the method used was crappy, helped me anyway.

About Steve Faulkner

Steve is the Technical Director at TPG. 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 Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including HTML 5.1, ARIA in HTML, Notes on Using ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility.


  1. An excellent resource Steve. My “next to impossible to evaluate” claim was overly broad – and this tool certainly proves that to be the case. What IS “next to impossible to evaluate” is whether those parsing errors make any difference for accessibility. As I noted in my article, I’m not aware of any such errors that affect assistive technology that are not already addressed by other guidelines.

    In short, while valid code is always an excellent idea, I don’t see how the 4.1.1 Parsing requirement does anything to aid accessibility.

  2. First off – siteSifter does validation as part of both the WCAG 1 and 2 baselines, as well as partial validation (the “required checks” above) in a client-specific set of tests. It is somewhat heuristic the whole thing, of course, but it is quite possible. Note that this relate to HTML validation – HTML5 is a different kettle of fish.

    Secondly, I’d claim that validation DOES aid accessibility, as it’ll remove such bugs as unclosed elements, or more precisely incorrectly closed ones, which can make certain things very difficult. I’m sure we’ve all run across pages that are one, gigantic, hyperlink because an A got left out somewhere … it is, of course, not a panacea.

  3. Hi Jared,
    I have found the odd nesting error that has affected a screen readers ability to convey table information correctly and having multiple form controls with the same id values is definielty a potential issue, so cannot agree with you completely on this one.

  4. Inspiration bit of sideways thinking Steve, will follow this with interest.

    My thoughts on the parsing debate: Clean code will not harm accessibility, bad code might. Why take the risk? In addition, clean code is quicker to load and easier for search engines to read. The outcome: accessible, speedy and well ranked.

  5. Steve –

    If a screen reader is unable to get table information or if form controls are not properly associated, these would be failures of other success criteria. My point still stands – I can think of no parsing error that BY ITSELF causes accessibility issues that are not covered elsewhere in WCAG.

    Again, I’m not arguing against validation, I just don’t think it should be an accessibility conformance requirement.

  6. When performing user accessibility testing, I have often wondered if criteria 4.1.1 should be flagged, but have concluded like Jared that it is not really an accessibility issue. I assume it will be flagged by automated tool testing, and since it comes under the Robust category, it is “Value Added” and simply good coding. However, it should remain as a criteria check, as it will reduce manual user testing accessibility errors considerably.

Comments for this post are closed.