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.