Prologue
A long time ago, the Web Content Accessibility Guidelines 1.0, published in 1999, urged web developers to “create documents that validate to published formal grammars”. This requirement was defined in checkpoint 3.2, which had priority level 2.
The Arduous Rise
When work began on WCAG 2.0, many wanted to get rid of the validation requirement, which was felt to be too restrictive. For example, the 19 November 2004 working draft, proposed the following wording:
Except where the site has documented that a specification was violated for backward compatibility or compatibility with assistive technology, the technology has: (...)
a. passed validity tests for the version of the technology in use (whether it be conforming to a schema, Document Type Definition (DTD), or other tests described in the specification),
b. structural elements and attributes are used as defined in the specification.
The exception for “compatibility with assistive technology” now sounds as if it would allow WAI-ARIA attributes, which would have caused validation errors in HTML and XHTML at that point in time, but the first public working draft of WAI-ARIA 1.0 wasn’t published until February 2008. In addition, the wording assumed that all web content would be based on markup languages, even though one of WCAG 2.0’s design goals was to create technology-neutral requirements.
The next working draft, published on 30 June 2005, removed the requirement, replacing it with an editorial note:
The success criteria, examples and benefits have not been included in this Working Draft because there is ongoing discussion about the priority of validity requirements in these guidelines. A summary of the issues, background, and questions for discussion to find a consensus-based outcome are available at Validity and Accessibility.
The note “Validity and Accessibility” that accompanied the working draft summarised the discussion on validation that had taken place and pointed to “spirited discussions” on the working group’s mailing list. As one working group member would later write hyperbolically, “There was almost WW3 over validation”.
The November 2005 working draft used a suggestion from the June 2005 face-to-face meeting to define a criterion that sat somewhere between validation and “anything goes”:
Delivery units can be parsed unambiguously and the relationships in the resulting data structure are also unambiguous.
This was not yet the final wording, but the definition of parsed unambiguously encapsulated the essence of the intent:
Parsing transforms markup or other code into a data structure, usually a tree, which is suitable for later processing and which captures the implied hierarchy of the input. Parsing unambiguously means that there is only one data structure that can result
What had actually been proposed in the working group was to draw inspiration from the XML concept of well-formedness. XML defines two levels of “correctness”: well-formedness and validity. Well-formedness is a purely syntactic matter and can be checked without reference to a document type definition or schema. All you need is a parser that understands the basic rules of XML. Validation, by contrast, is the more familiar concept and includes checking that only elements and attributes allowed by the document type definition are used, that attribute values are within the allowed data type or range, that elements only occur inside other elements that are allowed to contain them, etc.
To some extent, the concept of well-formedness can be translated to HTML. For example, you don’t need a document type definition to detect that two elements overlap instead of being properly nested, that a start tag has a duplicate attribute or whether the quotes around attribute values match. These are syntax issues in HTML.
The April 2006 (last call) working draft proposed the following wording for success criterion 4.1.1:
Web units or authored components can be parsed unambiguously, and the relationships in the resulting data structure are also unambiguous.
It wasn’t until the May 2007 working draft that the now familiar wording appeared:
Content implemented using markup languages has elements with complete start and end tags except as allowed by their specifications, the elements are nested according to their specifications, and any IDs are unique.
Content implemented using markup languages has elements with complete start and end tags except as allowed by their specifications, the elements are nested according to their specifications, and any IDs are unique.
Some of the wording of the definition of “parsed unambiguously” from the November 2005 working draft could now be found in Understanding Success Criterion 4.1.1 (Parsing) (emphasis mine):
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.
This requires correct syntax but not validity.
However, neither the success criterion itself, nor the understanding document pointed this out clearly. As a consequence, it was not clear that “elements are nested according to their specifications” referred to syntactic nesting rather than valid content models. You don’t need a document type definition to determine whether start and end tags are complete. Similarly, you don’t need a document type definition to determine whether elements are correctly nested at a syntactic level. In addition, there is nothing in the criterion that prohibits custom attributes. (Bear in mind that WAI-ARIA started out as a set of attributes that were not part of any HTML specification, just like custom attributes.) But many readers interpreted the nesting requirement as if it were a subset of validation, thereby imposing stricter rules for element nesting than for the syntax of start and end tags or for the use of custom attributes. This inconsistency went mostly unnoticed.
A Sea of Troubles
The Understanding document published alongside the the December 2008 recommendation pointed out that
The concept of "well formed" is close to what is required here. However, exact parsing requirements vary amongst markup languages, and most non XML-based languages do not explicitly define requirements for well formedness. Therefore, it was necessary to be more explicit in the success criterion in order to be generally applicable to markup languages. (...)
The difficulty with applying success criterion 4.1.1’s syntactical requirements to HTML is that you can’t check HTML syntax without validating the source code or the DOM. This is why validating web pages and using HTML according to spec were needed as techniques.
Many of the issues and questions raised related to this success criterion had to do with the lack of good tools to test it. For example, people asked whether deprecated elements and attributes failed the criterion (they didn’t), how to to interpret “complete start and end tags” for elements that have optional ends or no end tags at all, whether certain abuses of WAI-ARIA attributes violated the success criterion and whether it covers other markup failures that may affect AT. In 2015, an authoritative voice in the accessibility community simply declared success criterion 4.1.1 a PITA. (I hope the reader doesn’t mind this violation of success criterion 3.1.4.) Several years later, an issue in the WCAG bug tracker asked whether the success criterion should be deprecated but the proposed action plan to find out the impact of such a change on accessibility was never completed.
Decline and Fall
In June 2022, a proposal was submitted to reword success criterion 4.1.1 so its original intent would be more explicit. This proposal became the most heavily commented WCAG 2.x issue in the working group’s issue tracker, with 132 comments as of February 2023.
There was much disbelief about the claim that “elements are nested according to their specifications” was intended to refer to syntax rather than the validity of content models, and most of this disbelief was directed at former members of the working group who had heavily contributed to WCAG 2.0.
However, once this claim had been accepted, the discussion turned to the question whether the success criterion was still useful. After all, it had been written before HTML 4.01 and XHTML were displaced by HTML 5, which introduced much more consistent error handling than its predecessors. Thanks to more consistent error handling for HTML in current browsers, many commenters regarded the success criterion as obsolete.
There was also no support for keeping the success criterion for the sake of markup languages other than HTML. Another question was what types of issues that impact accessibility would no longer be caught if the success criterion were removed. This question did not receive an answer in that discussion.
While this debate was raging, another WCAG issue on GitHub argued against removing success criterion 4.1.1 from WCAG 2.2 because this would constitute a breaking change, and for marking it as obsolete instead.
The Final Act
As a result of the discussion on the proposal to reword success criterion 4.1.1 and related GitHub issues, the Accessibility Guidelines Working Group decided to declare the criterion obsolete. The January 2023 Candidate Recommendation Draft of WCAG 2.2 says,
This criterion was originally adopted to address problems that Assistive Technology had directly parsing HTML. Assistive Technology no longer has any need to directly parse HTML and, consequently, these problems no longer exists [sic]. Accessibility errors failed by this criterion also fail other criteria. This criterion no longer has utility and is removed.
Issue 2525 remains open until the working group has decided what to do with success criterion 4.1.1 in WCAG 2.0 and WCAG 2.1. Since checking the validity of content models causes a lot of work that most of the time has no benefits for accessibility, the success criterion is seen as doing more harm than good.
And that was the end of success criterion 4.1.1: born as a bastard child of XML, much maligned and misunderstood while alive, and eventually killed in ignominy. RIP.
Since the publication of this article in February 2023, the Accessibility Guidelines Working Group has also decided what to do with success criterion 4.1.1 in WCAG 2.0 and WCAG 2.1. For an update about this and the impact this has on a widely open-source accessibility testing library, see the blog post WCAG 2.2 Removes 4.1.1 Parsing and How axe-core is Impacted by Wilco Fiers of Deque (published on 21 June 2023).
