Deprecating SC 4.1.1

[WilcoFiers]

The top card of this issue will be updated as this work progresses

The purpose of this issue is to determine whether or not WCAG 2.1, success criterion 4.1.1 Parsing is still relevant to the accessibility of web content for people with disabilities. The web accessibility landscape has changes significantly since this criterion was proposed in 2008. Many accessibility experts are of the opinion that this success criterion is largely irrelevant, and that the part that is still relevant is addressed by other success criteria. If this is true, success criterion 4.1.1 could potentially be deprecated as part of WCAG 2.2.

Plan of Action

For this proposal, we'll go through the following steps:

1. Identify categories of conformance issues that need to be tested [ready for review]
2. Identify which markup languages require testing [in progress]
3. Determine which assistive technologies need to be tested
4. Create test cases, and perform assistive technology tests
5. Analyse the results and create a proposal for WCAG 2.2

Background

Web technologies have developed significantly since the creation of WCAG 2.0, where this success criterion was introduced. In HTML 4.01 and older versions, there was no description of what to do with malformed HTML. This caused HTML parsers to behave differently in different environments. HTML 5.0 included a detailed definition of how to parse malformed HTML. This has ensured that all modern browsers parse HTML exactly the same way.

The second reason why 4.1.1 was relevant in 2008, was because assistive technologies frequently had their own build-in HTML parser. Rather than rely on the browser to build up the accessibility tree, assistive technologies would build their own accessibility tree based on the HTML of a page. Improvements in browsers and standardisation efforts have made the accessibility trees more reliable. Assistive technologies in 2019 use the accessibility tree directly, rather than parse HTML and build their own.

Step 1: Breakdown of 4.1.1 Parsing

Scope

Success criterion 4.1.1 is applicable to all content implemented in markup languages.

Requirement 1

Elements have complete start and end tags.

This requirement can be broken down further:

1. A closing tag exists for each element that require a closing tag (such as main, h1, strong, etc.)

2. None of the closing tags are for elements that do not allow closing tags (such as img, input, meta, etc.)

3. Each closing tag has a corresponding opening tag positioned before the closing tag of its parent node (e.g. <div><h1></h1></div> rather than <div><h1></div></h1>)

Requirement 2

Elements are nested according to their specifications.

1. The root node of a document is an element that is allowed as the root node (e.g. html is the root of HTML documents, and svg for SVG documents)

2. Each child node of an element is of a type allowed in its content model. (e.g. p is allowed strong, but not h1)

Requirement 3

Elements do not contain duplicate attributes.

This requirement is often "expanded" to mean attributes must be marked up correctly.

1. Elements do not contain duplicate attributes (e.g. <p class="foo" class="bar">...</p> should be <p class="foo bar">...</p>, and <input readonly="readonly" readonly> should be<input readonly>)

2. Unquoted attributes (under certain circumstances) * (e.g. <p id=alexander-'the-great'> should be <p id="alexander-'the-great'"> or <p id=alexander-the-great>)

3. Mismatched quotes on attributes * (e.g. <p id="main'> should be <p id="main"> or <p id='main'>)

4. Attributes not space separated * (e.g. <p id="main"class="main"> should be <p id="main" class="main">)

5. Attributes are not malformed * (e.g. <p id:"main"> should be <p id="main">))

*: It is debatable whether or not points 2 through 5 are required by the success criterion. Either way it is worth exploring whether or not these cause accessibility issues.

The same attribute and attribute + value combination can exist on different elements, just not on the same element.

Requirement 4

Any IDs are unique.

1. IDs used in IDREFs are unique (e.g <label for="name">name</label><input id="name">)

2. IDs used referenced by internal links are unique (e.g <h1 id="hd1"><a href="#hd1">Heading 1</a></h1>)

3. IDs used on user interface components are unique (e.g <button id="submit">Submit</button>)

4. IDs used on any element unique (e.g <p id="my-style-be4d-c66d4b51819f">...</p>)

Note 1: IDs in different DOM trees are not required to be unique. The same ID can exist in different shadow DOM trees, since ID referencing across different trees is not valid.

Note 2: Elements hidden through CSS are not allowed duplicate IDs. IDREFs work regardless of if an element is visible. For example, aria-labelledby can use hidden elements for the computation of an accessible name.

Step 2: Scope "Markup languges"

In order for any markup language to be relevant for SC 4.1.1 Parsing, it must meet the following requirements:

• It can be served as a web page
• It is supported by assistive technologies
• It is implemented in a user agent

