In 2012 I wrote:
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.
In 2015 I wrote WCAG 2.0 Parsing Criterion is a PITA which discusses the ins and outs of the Parsing criterion.
In 2019 we have WCAG 2.1, with no change to the parsing criterion.
In 2012 I wrote: and this holds true in 2019 (as far as I know).
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 following 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
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, Gez Lemon and Dennis Lembrée who although they thought the method used was crappy, helped me anyway.