4.1.1 Parsing (A)

The intent of this Success Criterion is to ensure that user agents, including assistive technologies, can accurately interpret and parse content. If the content cannot be parsed into a data structure, then different user agents may present it differently or be completely unable to parse it. Some user agents use "repair techniques" to render poorly coded content.

Since repair techniques vary among user agents, authors cannot assume that content will be accurately parsed into a data structure or that it will be rendered correctly by specialized user agents, including assistive technologies, unless the content is created according to the rules defined in the formal grammar for that technology. In markup languages, errors in element and attribute syntax and failure to provide properly nested start/end tags lead to errors that prevent user agents from parsing the content reliably. Therefore, the Success Criterion requires that the content can be parsed using only the rules of the formal grammar.

Note: since WCAG 2.0 was released, markup specifications (in particular for HTML) have evolved to include algorithms that standardize most common "repair techniques" used by browsers/user agents. As such, even markup which fails HTML validation will generally be error-corrected the same way by different modern browsers. There are nonetheless still cases where validation errors generally have accessibility repercussions. As such, testing markup for 4.1.1 Parsing involves checking against a subset of the checks that are made when validating HTML code. These include checking that:

• Elements have complete start and end tags.
• Elements are nested according to their specifications.
• Elements do not contain duplicate attributes.
• Any id attributes are unique.
• Attributes are quoted (except under certain circumstances).
• There are no duplicate attributes.
• The quotes on attributes are not mismatched.
• Attributes are space separated.

At a high level, testing against this success criterion is accomplished using an automated markup validator, such as the online W3C Markup Validation Service and then interpreting/filtering any of the reported errors/warnings to only include markup errors which impact accessibility.

To facilitate the filtering, The Paciello Group has released a JavaScript based WCAG 2.0 parsing error bookmarklet.

Note: in general, online validators allow testers to simply provide a URL to test; the validator then fetches the content of the URL and runs validation checks. This won't work for resources / web addresses that are not publicly available, such as intranet-only pages. Additionally, validators generally only check the markup as sent by the server - if a page/site relies on client-side JavaScript to generate/display content (and particularly if it contains interactive elements, such as dialogs, which dynamically load further content), this content won't be checked by the validator. In these situations testers will have to resort to copying the page's rendered DOM (using their browser's developer tools) and "manually" validating it (for instance, by pasting it into the alternative "Validate by Direct Input" text box in the W3C Markup Validation Service).

Note: if the specific sample to be tested is not implemented using markup languages (i.e. it is not an HTML sample, but a standalone video file or similar), this criterion is marked as not applicable.