Markup Language	Web Page	User Agent	Assistive Technology
HTML: The Markup Language	Yes	Web Browsers
SVG: Scalable Vector Graphics	Yes	Web Browsers
MathML: Mathematical Markup Language
SMIL: Synchronized Multimedia Integration Language
TTML: Timed Text Markup Language
EmotionML: Emotion Markup Language
EMMA: Extensible MultiModal Annotation markup language
InkML: Ink Markup Language
VoiceXML: Voice Extensible Markup Language
SSML: Speech Synthesis Markup Language

To do: Fill out the table

Step 3: Assistive Technologies

TBD as part of step 3.

Step 4: Testing

TBD as part of step 4.

Step 5: Conclusion And Recommendations

TBD as part of step 5.

[bruce-usab]

Let’s be sure to drag @stevefaulkner into this discussion!
Here is a link to his parsing bookmarklet (2/25/19). Per his comments, Steve seems to think 4.1.1 might still have utility.

[mraccess77]

We often see links inside of buttons and other nesting issues that aren't clearly covered by SC but don't work well with assistive technology. This is the type of issue that 4.1.1 may still be needed for.

[DavidMacDonald]

Excellent start of this discussion @WilcoFiers . There are two minor corrections about the intent of the Success Criteria parts, from my memory of when we wrote it.

Requirement 1: Elements have complete start and end tags.

This was a very simple requirement that anything that opened needed to be closed (if closing it is in the spec). Your example of <div><h1></div></h1> would fall under your examples of the second requirement about nesting. An example of this that I would give would be
<h1>La la<p> more lala</p>
with no close to the h1.

Requirement 2:
I would put your example from #1 here.
<div><h1></div></h1>
In addition to your discussion of nodes.

[mraccess77]

The other part of this discussion was that issues with duplicate ids that impacted the user such as references to labels and aria-labelledby, etc. would be caught under other SC like 1.3.1 and 4.1.2. So I think people agree that duplicate ids can be an issue -- but they generally result in violations to other SC -- @WilcoFiers this is an important concept to capture in the doc.

[bruce-usab]

@mraccess77 wrote:

We often see links inside of buttons and other nesting issues that aren't clearly covered by SC but don't work well with assistive technology. This is the type of issue that 4.1.1 may still be needed for.

Jon, could you post a cleanish example of this? (On a live page somewhere.) It seems to me like the simplest way to resolve this issue would be a single example demonstrating that we still need 4.1.1 (at least for now).

[jake-abma]

I know of lots of wrongly nested roles when using ARIA which this SC should cover, but doesn't, as it only speaks of "elements". Same Jon talks about... 4.1.2. Passes but still confuses UA/AT like role button nested in role textbox. Enough to add/extend in Understanding doc OR new SC?

[bruce-usab]

Enough to add/extend in Understanding doc OR new SC?

I feel pretty strongly that this should be new SC. I think it is okay that an SC written in 2008 misses catching common mistakes developers make with ARIA. I am not really okay with changing Understanding to have new normative requirements. Likewise, I feel like the note attached to 4.1.2 should really guide our saying if some particularly poor code fails 4.1.2 or not.

[johnfoliot]

+1 to Bruce - a new SC rather than modifying the intent & scope of the original 4.1.1 JF

…

On Thu, Jun 6, 2019 at 12:35 PM bruce-usab ***@***.***> wrote: Enough to add/extend in Understanding doc OR new SC? I feel pretty strongly that should be a new SC. I think is okay that an SC written in 2008 misses ARIA. I am not really okay with saying that 4.1.1 catches wrongly nested ARIA roles. Likewise, I feel like the note attached to 4.1.2 should really guide our saying if some particularly poor code fails or not. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#770?email_source=notifications&email_token=AAJL445COETPIHFAFTEDLSTPZFDGLA5CNFSM4HVAQSU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXDTF3Y#issuecomment-499593967>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJL44YIQLHUGEK7UWTAYZLPZFDGLANCNFSM4HVAQSUQ> .

-- *​John Foliot* | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com

[Ryladog]

+1 to new SC

…

