Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecating SC 4.1.1 #770

Open
WilcoFiers opened this issue Jun 6, 2019 · 35 comments

Comments

Projects
None yet
@WilcoFiers
Copy link

commented Jun 6, 2019

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:

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

This comment has been minimized.

Copy link

commented Jun 6, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

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

This comment has been minimized.

Copy link

commented Jun 6, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

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

This comment has been minimized.

Copy link

commented Jun 6, 2019

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

This comment has been minimized.

Copy link

commented Jun 6, 2019

@Ryladog

This comment has been minimized.

Copy link

commented Jun 6, 2019

@jake-abma

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

Clear, added to MATF doc to discuss, thanks!

@awkawk

This comment has been minimized.

Copy link
Member

commented Jun 6, 2019

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

This comment has been minimized.

Copy link

commented Jun 6, 2019

+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

This comment has been minimized.

Copy link

commented Jun 6, 2019

@dd8

This comment has been minimized.

Copy link

commented Jun 7, 2019

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

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

This comment has been minimized.

Copy link

commented Jun 7, 2019

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

This comment has been minimized.

Copy link
Author

commented Jun 7, 2019

@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

This comment has been minimized.

Copy link

commented Jun 7, 2019

@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

This comment has been minimized.

Copy link
Member

commented Jun 7, 2019

@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

This comment has been minimized.

Copy link
Member

commented Jun 7, 2019

I would like it to also be relevant to ePub.

@Ryladog Epub uses markup so it does apply already.

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Jun 8, 2019

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

This comment has been minimized.

Copy link
Member

commented Jun 8, 2019

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

This comment has been minimized.

Copy link

commented Jun 9, 2019

@mraccess77

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2019

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

This comment has been minimized.

Copy link

commented Jun 12, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2019

@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

This comment has been minimized.

Copy link
Member

commented Jun 12, 2019

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

@jake-abma

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2019

Also mixed native AND custom elements in the mix, makes browsers go... lost

@dd8

This comment has been minimized.

Copy link

commented Jun 12, 2019

I think requirement 2 (nested according to their specifications) is still needed in some form:

  1. Although the HTML parsing algorithm prevents nesting elements like an h2 inside an h1 element, there's often a way to create an equivalent illegal nesting using ARIA.

The HTML parsing algorithm automatically fixes nested headings, so <h1>Heading 1<h2>Heading 2</h2></h1> turns into <h1>Heading 1</h1><h2>Heading 2</h2> in the DOM. This produces sensible output in a screen reader. This handling of nested headings is specified here:
https://www.w3.org/TR/html5/syntax.html#the-in-body-insertion-mode

Unfortunately, ARIA allows you to add role=heading to elements that are legal to nest in HTML, and the HTML parsing algorithm doesn't take account of ARIA roles, so you can do this:

<div role='heading' aria-level='1'>First level heading
    <div role='heading' aria-level='2'>Second level heading</div>
</div>

This gives very confused output in a screen reader:
https://www.powermapper.com/tests/screen-readers/headings/aria-role-heading-nested/

  1. The parsing algorithm does fix nested interactive elements of the same type ( button inside button and a inside a) but doesn't fix nested interactive elements of different types, such as an a element inside button so requirement 2 is still needed to cover these cases.
<button onclick="alert('clicked')">
    Push Button
    <a href="#top">Link</a>
</button>

This reads as 'Push button link, button' in VoiceOver with Safari on macOS and it's very hard to interact with the link inside the button using the VO keys.

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Jun 13, 2019

<div role='heading' aria-level='1'>First level heading
    <div role='heading' aria-level='2'>Second level heading</div>
</div>

would that fail 1.3.1?

<button onclick="alert('clicked')">
    Push Button
    <a href="#top">Link</a>
</button>

would that fail 2.4.3 focus order?

@dd8

This comment has been minimized.

Copy link

commented Jun 13, 2019

would that fail 2.4.3 focus order?

It's unclear if it fails - you can tab to the link, but can't reach it using VO-Left-Arrow (next item) or VO-Command-L (next link).

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Jun 13, 2019

but the focus order is illogical even with a keyboard on desktop, as you'd be focusing on the outer button, THEN on the inner link.

@dd8

This comment has been minimized.

Copy link

commented Jun 13, 2019

but the focus order is illogical even with a keyboard on desktop,
as you'd be focusing on the outer button, THEN on the inner link.

But don't iframes work like that in some AT? In NVDA there's a tabstop on the iframe, then you tab to links inside the iframe.

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Jun 13, 2019

doesn't make it right or logical, but it's outside of author's control (likely/possibly to allow for keyboard scrolling)

@dd8

This comment has been minimized.

Copy link

commented Jun 13, 2019

Video elements with controls in Safari also exhibit the same tab focus pattern - focus goes to entire video first, then to play control inside video.

Presently nested controls are an unambiguous fail under 4.1.1, but I think this becomes harder to fail under 2.4.3 Focus Order given the pro and con arguments above.

@alastc alastc added the Normative label Jun 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.