Understanding WCAG 2.1 Success Criterion 4.1.1
One of the most frequently misunderstood success criteria in WCAG 2.0 and WCAG 2.1 is success criterion 4.1.1 parsing. The criterion was written when HTML 4.01 (based on SGML) was still in use and XML-based successors had been in development for several years, especially XHTML 1.0 (a reformulation of HTML 4 in XML 1.0) and XHTML 2.0. Development of XHTML 2.0 was abandoned after HTML 5 turned out to be much more viable. Instead of building on SGML or XML, HTML 5 describes how an HTML parser should behave and what parse errors are.
What distinguishes HTML 5 from its predecessors is that it is based neither on SGML nor on XML. However, when success criterion 4.1.1 was defined for WCAG 2.0, it was not yet clear that HTML5 would radically break with XML and its clear separation between syntax (well-formedness constraints) and document type (validity constraints). The wording of the success criterion is based on XML's concept of well-formedness but avoids that term in order to remain format agnostic and thereby more future-proof.
When we read success criterion 4.1.1 with XML in mind, we arrive at the following meanings:
elements have complete start and end tags
. This says that each tag should be complete, not each element, so it does not refer to missing required end tags, which would be a validation constraint. Instead, it refers to missing characters in the tags themselves. In fact, this is explained in the note below the success criterion.
(Background: (1) Tags are not the same as elements. Tags are the character sequences that define where an element begins and ends. Elements are essentially nodes in a syntax tree (not any nodes, but instances of element types). (2) End tags are not required for every HTML element; for example, they are optional for elements such ashtml
,head
,body
andp
. See Optional Tags in the HTML 5.2 specification. Other elements, by contrast, are not allowed to have an end tag in HTML 5, for example,img
,track
,area
andsource
. However, from an XML point of view, these are validation constraints, not well-formedness constraints.)elements are nested according to their specifications
. This is syntactical constraint (like XML's well-formedness), not a validity constraint. So it is not about whether you can have ap
element inside aspan
element, for example. Instead, it is about whether elements overlap, as illustrated in the subchapter on well-formedness in XHTML 1.0. (This overlapping was already illegal in SGML.) See also in the HTML 5.2 specification: Misnested tags:<b><i></b></i>
and Misnested tags:<b><p></b></p>
.elements do not contain duplicate attributes
. This is is another syntactical constraint and the easiest part of the success criterion. Note that the HTML 5 specification's chapter on tokenization states that duplicate attributes are parse errors and that if a tag has more than one attribute with the same name, only the first one is retained in the syntax tree.any IDs are unique
. This is also easy to understand, but unlike the previous requirement, this is strictly speaking a validity constraint, not a syntax constraint. See Validity constraint: ID in the XML specification. The HTML 5.2 specification does not discuss duplicate ID values in the chapter on parsing but in the chapter on semantics: global attributes.
(Note that HTML 5 allows ID values that start with a number, whereas XML does not. However, this is outside the scope of success criterion 4.1.1.)
The success criterion prohibits neither custom elements nor custom attributes. When WCAG 2.0 was in its final stages, development if WAI-ARIA had already started. The first public working draft of WAI-ARIA was published in February 2008, a few months after the WCAG working group had published its second Last Call Working Draft of WCAG 2.0. At the time, it was not possible to use WAI-ARIA attributes in HTML 4.01 or XHTML documents without causing validation errors; this type of attributes were still essentially custom attributes. The first public working draft of HTML 5 was published in January 2008 and did not address WAI-ARIA or custom attributes. The WCAG did not want to hamper the use of WAI-ARIA or other attributes that would improve accessibility. For this reason, success criterion 4.1.1 does not say what types of attributes are allowed or disallowed.
Some have objected to explaining the phrase elements are nested according to their specifications
as a syntax constraint and
insisted that it is a validation constraint because the normative text does not support [this] interpretation
.
However, the “validation interpretation” of the criterion introduces an inconsistency into the success criterion,
since it requires only correct syntax at the level of attributes and validation at the level of element nesting, in other words two different types of constraints for two features of the same markup languages.
The “syntax interpretation”, by contrast, makes the success criterion internally consistent (same type of constraint for both attributes and element nesting),
consistent with the criterion's name (“Parsing”) and with the (non-normative)
Understanding Success Criterion 4.1.1: Parsing (for WCAG 2.0).
If inconsistency in the requirements for attributes and element nesting had been intended, the Understanding document would have pointed this out (but it does no such thing).
Historical note: XHTML 2.0 would have supported the use of WAI-ARIA roles through its Role Attribute Module. See also XHTML Role Attribute Module (Working Group Note, December 2010 and Role Attribute 1.0 (W3C Recommendation, March 2013). However, the 16 December 2010 version of XHTML 2.0 was the last draft of that specification. XHTML 2.0 was retired in 2010 because browser developers preferred to support HTML 5.
The section Notes on the History of Success Criterion 4.1.1 attempts to reconstruct the history of the success criterion based on publicly available sources.
Test Pages
Below is a list of test pages, some of which contain errors according to the W3C's Validation Service. However, not all issues flagged by the validator are failures of success criterion 4.1.1.
head
andbody
elements without start and end tagsp
element without end tagp
element without start tag- Nested
span
elements - Nested
a
elements - Overlapping
em
andb
elements form
element andinput
element with the sameid
attributespan
element withonclick
attribute to create a fake link- page combining all of the above issues or features
- page combining all of the above issues or features with a few additional ones
Other test pages:
div
insidebutton
(HTML 5 version)div
insidebutton
(XHTML version of previous file)- Ambiguous label in form
div
insideul
- Empty link inside
button
- Unquoted Attribute with Whitespace Value (HTML 5 version) based on Examples 3 and 5 in Failure F70; see also F70 goes beyond WCAG 4.1.1 #2187 in the WCAG issue tracker on GitHub.
- Unquoted Attribute with Whitespace Value (XHTML 1.0 version)
span
withhref
Attribute- Input Field with Label and Duplicate Description
- Lists relying on WAI-ARIA Roles (see Violation of 4.1.1, if with ARIA syntax is correct? #2135)
- Link Inside Label
- Minimalistic HTML 5 document.
- Minimalistic XHTML 1.0 Strict document.
Validator Errors and Warnings
Accessibility audits often rely on tools such as the W3C's Validation Service to identify violations of success criterion 4.1.1. Examples of validator errors or warnings that are failures of the success criterion include the following:
- End tag
div
seen, but there were open elements. - Stray end tag
section
. - End tag
em
violates nesting rules. - Duplicate attribute
class
. - Duplicate attribute
id
. - Duplicate ID
search-1
.
The following errors and warnings may be failures of success criterion 4.1.1.
- Stray end tag
a
.
This is a syntax error if triggered by code such as<span>…</span></a>
(there is no matching start tag for thea
element).
This is a validation error but not a syntax error if triggered by the following code:<a href="..."><a href="..."></a></a>
. (Nesting links violates HTML content models.) - No space between attributes.
HTML 5.2's section on attribute syntax
contains the following requirement:
If an attribute using the double-quoted attribute syntax is to be followed by another attribute, then there must be ASCII whitespace separating the two.
(Similar rules exist for empty attribute syntax, unquoted attribute value syntax, single-quoted attribute value syntax.)
No space between attributes. is a syntax error but success criterion 4.1.1 does not explictly define syntax requirements for attributes. Code such as<img src="logo.png"alt="Acme logo" />
does not fail any of the requirements in the success criterion, but<img src="logo.png"alt="Acme logo />
causes an incomplete tag and therefore fails the criterion.
The following errors and warnings are not failures of success criterion 4.1.1. Some of them are violations (or potential violations) of other success criteria, whereas others are not relevant to any success criterion.
- Bad character . after <. Probable cause: Unescaped <. Try escaping it as <.
This is a syntax error, but success criterion 4.1.1 does not consider this error as a violation. - End tag had attributes.
This is a syntax error, but success criterion 4.1.1 does not consider this error as a violation. - An
img
element must have analt
attribute, except under certain conditions.
(See success criterion 1.1.1.) - The
banner
role is unnecessary for elementheader
.
(This warning can be reported under success criterion 4.1.2 Name, Role, Value, even though that success criterion is strictly speaking only about user interface components.) - Attribute
placeholder
not allowed on elementinput
at this point.
(This is a pure validation error, not a syntax error.) - Start tag
a
seen but an element of the same type was already open.
(This is a validation error; however, see the syntax error in the preceding list.) - Section lacks heading. Consider using
h2
-h6
elements to add identifying headings to all sections. - Attribute with the local name
xmlns:og
is not serializable as XML 1.0. - Bad start tag in
img
innoscript
inhead
. - This document appears to be written in English. Consider adding
lang="en"
(or variant) to thehtml
start tag.
(See success criterion 3.1.1.) - Element
div
not allowed as child of elementol
in this context. (Suppressing further errors from this subtree.)
(This is a pure validation error, not a syntax error.) - Possible misuse of
aria-label
.
(Found on a page with the following code:<div class="grid--cell mr12" aria-label="notice-message">
.) - Bad value
for attribute
aria-controls
on elementbutton
: An IDREFS value must contain at least one non-whitespace character.
(Found on a page with an emptyaria-controls
attribute.) - The
name
attribute is obsolete. Consider putting anid
attribute on the nearest container instead.
(This is a pure validation error, not a syntax error.) - Bad value
status
for attributerole
on elementaside
.
(This is a pure validation error, not a syntax error. See success criterion 2.4.6 or 4.1.2.) - The
aria-describedby
attribute must point to an element in the same document.
(Depending on context, this may be relevant to success criterion 4.1.2 or 4.1.3.) - The
aria-controls
attribute must point to an element in the same document. - Consider using the
h1
element as a top-level heading only (allh1
elements are treated as top-level headings by many screen readers and other tools).
(Potentially relevant to success criterion 1.3.1.) - X-UA-Compatible HTTP header must have the value
IE=edge
, wasIE=Edge,chrome=1
. - Bad value
https://fonts.googleapis.com/css?family=Source Code Pro
for attributehref
on elementlink
: Illegal character in query: space is not allowed. - CSS:
xright
: Propertyxright
doesn't exist. - CSS:
color
: Parse Error.
(Parse errors in CSS don't count.) - Document uses the Unicode Private Use Area(s), which should not be used in publicly exchanged documents. (Charmod C073)
- The element noscript must not appear as a descendant of the noscript element.
- Self-closing tag syntax in text/html documents is widely discouraged; (…).
(This is a warning, not an error, and does not violate any WCAG success criteria. The validator started giving out this warning in (late?) September 2022.) - Trailing slash on void elements has no effect and interacts badly with unquoted attribute values.
(This is a warning, not an error, and does not violate any WCAG success criteria. The validator started giving out this warning in October 2022, probably replacing the previous warning about self-closing tag syntax. It even issues this warning for HTML files in which attribute values are consistently quoted (e.g.meta
andlink
elements in thehead
element) and for<br />
tags without attributes.)
How to Check Conformance to SC 4.1.1
Steve Faulkner's articles WCAG 2.0 Parsing Criterion is a PITA (TPGi, 20.11.2015) and WCAG 2.1 parsing error bookmarklet – updated 25th February 2019 desribe why conformance to SC 4.1.1 is difficult to check and provides an approach: use the W3C Markup Validation Service, then use a bookmarklet to filter the errors and warnings output by the validator. The remaining errors are to be considered violations of the success criterion. The main issue with the bookmarklet is that it retains many errors that are strictly violations of content models rather than syntax issues. Another issue is that the bookmarklet code on GitHub looks unmaintained: as of November 2022 it has open issues dating back to November 2019; newer warnings issues by the validator are not taken into account.
Another approach, suggested elsewhere, consists in using parsetree.validator.nu. This service seems to reliably find syntax errors without reporting validaion errors. However, this has several drawbacks. First, it is an undocumented service; neither About Validator.nu nor The Validator.nu HTML Parser mention this service, nor how to run it elsewhere. It is not mentioned in the validator wiki on GitHub either. Second, it outputs a represeation of an entire parse tree, whereas users would only be interested in the presence of syntax issues, which are listed only at the very end of the results page. Finally, it does not catch duplicate IDs, since that is not a syntax issue, so anothe tool would still be needed to check IDs.
For these reasons, it seems better to adapt Steve Faulkner's bookmarklet so it filters out all validation errors and retains only those issues that really are violations of the success criterion. The WCAG syntax only bookmarklet is an adapted version of Steve Faulkner's WCAG parsing only bookmarklet that filters more types of errors and warnings. Validator messages caused by incorrect content models, which are not syntax issues, are now no longer shown after using the bookmarklet. The full source code (not minified) is available elsewhere on this website and in the site's GitLab repository.
Notes on the History of Success Criterion 4.1.1
Even though I was a member of the WCAG Working Group when this success criterion was discussed and formulated,
people sometimes want to know if there is any evidence for my explanation of the success criterion, especially the condition elements are nested according to their specifications
.
The history of the success criterion has beome difficult to reconstruct, because when discussion about it began, the working group's minutes recorded only resolutions and to-do items (and some notes and links that were deemed important enough) instead of full discussions,
and because Bugzilla bugtrackers—both the W3C public bugzilla
and the WCAG Working Group's Bugzilla hosted at the Trace Research & Development Center
(then still at the University of Wisconsin at Madison)—are no longer online. Publicly available evidence is based on those WCAG Working Group meeting minutes that are still publicly accessible (not all of them are)
and on posts to the working group's mailing list. Below are a few pointers retrieved in mid June 2022, especially references to the concept of well-formedness.
- WCAG WG meeting minutes, 23 June 2005.
The wording in the November 2004 draft requires more discussion.
Resolution:leave all of the SC out of GL 4.1 and have an ed note stating the problem and pointing people to an external page describing the problem in more detail along with our current proposals. Ed note will invite comment and comments can be added to the "problem/proposal" page.
This editorial note was added to the 30 June 2005 working draft; the external page Validity and Accessibility. The document states thatalthough HTML is a SGML application and SGML does not have the concept of well-formedness, it does seem like a reasonable approach to say "make sure the DOM can be consistently formed" and refer to well-formedness in XML. The sub-group should also investigate PDF, Flash, and other formats and propose a parallel criterion.
The section “Well-formed and valid” contains additional notes that show that well-formedness, or something similar that would translate to non-XML documents, was what some working group members wanted to see at Conformance Level A (still called Level 1 at the time).
The minutes also contain a link to a discussion about semantics versus well-formedness on the working group's mailing list (20 June 2005) that discusses SGML, XML and well-formedness. The starting point of the discussion thread was a question about the mention of well-formedness in a draft for Guideline 4.1. See, for exammple, Well-formed (was: Re: F2F Proposed Resolutions Draft Updates) (17.06.2005):In Brussels, we tried to define a level of "correctness" that is lower than validity and that still makes sense for formats that are not based on XML. It is true that SGML does not define well-formedness, but if you say that a well-formed document is essentially "one that can unambiguously be parsed to create a logical tree in memory" (Jon Bosak, at http://www.isgmlug.org/n3-1/n3-1-18.htm), then you can apply this concept also to SGML.
See also Gez Lemon's response with arguments against the term “well-formed”. - WCAG WG meeting minutes, 6 October 2005:
editors are doing 4.1
. - WCAG WG meeting minutes, 10 November 2005:
after a discussion on SGML content models, the working group accepts the following wording for SC 4.1.1:
Delivery units can be parsed unambiguously.
The following definition of parsing was accepted along with it: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.
This wording was published in the 23 November 2005 working draft. This wording is clearly based on syntax and does not require valid content models. For XML, well-formedness would essentially give the same result. A requirement for the uniquenesss of identifiers is not yet present at this stage. - Charles McCathieNevile:
[last call] Unambiguous parsing, 23.06.2006.
In this comment on the (first) last call working draft, Charles McCathieNevile suggested to return to the wording from WCAG 1.0:
conforms to formal published grammars
. - WCAG WG meeting minutes, 17 November 2005: resolutions related to a draft of
How to meet SC 4.1.1 (referred to as “Guide doc” in the minutes).
Quotes from the minutes:
accept unanimously wendy's rewording SC 4.1.1 "delivery units can be parsed unambiguously and the relationships in the resulting data structure are also unambiguous"
and… ensuring that the delivery unit is well-formed AND that unique ids are specified adopted
(the latter referring to two proposed techniques).
Titles for proposed techniques:Ensuring that unique ids are specified AND that opening and closing tags of all elements can be parsed unambiguously
(for HTML-based content) andEnsuring that the delivery unit is well-formed AND that unique ids are specified
(for XML-based content). - WCAG WG meeting minutes, 2 December 2005:
proposed changes to 4.1 and 4.2: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005OctDec/att-0592/4.1and4.2Proposal.htm
. (No change for SC 4.1.1, nor anything relevant to its understanding.) - WCAG WG meeting minutes, 25 October 2007:
Issue 2134, 2218: SC 4.1.1 and markup languages
. Due to the WCAG bug tracker no longer being available, the content of the resolution can no longer be retrieved.
The next public working draft, dated 11 December 2007 contained the following wording of SC 4.1.1: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.
This wording was introduced after the 27 April 2006 working draft, which contained the following wording:Web units or authored components can be parsed unambiguously, and the relationships in the resulting data structure are also unambiguous.
- Understanding Success Criterion 4.1.1: Parsing (for WCAG 2.0) also discusses how well-formedness informed the wording of the success criterion:
Note: 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. Because the term "well formed" is only defined in XML, and (because end tags are sometimes optional) valid HTML does not require well formed code, the term is not used in this success criterion.
See also the note for Understanding Success Criterion 4.1.1: Parsing (for WCAG 2.0) contains the same language.
The “Intent” section uses the “data structure” concept that had been used in earlier version of the success criterion: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 is based on syntax rather than validation.
A Proposal to Rephrase Success Criterion 4.1.1
Since many accessibility testers and other accessibility experts erroneously interpret the phrase elements are nested according to their specifications
as referring to content models instead of syntactical nesting, a rewording that avoids this misunderstanding is highly desirable. Below is a proposed rewording.
(This rewording was submitted as WCAG issue 2525 on 22.06.2022.)
In content implemented using markup languages, the following are true, except where the specifications for the markup languages being used allow exceptions to these requirements:
- elements have complete start and end tags,
- elements are nested according to the syntactical rules of their specifications,
- elements do not contain duplicate attributes, and
- any IDs are unique.
Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.
Note: Syntactically correct nesting is distinct from nesting according to the content models specified in a technical specification. The second condition of the success criterion does not require correct content models; only correct syntax.
Note: When a scripting language is used to manipulate elements or attributes (or both) in the Document Object Model, the resulting in-memory representation is still regarded as
content implemented using markup languages.
Description of the changes: The second condition has been reworded to highlight syntactical correctness (as opposed to validity of content models). The second note, which is new, draws attention to this.
The first note is identical to the note in the WCAG 2.1 recommendation from June 2018.
The numbering is new; the phrase the following are true
is copied from other success criteria, such as SC 1.2.1 and SC 2.2.2.
The third note addresses an issue unrelated to the distinction between correct syntax and validity.
Compatibility with existing versions of WCAG 2 and EN 301 549:
Since the proposed rewording results in a requirement that is less strict than the interpretation of most accessibility testers,
all documents that pass the current version of SC 4.1.1 should also pass its proposed rewording.
In this sense, the proposed rewording is compatible with the current version.
Clause 9.4.1.1 of EN 301 549 says, Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 4.1.1 Parsing
.
Unless the editors of EN 301 549 want to retain the current version of the success criterion, no rewording of clause 9.4.1.1 is needed beyond, at some future point in time, an update of the referenced version of WCAG.
The intent of this rephrasing is not to “defend” the many types of validation errors that accessibility testers flag using this success criterion. My intent is merely to eliminate a common misunderstanding about what the success criterion actually means. If non-syntactical validation errors which impact accessibility are found, these should be caught either by existing success criteria or by new ones that still need to be created.
Links
- W3C Markup Validation Service
- Understanding Success Criterion 4.1.1: Parsing (WCAG 2.1, W3C)
- G134: Validating Web pages (Techniques for WCAG 2.0, W3C)
- Well-Formed XML Documents (Extensible Markup Language (XML), W3C)
- Optional Tags (HTML 5.2, W3C redirecting to WHATWG)
- XML Validator (W3Schools)
- Steve Faulkner: WCAG Parsing Bookmarklet, updated on 09.06.2021.
- W3C specs requiring valid code: posted to the WCAG working group's mailing list on 9 November 2005. The background was a discussion on how SC 4.1.1 should be formulated; using the concept of validity would require that it applies formats other than XHTML. Conformance to HTML 4.01, for example, did not explicitly require valid code.
- History of Changes to WCAG 2.0 Working Drafts
- Minutes from AG (formerly WCAG) WG meetings. Not all meeting minutes are publicly available, especially from 2004, 2006, 2007, 2008, 2009 and 2010.
- Page Tree Dump.
- Joe Watkins: NU HTML Checker Hybrid Parsing Bookmarklet, on GitHub, published on 27.09.2022.
Questions and Statements about the SC's Meaning
Questions and discussions about how the success criterion should be interpreted:
- Re: [wcag2] "complete start and end tags": posted to the WCAG mailing list on 4 March 2009. See also 4.1.1 question, not clearly documented posted by Jens Meiert on 19 February 2009.
-
Re: Question re. SC 4.1.1 and technique G134: posted to the WCAG mailing list by Gregg Vanderheiden on 21 April 2009.
Quote:
That provision only applies to content that is implemented in markup languages. So Javascript is not affected by that provision. But the markup languages on a page with javascript are.
- WCAG 2 conformance claim: validating code: question posted by Sailesh Panchang on 24 September 2010. Working group response Re: WCAG 2 conformance claim: validating code, 23 March 2011.
-
SC 4.1.1 - are deprecated tags or attributes a concern?: question posted by Marc Johlic on 23 May 2011.
The question references a WCAG comment from January 2008:
Absence of success criterion for deprecated and obsolete features, which had asked,
Why is there no success criterion (not even a "AAA") that requires deprecated and obsolete features to be avoided? (…)
-
WCAG 2.0 4.1.1 Parsing (elements have complete start and end tags): question posted by Steve Faulkner (then HTML 5.1 co-editor) on 9 February 2014.
Quote:
(…) in HTML end tags certain end tags are optional [2] and certain elements have no end tags (<img>, <input> etc.) How do we explain/reconcile this disparity?
Gregg Vanderheiden's response (9 February 2014):"Complete start and end tags" does not mean "matching start and end tags". They key is always what is in the specification. If a specification only requires one tag in some cases then one tag would constitute "complete start and end tags" for that feature. The phrasing of the success criterion was chosen to differentiate situations where specifications require start and end tags, but they are often missing because browsers can repair and recover from missing tags, but unfortunately not all AT could. The language in the success criterion was never intended, and should not be interpreted to mean, that WCAG requires start or end tags that are not required by the specification."
Response by Christophe Strobbe (10 February 2014) referencing XML's concept of well-formedness. - Thoughts on roles and conformance to SC 4.1.1 Parsing: posted by Jonathan Avila on 21 August 2015.
- Faulkner, Steve:
WCAG 2.0 Parsing Criterion is a PITA,
TPGi, 20.11.2015 (accessed on 17.06.2022).
Steve Faulkner created the wcag parsing error bookmarklet (available on GitHub without an open-source licence) based on the understanding described in this article and in WCAG 2.1 parsing error bookmarklet – updated 25th February 2019 (accessed on 17.06.2022). See also WCAG Parsing Bookmarklet on CodePen.
Steve Faulkner provides good error examples except for the conditionelements are nested according to their specifications
, which he interpets semantically instead of syntactically. He claims,What this requirement means is that you cannot do something silly like having a list item
. The code examples he gives contain validation errors and are non-conforming, but they are not examples of the type of syntax errors that the success criterion prohibits.li
without it having aul
orol
as a parent (…) or multiple controls inside a label element (…) -
Re: Question on 4.1.1 Parsing - what it covers: posted to the WCAG mailing list on 12 January 2016.
As far as I understand, SC 4.1.1 covers only the four parsing errors that are explicitly mentioned, and no other ones.
Re: Question on 4.1.1 Parsing - what it covers (Jason White) on 12 January 2016:(…) there may be cases of markup which is not well formed in ways that create accessibility barriers, without breaching 4.1.1.
(not well formed
suggests that the success criterion is not about validation.) -
Re: Question #2 on 4.1.1 Parsing - what it covers - markup-wise: posted to the WCAG mailing list on 13 January 2016.
Quote:
(…) HTML 4 and its predecessors were based on SGML, where "well-formed" markup was not a concept. (SGML-based documents are valid or not valid when compared against the DTD.) (…) HTML 5's HTML syntax is merely "inspired by SGML".) and does not have the concept of "well-formed markup". (…)
Response by Gregg Vanderheiden, 13 January 2016:This is a quite good answer and agrees with my memory of the discussions as well
- Re: Question #2 on 4.1.1 Parsing - what it covers - ARIA? and How? - and SVG: posted to the WCAG mailing list on 14 January 2016.
Quote:
SVG is (and has always been) XML-based, and the conformance sections of both SVG 1.1 [1] and SVG Tiny [2] required well-formed code, so SVG content that meets the SVG conformance criteria also meets SC 4.1.1.
Later in the same thread: Question #2 on 4.1.1 Parsing (…) by Gregg Vanderheiden, 29.01.2016:(…) We only cited those for bits because they were the only ones with any evidence of Causing problems for assistive technologies. We specifically did not require that everything be done to spec because there was no evidence that following a specification completely was needed for accessibility. In fact there were some places where it was shown that following a specification religiously actually prevented pages from being as accessible as otherwise as possible.
The provision should not be read as “use everything exactly to specification” although there was consensus that in general that is very good practice. Making it a requirement for accessibility however went beyond what our mandate was. Our mandate was to only address things that addressed accessibility and not carry the torch for good interface or other practice that did not directly impact accessibility in any known way. -
Andrew Kirkpatrick's comment on WCAG issue 761 (3 June 2019):
My short answer to your precise question is no. 4.1.1 doesn't require validation, although if a page validates it will pass 4.1.1.
-
goetsu organised an informal Twitter poll on 10.05.2022:
is img without alt and with role="presentation" a SC 4.1.1 failure ? github.com/w3c/wcag/issues/186 (…)
Eight people repsonded to the poll; 2 said yes, 6 said no.
The referenced WCAG issue is F38 and 4.1.1 conflict ? The issue was closed because F38 is a failure only of SC 1.1.1, not of SC 4.1.1. -
Automated A11y non-issues and SC Parsing 4.1.1: posted by Joshue O Connor on 18 July 2016.
Quote:
I have a client which uses multiple IDs in their UI widgets - these IDs are 'active' at different times for different reasons depending where the user is within a 'flow'. It hasn't demonstrated any a11y problems, but is technically a fail of SC 4.1.1. (…)
Several working group members see this as a false positive and there was an attempt to reword SC 4.1.1 to get around this issue. -
Question: testing for non-unique id values SC 4.1.1: posted by Sailesh Panchang on 29 September 2016.
The ensuing discussion led to the following comment by working group chair Andrew Kirkpatrick:
This seems to be a great example of why 4.1.1 is not really accomplishing what people may hope. (…)
(David Macdonald:There was almost WW3 over validation, and this was our compromise.
)
Jonathan Avila's response from 30 September 2016 lists several syntax-related issues he had encountered in the wild that caused problems for assistive technologies but not for other users.
Andrew Kirkpatrick's response from 29 September 2016 asks,I don't think the phrase "...in content USING markup languages..." is the same as "In markup content ..."
But it says “in content implemented using markup languages”. If I implement content using javascript to create a useful DOM tree, am I using markup? -
Wilco Fiers organised an informal Twitter poll on 01.03.2019.
He asked whether
<button><div>Text</div></button>
violates SC 4.1.1. 39 Twitter users responded: 38.5% thought the code violates the success criterion, 28.2% said,Yes, but I never call it
and 33.3% said it was not a failure. - Doole, Rushana:
Want to understand Success Criterion 4.1.1 – Parsing (Level A)?,
LinkedIn, 01.5.2019.
This article already misinterprets the success criterion in its first sentence:4.1.1 Parsing is a success criterion that is all about giving attention on HTML semantics errors that could occur unintentionally (…)
. In reality, the success criterion is about syntax (and unique IDs), not semantics in the sense of content models. Most of the examples in the article are good, with the exception of the section onHTML elements are nested according to the specifications
, which erroneously interprets this as referring to content models instead of syntax. -
correct syntax versus content models according to SC 4.1.1 (Re: <ol start="3"> Is this accessible?)
Quote:
Yes, and this refers to correct nesting at the *syntactic level*, not to validation.
Sent to the WAI-IG mailing list on 27.11.2019. This post triggered the following issue in the working group's GitHub issue tracker: What does nested according to the specification mean in SC 4.1.1. -
4.1.1 Parsing - Exception for custom attributes other than data-*? #1078 (WCAG issue tracker on GitHub, 09.03.2020).
This issue was closed based on the argument that
it's fairly clear from the normative language of the spec that attributes - other than duplicate attributes and non-unique IDs - do not fall under the SC's purview
. - 9.4.1.1 - Definition Custom-Attribut: Syntaxfehler vs, Validierungsfehler #99 (BIK-BITV issue tracker on GitHub, 20.01.2020).
- Roselli, Adrian:
Beware False Negatives,
Adrian Roselli, 25.09.2021; updated on 07.10.2021.
This blog post is not specifically about SC 4.1.1 but incorrectly claims that<button><h2>A button holding a heading</h2></button>
is a 4.1.1 Parsing error under WCAG
. In reality, this is purely a content model issue, not a syntax issue, and therefore not a violation of the success criterion.
Roselli also claims that the code fragment under Abusing Roles and Not Knowing It, which uses custom elements combined withrole="heading"
andaria-level
attributes to fake and nest headings, also violates the success criterion. In reality, the code does not contain a single violation of SC 4.1.1. None of the comments correct Roselli on this. - Violation of 4.1.1, if with ARIA syntax is correct? #2135 (WCAG issue tracker on GitHub, 15.11.2021).
- 4.1.1 Validity vs. well-formedness (WCAG issue tracker on GitHub, 18.01.2022).
- F70 goes beyond WCAG 4.1.1 #2187 (WCAG issue tracker on GitHub, 18.01.2022).
- Raghavendra Satish Peri:
Understanding SC 4.1.1 Parsing,
DigitalA11Y, 03.05.2022.
This blog post contains the following claim:HTML has certain standards & they apply very strongly here. You cannot have div tag inside a span & li tag inside a div without having ul or ol tags.
This claim misinterprets the success criterion as based on validation (content models) instead of syntax. The examples given do not violate the success criterion. -
WCAG – 4.1.1 Parsing (Level A),
HolisticA11Y, 09.03.2022.
The “Design Guide” section of this article contains the following recommendation:If you’re using the ARIA role attribute, look at the role’s definition in the W3C ARIA 1.1 specifications to check whether you’re nesting elements with that role correctly.
Although this is good advice, it is not relevant to success criterion 4.1.1. -
4.1.1 Parsing (A),
Modern Accessibility, 03.06.2022.
This blog post erroneously claims thatHTML code must conform to the standard identified in the doctype statement
. This goes far beyond the intent of the success criterion.
Futher down the page, the author claims,For example, the website must be following these rules: Validate Web pages, Fully conform specifications, (…)
. The author probably does not understand that the technique documents are not normative. - Bewertung von 9.4.1.1 #269 (BIK-BITV issue tracker on GitHub, 14.06.2022).
-
Erfolgskriterium 4.1.1 Syntaxanalyse (Parsing),
Zweiter Blick, 13.05.2022.
This article does not appear to make a distinction between correct syntax and valid code.
Discussions on How to Check Conformance
Discussions about how to check conformance to this criterion and its potential removal from future versions of WCAG:
-
Re: Question on 4.1.1 Parsing - what it covers: posted to the WCAG mailing list by Sailesh Panchang on 12 January 2016.
About parsing only bookmarklet:
I see it also flags errors like:
Error: Attribute ng-controller not allowed on element body at this point.
(…) I do not believe flagging invalid attributes is within the scope of SC 4.1.1. - Faulkner, Steve: WCAG 2.0 Parsing Criterion is a PITA, Paciello Group blog, 20.11.2015.
- WCAG Issue #542: 4.1.1 Parsing - Duplicate attributes with no user impact cause a conformance failure: submitted on GitHub in November 2018 and closed on 6 June 2019.
-
WCAG Issue #770: Deprecating SC 4.1.1:
submitted on GitHub in June 2019. The discussion on the previous issue is continued here.
See also 4.1.1 depreciation discussion on the working group's mailing list (starting 20 September 2019). The initial responses mostly support withdrawing the proposal to deprecate SC 4.1.1. Wilco Fier's message from 21 September 2019 provides arguments to deprecate it.
Alastair Campbell's message from 22 September 2019 includes a list of what tool testers test for when checking SC 4.1.1. This includes many content model issues, i.e. issues that go beyond correct syntax. - 4.1.1 depreciation discussion: discussion thread on the AGWG's mailing list, started on 20.09.2019.
- Re: SC 4.1.1 source fails but DOM passes - must a page fail? Sent to the WAI-IG mailing list on 11.01.2019.
Removing SC 4.1.1 from WCAG
In January 2023, the Accessibility Guidelines Working Group decided to remove success criterion 4.1.1 from WCAG 2.2;
see Re: CFC - Removing 4.1.1 Parsing from WCAG 2.2 on the working group's mailing list (12 January 20223).
The GitHub issue Do not remove 4.1.1 Parsing from WCAG 2.2 was closed as a consequence of this decision.
The GitHub issue Proposal to Rephrase Success Criterion 4.1.1 remained open, but with a note saying,
Noting that this has been removed this from WCAG 2.2, but leaving open for potential updates to 2.1/2.0
.
Success criterion 4.1.1 was removed from the Candidate Recommendation Draft of 25 January 2023.
For reactions and feedback on this decision, see, for example, the following resources:
-
Steve Faulkner on Twitter, 14.12.2022:
I personally and as a representative of @TPGinteractive at @w3c support the removal of success criterion 4.1.1 Parsing from the WCAG 2.x guidelines
.
The tweet includes a link to Alastair Campbell's message “Removing 4.1.1” to the AGWG mailing list from 13.12.2022. - Roselli, Adrian:
The 411 on 4.1.1,
Adrian Roselli, 05.12.2022, updated on 14.12.2023.
The blogpost was updated to add a link to the blogpost The Troublesome Life and Lamentable Death of Success Criterion 4.1.1by one of the original authors of SC 4.1.1
. Both the orginal post and the update carefully avoid naming the author (unlike the names of other accessibility experts). -
Paul J. Adam on Twitter, 14.12.2022:
I personally and as a representative of #a11y Do Not support the removal of 4.1.1 Parsing or any other WCAG success criteria!
.
In response to a tweet asking why he did not support the removal, Paul J. Adam added,4.1.1 Parsing is useful to get folks to fix their duplicate IDs and validate their code. I don't support removing any SCs in general either.
Scott O'Bother's response to this:it's rather unfortunate that you continue to take this standpoint, particularly since I clearly wasted so much time attempting to educate you that your objection to its removal is based on a misunderstanding of what the SC actually requires.
- Avila, Jonathan: WCAG 2.2 Update: It’s Time to Say Goodbye to the Parsing Criterion, LinkedIn, 02.02.2023.
- Microsoft WCAG 2.2 CR2 Feedback: Support for 4.1.1 Parsing removal (in *both* WCAG 2.2 and earlier), submitted to the AGWG's issue tracker on GitHub on 17.02.2023.
- Avila, Jonathan: WCAG 2.2 Status Update: What’s the Hold-Up?, Level Access blog, 02.02.2023. (This blog post is not primarily about the removal of success criterion 4.1.1.)
- Strobbe, Christophe:
The Troublesome Life and Lamentable Death of Success Criterion 4.1.1,
Eleven Ways • Digital Accessibility Lab on Medium, 09.02.2023.
This article was listed in issue #332 (20.02.2023) of Accessibility Weekly.
The Accessibility Guidelines Working Group also discussed what to do with success criterion 4.1.1 in WCAG 2.0 and WCAG 2.1.
- CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1 by Alastair Campbell, 08.03.2023.
- Re: 4.1.1 Parsing in WCAG 2.0 and 2.1 by Alastair Campbell, 09.03.2023, lists several arguments that have been given for removing the success criterion.
- Formal Objections (was: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1) by John Foliot, 09.03.2023.
- Re: Formal Objections (was: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1) by John Foliot, 13.03.2023.
- Re: Formal Objections (was: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1) by Chaals Nevile, 15.03.2023. The author objects against modifying WCAG 2.0 and 2.1 but could live with creating something like WCAG 2.01 and 2.11.
- 4.1.1 Parsing in WCAG 2.0 and 2.1 - take 2
by Alastair Campbell, 15.03.2023.
One of the suggestions is to add a note such as the following:NOTE: This SC should be considered as automatically met for any content using HTML. Modern browsers all have automatic error correction for parsing errors, and issues such as incorrect states or names due to a duplicate ID, or missing roles due to inappropriately nested elements are covered by different success criteria. This SC can therefore be ignored as being redundant. It no longer provides any benefit to people with disabilities in itself and should not be enforced or required for accessibility.
There is discrepancy between the scope of the success criterion, which covers all markup languages, not just HTML, and the suggested note, which ignores all markup languages that are not HTML.