On Thu, Jun 6, 2019, 1:46 PM John Foliot ***@***.***> wrote: +1 to Bruce - a new SC rather than modifying the intent & scope of the original 4.1.1 JF On Thu, Jun 6, 2019 at 12:35 PM bruce-usab ***@***.***> wrote: > Enough to add/extend in Understanding doc OR new SC? > > I feel pretty strongly that should be a new SC. I think is okay that an SC > written in 2008 misses ARIA. I am not really okay with saying that 4.1.1 > catches wrongly nested ARIA roles. Likewise, I feel like the note attached > to 4.1.2 should really guide our saying if some particularly poor code > fails or not. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > < #770?email_source=notifications&email_token=AAJL445COETPIHFAFTEDLSTPZFDGLA5CNFSM4HVAQSU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXDTF3Y#issuecomment-499593967 >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AAJL44YIQLHUGEK7UWTAYZLPZFDGLANCNFSM4HVAQSUQ > > . > -- *​John Foliot* | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#770?email_source=notifications&email_token=ABL6VSVJRHQP4IKKNGBKQITPZFEN5A5CNFSM4HVAQSU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXDUC4I#issuecomment-499597681>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABL6VSQEDC3NW3V7677C7ITPZFEN5ANCNFSM4HVAQSUQ> .

[jake-abma]

Clear, added to MATF doc to discuss, thanks!

[awkawk]

Much of the discussion on #542 was around deprecating 4.1.1 if it can be demonstrated that issues that are flagged as 4.1.1 issues all either are issues against other SC. It sounds like the discussion is at least partly around adding a new SC to capture aria-related issues. Is it reasonable to address these as separate questions and issues?

[bramd]

+1 for a new SC.

I've seen 4.1.1 used to argue that a PDF document should have a Document element at the root of it's tag tree. While I think it is a bit of a stretch to see a PDF tag structure as a markup language, it clearly has properties in common with markup languages.

So, if we go the route of a new SC to express that only valid nested roles are allowed, it would be good to think of the above case as well. Basically, I think we would like to see that people don't put things in something that is eventually rendered to an accessibility tree that mess up the resulting role structure. It being HTML, ARIA, a PDF tag tree or may be in the future an accessibility tree generated by some javascript.

[Ryladog]

I would like it to also be relevant to ePub.

…

On Thu, Jun 6, 2019, 5:56 PM Bram Duvigneau ***@***.***> wrote: +1 for a new SC. I've seen 4.1.1 used to argue that a PDF document should have a Document element at the root of it's tag tree. While I think it is a bit of a stretch to see a PDF tag structure as a markup language, it clearly has properties in common with markup languages. So, if we go the route of a new SC to express that only valid nested roles are allowed, it would be good to think of the above case as well. Basically, I think we would like to see that people don't put things in something that is eventually rendered to an accessibility tree that mess up the resulting role structure. It being HTML, ARIA, a PDF tag tree or may be in the future an accessibility tree generated by some javascript. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#770?email_source=notifications&email_token=ABL6VSVKDJHZNTGODQFC7U3PZGBYHA5CNFSM4HVAQSU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXEI4SY#issuecomment-499682891>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABL6VSXYAFFCNZW2JRRW4ILPZGBYHANCNFSM4HVAQSUQ> .

[dd8]

The other part of this discussion was that issues with duplicate ids that impacted the user such as references to labels and aria-labelledby, etc. would be caught under other SC like 1.3.1 and 4.1.2. So I think people agree that duplicate ids can be an issue -- but they generally result in violations to other SC

Here's a list of HTML / SVG / MathML features that use ID references taken from the relevant recommendations - that should help in figuring out whether duplicate IDs can have an impact not covered by other SC:

Element	Attribute	Spec
a	href # id	HTML 4.01
label	for	HTML 4.01
td	headers	HTML 4.01
th	headers	HTML 4.01
input	list	HTML 5
output	for	HTML 5
(any form element)	form	HTML 5
(any element)	itemref	HTML 5
(any MathML element)	xref	MathML 3
(any SVG element)	(various)	SVG 2

• HTML 4.01 - ID references use IDREF type:
  https://www.w3.org/TR/html4/sgml/loosedtd.html
• XHTML 1.0 - ID references use IDREF type:
  https://www.w3.org/TR/xhtml1/dtds.html
• HTML living standard - ID references scattered around normative text
  https://html.spec.whatwg.org/multipage/indices.html#attributes-3

The SVG recommendation says IDs should be unique within the node tree - that has implications for SVG embedded in HTML:
https://www.w3.org/TR/2018/CR-SVG2-20181004/struct.html#Core.attrib

The MathML 3 recommendation is inconsistent about whether IDs should be unique. This normative text says id is a unique reference:
https://www.w3.org/TR/MathML3/chapter2.html#fund.globatt
but the MathML DTD intentionally allows IDs to be duplicated - see MMLIDTYPE in the DTD:
https://www.w3.org/Math/DTD/mathml3/mathml3.dtd

