WCAG 2.2 Removes 4.1.1 Parsing and How axe-core is Impacted

Earlier this year, for the first time ever the World Wide Web Consortium (W3C) proposed to remove a success criterion from WCAG 2. Success Criterion 4.1.1 Parsing ensures that pages written in markup languages like HTML and SVG are written in a way that allows browsers and assistive technologies to understand them consistently. Let’s take a look at why this got removed, how the W3C plans to make this change, and how this impacts Deque products.

Why 4.1.1 Parsing gets removed

The text of success criterion 4.1.1 Parsing is as follows:

4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)

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.

This was an important requirement before HTML 5. Prior versions of HTML did not describe how invalid markup should be handled. Such markup could work one way in today’s browser, and work differently tomorrow. This was particularly impactful to people who relied on assistive technologies. So when HTML 5 standardized how browsers should handle invalid markup, it created a guarantee that if invalid markup worked today, it would work with all future browsers.

Few accessibility testers apply 4.1.1 Parsing as it was originally intended. Axe-core, for example, only tests for duplicate IDs, as those can cause incorrect labels and properties for assistive technologies. Since axe-core 3.1, we list duplicate IDs that cannot impact accessibility as a minor issue. But the reality is that duplicate IDs are an indicator of an accessibility problem, they are not an accessibility problem in and of themselves. Real accessibility problems currently reported under 4.1.1. Parsing are problems already covered under different WCAG criteria.

Rollout in WCAG and elsewhere

Removing a criterion from WCAG is a tricky problem. WCAG 2.0 and 2.1 are international standards and they are adopted into laws and regulations. Changing these is difficult and introduces long transition periods. So instead, the W3C decided on a two-prong strategy:

• For WCAG 2.2 (which is not yet finalized) criterion 4.1.1 Parsing will be removed. It is no longer required, as it is no longer part of the standard.
• For WCAG 2.1 and 2.0 (which are finalized) a note will be added to criterion 4.1.1 Parsing. The note will indicate that 4.1.1 is always passed for HTML and XML content.

This note the W3C plans to add to WCAG 2.0 and 2.1 is a bit of a trick, in that it doesn’t change the actual requirement. The criterion is what it always was. The only thing that changes is a clear intent on how the W3C believes the criterion should be interpreted. This allows everyone using WCAG 2.0 and 2.1 today to say “see, W3C says this passes”, even if that note isn’t in the older copies of WCAG that an organization is required to follow.

Will there be others?

It is a real triumph for web accessibility that technology has advanced enough that a success criterion is no longer necessary. Simultaneously, one may ask whether there are other parts of WCAG that could become obsolete by improving standards and browsers. The good news is that there are a variety of other notable improvements browsers have made.

All browsers these days support zoom, instead of solely relying on font resizing like was the case in 2008. More recently browsers started blocking automatically playing audio. Some browsers have an improved focus ring in their accessibility settings which content owners cannot override. Automated language detection exists in some browsers too (but is turned off by default). Several browsers also have reader modes now. The list goes on.

These efforts of individual browser vendors are great, but they need to be standardized. As was the case for parsing, code that works in one browser may not work in other browsers, or even in the next version of that same browser. Since no such standardization is happening, it is unlikely that despite the many advances, we’ll see any other WCAG 2 success criteria become obsolete in the next few years.

Deprecating rules in axe-core

Axe-core version 4.8, expected August 2023, will include changes to follow this update from the W3C. Axe-core currently has three rules to test success criterion 4.1.1 Parsing. All three of these are related to duplicate IDs.

Axe-core’s duplicate-id-aria rule will be reported under criterion 4.1.2 Name, Role, Value. This rule checks that IDs used in ARIA and accessible labels are not duplicated. This is important to look at, as it can result in controls having the wrong label or value. Because these aren’t a guaranteed accessibility problem, these results will be reported as “needs review” instead of as a violation.

The duplicate-id and duplicate-id-active rules check for IDs on elements where not having a unique ID has no impact on practical accessibility of the page. These two rules will be deprecated. This means that these will be disabled by default and that when axe-core 5.0 is released these rules will be removed. These rules have been given the “wcag2a-obsolete” tag for anyone who for backward compatibility reasons may temporarily still need to run these rules.

Related Reading

Want to learn more? Back in February, before the decision on WCAG 2.0 and 2.1, Christophe Strobbe wrote a great article on The Troublesome Life and Lamentable Death of Success Criterion 4.1.1. Christophe was involved in the original writing of criterion 4.1.1 Parsing back in WCAG 2.0, and last year started the issue that led to its removal.