Of note: there's also a section in the MathML 3 recommendation explaining how things like complete end tags and attribute quotes are not required for MathML in HTML:
https://www.w3.org/TR/MathML3/chapter6.html#interf.html

[dd8]

The use of duplicate IDs referenced in links via href=otherpage.html#targetid may be hard to map to another SC because the conformance requirements apply to full pages or complete processes, and the link may come from outside those.

Ending up on the wrong part of the target page is difficult for people using magnifiers or screen readers.

[WilcoFiers]

@dd8 Thanks for the list. That would have taken me a while to put together.

Enough to add/extend in Understanding doc OR new SC?

I agree with what most people are saying here, a new SC would be preferable.

Update

I've updated Requirement 3 in the top post, to include some of the attribute tests that Steve Faulkner's bookmarklet treats as failures for SC 4.1.1. I'm going to create a Doodle poll next for some of the people who volunteered to help work on this to come up with next steps.

[dd8]

@dd8 Thanks for the list. That would have taken me a while to put together.

There are some missing since IDs can be used in any URL after the # character, so that means any href or src attribute (and there are many other attributes that contain URLs such as longdesc).

Fragments in URLs can only cause dupe id problems if the content type referenced can contain IDs. For example, the fragment in <img src='map.png#iceland'> has no meaning for PNG graphics and works identically to <img src='map.png'> , but <img src='map.svg#iceland'> should display Iceland if map.svg contains id='iceland' and there's obviously a problem for the user if more than one country on the map is identified as Iceland.

An example that currently fails SC 4.1.1 but needs considered if the SC is removed/replaced are skip links linked to duplicated IDs:

<a href='#main'>Skip to content</a>
<div id='main'>...</div>
<div id='main'>...</div>

There's also an ambiguity on img usemap due to spec churn:

• in HTML 5 usemap refers to map name again but via a 'hash-name reference' instead of a URL
• in XHTML 1.1 usemap refers to map id via a URL and name was removed
• in XHTML 1.0 usemap refers to map id via a URL and name was deprecated
• in HTML 4.01 usemap refers to map name via a URL

[awkawk]

@dd8 This doesn't necessarily fail any other SC - it may fail 2.4.1 Bypass blocks if the user agents make the skip link go to the wrong place, but if the user agents make the skip link go to the right place then functionally it is fine for users.

[awkawk]

I would like it to also be relevant to ePub.

@Ryladog Epub uses markup so it does apply already.

[patrickhlauke]

The use of duplicate IDs referenced in links via href=otherpage.html#targetid may be hard to map to another SC because the conformance requirements apply to full pages or complete processes, and the link may come from outside those.

Ending up on the wrong part of the target page is difficult for people using magnifiers or screen readers.

Question is probably if it's a problem for all users, or something that disproportionately affects users with disabilities?

[patrickhlauke]

We often see links inside of buttons and other nesting issues that aren't clearly covered by SC but don't work well with assistive technology. This is the type of issue that 4.1.1 may still be needed for.

I'd flag that under focus order, generally

[Ryladog]

Andrew, Ooops, you are right, it does have elements! Thanks! ** katie **

[mraccess77]

Bruce, we come across situations like the following
<a href="http://www.google.com">
<input type="checkbox" aria-label="I agree to the terms"> I agree to the terms
</a>

<div role="button" tabindex="0"aria-label="Visit Google">
<a href="http://www.google.com"> <span class="backgroundimage"></span> </a>
</div>

<a href="http://www.google.com">
<button><span class="backgroundimage"></span> </button>
</a>

[bruce-usab]

@mraccess77 is that three examples or just one? I am reading it as three, but also I am not seeing how any of those fail against what 4.1.1 catches. Maybe not “nested according to their specification”? I feel like I need a more complete code sample to evaluate that.

[mraccess77]

@bruce-usab HTML specification does not allow button inside of anchor, anchors inside of buttons, or inputs inside of anchors. So yes, these are 3 examples of nesting issues that can have impact on some AT in different ways.

[awkawk]

@mraccess77 It would be great to see functioning examples for those cases.

[jake-abma]

@mraccess77 It would be great to see functioning examples for those cases.

I've been involved in features where this had been implemented dozens of times the last 2/3 years. Specially for sites where they use / create custom components / web components (with lots of ARIA). Problem is focus / programmatic associated descriptions / label / names gets mixed, not communicated properly or skipping of elements when Tabbing / Shift tabbing UICs. Also inconsistency in Tabbing OR Shift tabbing. (skipping one direction, not other direction).

[jake-abma]

(my opinion: all of Robust should go, they are only means to make content P, O, and U... ;-) and place 4.1.3 under Perceivable / Adaptable)

[patrickhlauke]

My recollection is that we decided to defer to 2.3, if there is a 2.3

@alastc could I suggest changing the label for this in that case?

[DavidMacDonald]

PROPOSED RESPONSE:

Out of an abundance of caution for backwards compatibility, and a desire not to cause confusion in the accessibility community over what removing 4.1.1 would mean, and concern about the number of group cycles that would be used up trying to achieve consensus which has been illusive on this issue, and also understanding the long history of 4.1.1 and validation discussions in general, we have decided not to deprecate this SC in WCAG. 2.2.

@alastc (READY FOR SURVEY)

[patrickhlauke]

in terms of confusion in the accessibility community, i actually see a lot more confusion currently over what exactly counts as a normative failure or not. any error reported by the HTML validator? or just a subset, and if so which ones? what about CSS, does that need to pass validation? what about markup that is sent invalid, but consistently error-corrected by browsers, or modified client-side and corrected via JS? similarly, how/when should authors check validity...just checking what the server sends, or checking the rendered DOM in browser after scripts/etc have had a chance to run? do they also need to test whenever some script generates new structures or otherwise modifies the existing DOM? when using ARIA, does an error in ARIA attributes/values count as a failure of 4.1.1? does it need to pass ARIA-in-HTML rules?

IF 4.1.1 is to be retained, the understanding document should really clarify the situation a lot more.

[cstrobbe]

<label class='gfield_label' for='input_11_6' >
Birthday <span id='field_11_6_dmessage' class='sr-only'> - must be mm/dd/yyyy format</span>
</label>

<input aria-describedby='field_11_6_dmessage' 
name='input_6' id='input_11_6' type='text' 
value='' class='datepicker medium mdy datepicker_no_icon'   placeholder='Birthday'  
aria-describedby='input_11_6_date_format' />

<span id='input_11_6_date_format' class='screen-reader-text'>Date Format: MM slash DD slash YYYY</span>

This is arguably not a failure in because the information in the second aria-describedby=input_11_6_date_format is nearly identical to the first aria-describedby=field_11_6_dmessage (the first one is voiced, but the second one gives better instructions when AT is set to not announce punctuation)

Nobody seems to have noticed that the code does actually violate SC 4.1.1 because of the duplicate aria-describedby attribute on the input element. This does not require interpretation, unlike the question whether the code violates SC 4.1.2.

[JAWS-test]

Decision Discussion: https://www.w3.org/2022/11/15-ag-minutes.html#item03

[alastc]

Um, I wouldn't call that a decision yet. There is support for the deprecation, the form of that is on the survey for next week.

[bruce-usab]

It was a very interesting discussion! My gratitude to @tombrunet for mention of Jim Thatcher and IBM Screen Home Page Reader and tree versus graph!

Also thanks to @TzviyaSiegman for pointing us to w3c process for deactivation since "deprecating" might not be enough.

[tombrunet]

For clarity, and to record my comments - the issue was something I encountered when we created IBM Home Page Reader 3.x, particularly with the DOM walkers I was creating. IE's DOM parser at the time would stumble over things like <b>One<i>Two</b>Three</i>, which was a fairly common authoring mistake at the time. IE would generate a DOM where sibling nodes would not have the same parent, and sometimes would result in infinite loops when doing in-order tree traversals. We created work-arounds, but if not handled correctly, it could cause an AT to hang / freeze up, which is a huge barrier. So, I believe 4.1.1 was created as result of these early parser issues.

I noted on the call - parsers have matured a lot over the last 20 years, and newer specs are more clear on how to handle a variety of authoring mistakes in consistent ways. Invalid element nesting is still bad practice, but not the accessibility issue that it was 20 years ago.

[mgifford]

Shouldn't this be under the 4.1.1 Label?

[patrickhlauke]

if it makes you happy, @mgifford ... ;)

[alastc]

Current status: We're moving to deprecate (remove) 4.1.1 in WCAG 2.2. Not finalised yet, we'll need a CFC on that. If that passes this issue can be closed.

[cstrobbe]

The January 2023 Candidate Recommendation has marked SC 4.1.1 as obsolete and has removed the success criterion. Is this issue being kept open for the sake of WCAG 2.0 and/or WCAG 2.1?

[alastc]

We've now decided the actions for 2.2 (removal) and 2.1/2.0 (adding a note), so closing this issue.