New SC (4.1.4?): Native Child-Element Roles

[cstrobbe]

When people object to interpreting "elements are nested according to their specifications" as referring to syntax (see e.g. issue 2186 and issue 2525), they often give code examples that cause or may cause accessibility issues and that are caught by a validator but not by a pure syntax check. On the other hand, people also complain that validation catches too many errors that are irrelevant to accessibility. Some of the accessibility issues that would be caught by a validator but not by a syntax check constitute violations of SC 4.1.2 or 1.3.1 (or even both), whereas some issues are not violations of those other success criteria.
This proposed new success criterion tries to capture some of the issues that appear to fall between the cracks when "elements are nested according to their specifications" is interpreted as referring to syntax (but are not caught by other success criteria).

Proposed SC Text

In content implemented using markup languages, the following are true:

• Parent role: when an element used with its native role occurs as a child element of another element used with its native role, the parent and child elements are nested according to the content models defined in their specifications;
• Child and sibling role: when an element used with its native role occurs as a required child element of another element used with its native role, all of the parent's child elements are nested according to the content models defined in their specifications;
• Required child element role: when an element used with its native role requires child elements used with their native role, the parent and child elements are nested according to the content models defined in their specifications;
• Link role: links do not have other links, interactive elements or keyboard-focusable elements as descendants.

Note: This success criterion only applies to elements that are exposed through an accessibility API.

Proposed Understanding Text

Intent

The intent of this success criterion is to make sure that elements with native roles are nested in such a way that their name, role, state and value can unambiguously be exposed through an accessibility API. Correct exposure through an accessibility API may require that element A is always nested inside elements X, never nested inside element Y or a combination of such nesting requirements.

Some elements that are natively exposed through an accessibility API can only be used as child elements of other elements, in other words, they are required child elements of those other elements. If another element is inserted such that the parent-child relationship is disrupted, user agents and assistive technologies are not always able to recover from this and expose the elements' roles correctly.

In HTML, the following are examples of required child elements with native roles:

• li, which can only occur within either ul, ol or menu, which are also elements with native roles;
• th and td, which can only occur within tr, which in turn can only occur within other table elements (thead, tbody, tfoot or table),
• legend, which can only occur within a fieldset element.

For elements such as the above, disrupting the hierarchy of required child elements can lead to incorrect or incomplete exposure roles through accessibility APIs.

Some parent elements expect child elements that are all of the same type. For example in HTML, the ul elements requires child elements that are all of the type li; other element types, such as p, are not reliably exposed as list items.

Certain other elements aren't required child elements of other elements but have native roles that may not be exposed correctly when used as child elements of other elements with a native role. In HTML, these elements include links (a elements with an href attribute), form elements, buttons and headings. When links or interactive elements occur as descendants of links, this can interfere with the role that is exposed through an accessibility API. In this case, it is the nesting of roles that causes ambiguity about the role that should actually be exposed.

The first three requirements in the success criterion look at elements from three different perspectives in order to cover parent, child and sibling relationships. The fourth requirement specifically focuses on links because authors sometimes erroneously use interactive elements as descendants of links. The phrase "interactive elements or keyboard-focusable elements" makes sure that interactive elements that authors have not made keyboard accessible are also covered.

"Content models" refers to the formal or informal descriptions in markup language specifications that define what each element in a specification may or must contain. For example, in HTML, the content model for ul only allows li elements as child elements. The content model for div, by contrast, allows a wide range of other elements, including the recursive nesting of div elements. Content models may be expressed using a formal grammar, such as a DTD, or in natural language. For example, in HTML 5, the rule that links must not be nested is expressed in natural language. The term "content model" has been in use for a long time; it has been used in the context of SGML, HTML 4 and older SGML-based versions of HTML, XML and HTML 5.

The phrase "nested according to the content models defined in their specifications" is used for two reasons. First, it leaves no doubt whether it refers to syntax (as in XML's concept of well-formedness, for example) or to validity. Second, the term "nesting" itself is too ambiguous to use on its own because it can refer to both parent-child nesting and to other ancestor-descendant relationships. Referring to an element's content model removes this ambiguity.

Benefits

Making sure that this category of validation errors does not occur inside or or immediately around elements with a native role helps ensure that assistive technologies can present the content accurately.

Related Resources

• HTML Accessibility API Mappings 1.0

Techniques

[Boiler plate "Each numbered item in this section represents ..." goes here.]

Sufficient Techniques

1. G134: Validating Web pages
2. G192: Fully conforming to specifications
3. H88: Using HTML according to spec

(These are all techniques for SC 4.1.1. They all go slightly beyond what both SC 4.1.1 and the proposed SC require.)

Failures

• Failure of Success Criterion 4.1.4 due to using an interactive or keyboard-focusable element inside a link.
• Failure of Success Criterion 4.1.4 due to using a heading as a child element of a link.

Examples

To illustrate the proposed SC, this section lists code examples that have been posted in discussions about "elements are nested according to their specifications" in SC 4.1.1. For each code example, this section states

• whether it fails or passes the syntax interpretation of "elements are nested according to their specifications",
• whether it fails or passes the validation interpretation of "elements are nested according to their specifications",
• whether it fails or passes the proposed new success criterion.

Example 1

Source: a comment by Steve Faulkner on issue #2525. See also a comment by Mark Rogers on issue #770.

<button><a href="#"></a></button>

Both button and links are elements with native semantics. According to HTML 5, the button cannot contain any interactive content descendants, and therefore no links.

This example

• passes the syntax interpretation of SC 4.1.1,
• fails the validation interpretation of SC 4.1.1,
• fails the proposed SC's first requirement.

Example 2

Source: same comment as example 1.

<ul>
  <div>
    <li>
    <li>
  </div>
</ul>

li is a required child element of ul but here occurs as a child element of div, where it is not allowed.

This example

• passes the syntax interpretation of SC 4.1.1,
• fails the validation interpretation of SC 4.1.1,
• fails the proposed SC's first requirement.

Example 3

Inspired by the previous example, see my div inside ul test page.

<ul>
  <li>tomatoes</li>
  <li>onions</li>
  <li>beans</li>
  <p>potato chips!</p>
</ul>

The ul element requires li elements as child elements; both element types have native roles.

This example

• passes the syntax interpretation of SC 4.1.1,
• fails the validation interpretation of SC 4.1.1,
• fails the proposed SC's second requirement.

Example 4

Source: a comment by Alastair Campbell on issue #2525.

<button><h2>Thing</h2></button>

Both button and h2 have native roles but they are not nested according to specification: the button elements content model only allows phrasing content and thus prohibits headings.

This example

• passes the syntax interpretation of SC 4.1.1,
• fails the validation interpretation of SC 4.1.1,
• fails the proposed SC's first requirement.

Example 5

Source: inspired by a comment by Giacomo Petri on issue #2525.

<p><input id="username" name="username" type="text" /></p>
<p><label for="username">College:
  <select size="1">
    <option selected="selected">Foxe College</option>
    <option>Jordan College</option>
    <option>Wordsworth College</option>
  </select>
</label>

See my earlier discussion of this example. This example

• passes the syntax interpretation of SC 4.1.1,
• fails the validation interpretation of SC 4.1.1,
• passes the proposed SC.

The HTML specification does not define which type of labelling takes precedence: the one defined by the for attribute or the one based on nesting. Hence, the relationship between the label and the control it labels visually (i.e. the control below it) cannot be determined programmatically in an unambiguous manner. If browsers determine that the first input's accessible name is the label element (including its descendant, the select element), the code violates SC 1.3.1. The HML 5 spec needs to solve this ambiguity.

Example 6

Source: Detlev Fischer, issue #2186.

<span><h6>bla bla</h6></span>

h6 has a native rol but span doesn't.

This example

• passes the syntax interpretation of SC 4.1.1,
• fails the validation interpretation of SC 4.1.1 (but it causes no accessibility issues),
• passes the proposed SC because span has no native role.

Example 7

Source: Detlev Fischer, issue #2186.

<span href="../page.html">bla bla</span>

This does not involve elements with a native role. The code does not create a link but just normal text. The "link" does not work for anybody, regardless of ability. People with disabilities are not inconvenienced more than anybody else.

This example

• passes the syntax interpretation of SC 4.1.1,
• fails the validation interpretation of SC 4.1.1 (but it causes no accessibility issues),
• passes the proposed SC because span has no native role.

Example 8

Source: a comment by Mark Rogers on issue #978, but with added alt attribute.

<table>
  <img src="test.png" alt="Pass" />
  <tr>
    <td>Cell
  </tr>
</table>

table, tr and td have native semantics and are connected through required-child relationships. img also has a native role but is not correctly nested inside the table.

If, for simplicity's sake, we ignore HTML 5's adoption agency algorithm, this example

• passes the syntax interpretation of SC 4.1.1,
• fails the validation interpretation of SC 4.1.1,
• fails the proposed SC's second requirement because img is not allowed as a sibling of tr.

However, if Mark Rogers' interpration of the adoption agency algorithm is correct and browsers move the image before the table, this results in code that passes both the validation interpretation of SC 4.1.1 and the proposed SC.

Example 9

Source: same as previous example.

<form>
  <input name="one" />
  <form>
    <input name="two" />
  </form>
</form>

The input element has a native role but is not required as a child element of form since it may be wrapped in p, div, fieldset and other elements that can be used as descendants of form.

If, for simplicity's sake, we ignore HTML 5's adoption agency algorithm, this example

• passes the syntax interpretation of SC 4.1.1,
• fails the validation interpretation of SC 4.1.1 (beause nested forms are not allowed),
• fails the proposed SC's first requirement because form has a native role and nested forms are not allowed.

Example 10

Source: a comment by Mark Rogers on issue #770.

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

This example

• fails both the syntax and validation interpretations of SC 4.1.1 because duplicate IDs have nothing to do with nesting according to specification,
• passes the proposed SC because duplicate IDs are not something the SC tries to cover.

This is an exammple of an issue that would not be covered by any SC if 4.1.1 were simply removed.

Example 11

Source: a comment by Jonathan Avila on issue #770.

<a href="http://www.google.com">
  <input type="checkbox" aria-label="I agree to the terms"> I agree to the terms
</a>

This example

• passes the syntax interpretation of SC 4.1.1,
• fails the validation interpretation of SC 4.1.1 (the element input must not appear as a descendant of the a element),
• fails the proposed SC's fourth requirement (essentially for the same reason that it fails validation).

Example 12

Source: same as previous example (with a space inserted before the aria-label attributte).

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

This example

• passes the syntax interpretation of SC 4.1.1,
• fails the validation interpretation of SC 4.1.1 (the element a must not appear as a descendant of an element with the attribute role=button),
• passes the proposed SC because the proposal does not consider roles overwritten by other metadata (more on this below).

Example 13

Source: same as previous example.

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

This example

• passes the syntax interpretation of SC 4.1.1,
• fails the validation interpretation of SC 4.1.1 (the element button must not appear as a descendant of the a element),
• fails the proposed SC's fourth requirement (essentially for the same reason that it fails validation).

Example 14

Source: a comment by Mark Rogers on issue #770, dated 14 August 2019 (a real-world example).

<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 example

• fails both the syntax interpretation and the validation interpretation of SC 4.1.1 because the input has a duplicate aria-describedby attribute (this is not a matter of element nesting),
• passes the proposed SC because the SC is not designed to catch duplicate or conflicting form labelling methods.

However, the discussion of this code in the comments on issue #770 focused on whether the code failed SC 4.1.2 (is "accessible description" implicitly included in "accessible name"). Keeping SC 4.1.1 would be the easiest way to catch this issue.

Example 15

Source: a discussion on a11y Slack that started on 1 November 2021.
See also the discussion on the same Slack that started on 5 November 2021.

<input type="checkbox" id="xyz"><label for="xyz"> <a href="abc.html">a label that is also a link</a></label>

The content model for label allows "phrasing content", which includes a elements. (It does not allow descendant labellable elements except for the labelled control, nor descendant label elements.)
The code is an example of bad UX, but neither of the two discussion threads on Slack could identify a success criterion that was violated, with the possible exception of 2.5.5. However, the violation of SC 2.5.5 is easy to avoid by adding plain text inside the label before the a element.

This example

• passes the syntax interpretation of SC 4.1.1,
• passes the validation interpretation of SC 4.1.1,
• passes the proposed SC because the HTML 5 specification does not prohibit links inside labels.

Example 16

Source: a discussion on a11y Slack from 26 November 2020.

<h2><p>[heading text]</p></h2>

This example

• passes the syntax interpretation of SC 4.1.1,
• passes the validation interpretation of SC 4.1.1,
• fails the proposed SC's first requirement (see p element mapping to accessibility APIs).

Example 19

Source: issue 2620: Failure of Success Criterion 1.3.1 due to using th elements.

<div role="grid">
  <table role="presentation">
    <tr role="row">
      <th role="columnheader">Header
    </tr>
    <tr role="row">
      <td role="gridcell">data
    </tr>
  </table>
</div>

This example

• passes the syntax interpretation of SC 4.1.1,
• passes the validation interpretation of SC 4.1.1,
• passes the proposed SC because the proposal does not address explicitly assigned roles.

The W3C validator issues three warnings but no errors: "The row role is unnecessary for element tr." (for the first row), "The columnheader role is unnecessary for element th." and "The row role is unnecessary for element tr." (for the second rowp).
The validator appears to ignore the requirement that "the user agent MUST apply an inherited role of presentation to any owned elements that do not have an explicit role defined" (WAI-ARIA 1.2) and that the two tr elements would be presentational without an explicit role.

Questions

Elements Whose Native Role Is Overwritten

The proposed wording only considers elements used with their native roles. When metadata such as WAI-ARIA is used to redefine roles, should that be included in the SC? If yes, how should the requirement be worded? (Since WCAG is technology independent, we can't just write "WAI-ARIA roles are nested according to specification".)

Note that required owned elements aren't necessarily descendants.

More Real-World Examples?

I would like to see more real-world examples to find out how well the proposed SC holds up.

[patrickhlauke]

Link role: links do not have other links, interactive elements or keyboard-focusable elements as descendants.

not sure this needs to be singled out so specifically for links. the same issue can apply to buttons, or other interactive controls, that aren't allowed to have other interactive controls inside them.

[JAWS-test]

@cstrobbe

Thank you very much. This is exactly what we need.

The SC should be worded so that this also applies to languages that override native semantics, like ARIA.
And it should also apply to languages that add semantics, like tags in PDF.

In the Understanding I would add that correct nesting is also important to be able to determine the number of elements. For example, a screen reader can only tell that a table has 3 columns and 2 rows and that I am currently in column 2 and row 1 if the nesting is correct.

Note: We already have something similar in EN 301 549 and Section 508:

11.5.2.9 Parent-child relationships: Where the software provides a user interface it shall, ... make the relationship between a user interface element and any parent or children elements programmatically determinable by assistive technologies.

502.3.7 Hierarchical Relationships: Any hierarchical (parent-child) relationship that a component has as a container for, or being contained by, another component shall be programmatically determinable.

[JAWS-test]

There are cases where the parent-child relationship is not achieved via the correct nesting of elements, e.g.

• Use of aria-owns
• Use of the name attribute for radiobuttons that belong to a radiobutton group.
• Use of aria-level for treegrids

Therefore, perhaps the new SC should rather be worded in such a way that it is not (only) about the correct nesting of elements, but about the fact that the parent-child relationship can be correctly submitted to the Accessibility API.

[JAWS-test]

Example 5 could also be a violation of 4.1.4, since a label element may not contain a form field if it refers to another form field via for (at least that's what the HTML specification says)

[bruce-usab]

@cstrobbe I like what you have started to lay out here. But it is almost certainly too late to get anything new into 2.2.

[patrickhlauke]

at a high level...instead of a new SC to patch how 4.1.1 isn't being interpreted well, i'd rather see 4.1.1 being updated normatively to include some of these thoughts explicitly (which can be done in a backwards-compatible way, so that content that complies with an expanded/more specific 4.1.1 would also pass previous looser versions of 4.1.1).

otherwise, we'll start having weird overlaps instead (SCs that appear to be special cases/stricter interpretations of already existing SCs)

[cstrobbe]

@JAWS-test

Therefore, perhaps the new SC should rather be worded in such a way that it is not (only) about the correct nesting of elements, but about the fact that the parent-child relationship can be correctly submitted to the Accessibility API.

Yes, that would be better, but I initially struggled with how to express that. I will submit another suggestion that should cover both native roles that aren't overwritten by other data, and explicitly assigned roles.

Example 5 could also be a violation of 4.1.4, since a label element may not contain a form field if it refers to another form field via for (at least that's what the HTML specification says)

The label element's content model is

Phrasing content, but with no descendant labelable elements unless it is the element's labeled control, and no descendant label elements.

There is ambiguity in HTML 5 about which type of labelling takes precedence: the one defined by the for attribute or the one based on nesting. If nesting takes precedence, the second label contains "the element's labeled control" and passes the proposed new SC. (The first input then has no label, so we can fail the code under SC 3.3.2, so it least we catch it somewhere.) If, however, the for attribute takes precedence, it is possible to argue that it fails the proposed SC.

[cstrobbe]

at a high level...instead of a new SC to patch how 4.1.1 isn't being interpreted well, i'd rather see 4.1.1 being updated normatively to include some of these thoughts explicitly (which can be done in a backwards-compatible way, so that content that complies with an expanded/more specific 4.1.1 would also pass previous looser versions of 4.1.1).

I'm rather reluctant to propose such a change to 4.1.1 because the intent is very different. SC 4.1.1 is about syntax (see the Understanding document, which explains how the SC was inspired by XML's concept of wellformedness), whereas the proposed SC certain specific relationships between elements that get exposed through an accessibility API.
If the working group wants to integrate language from the proposed SC into SC 4.1.1, that's up to them.

[patrickhlauke]

but the point of 4.1.1 isn't syntax for syntax's sake. it's about making sure content works correctly (robustly) with user agents and AT, so this seems to cover the same ground

[cstrobbe]

but the point of 4.1.1 isn't syntax for syntax's sake. it's about making sure content works correctly (robustly) with user agents and AT, so this seems to cover the same ground

The point of SC 4.1.1 is ensuring that user agents can build an unambiguous parse tree.
The point of the proposed SC is making sure that name, role, state and value can unambiguously be exposed through an accessibility API. Its goal is not merely to fill a gap in SC 4.1.1. In a way, it is closer to SC 4.1.2: it makes sure that the nesting does not mess up what SC 4.1.2 requires.

[JAWS-test]

@cstrobbe

When metadata such as WAI-ARIA is used to redefine roles, should that be included in the SC? If yes, how should the requirement be worded?

I am absolutely in favor of ARIA being considered with 4.1.4, because it is with ARIA that most of the problems in this regard occur and not with HTML:

• HTML is mostly used correctly
• HTML can be validated
• HTML is automatically repaired by the browser

ARIA has the following disadvantages:

• most do not use ARIA correctly (especially since the specification is not stable and the requirement changes often).
• ARIA can hardly be validated
• ARIA is not automatically repaired by the browser - and if it is, it is not repaired consistently

The wording could be as in the EN and Section 508.

However, it would be good to consider what exactly is to be evaluated:

• Source code
• DOM
• Accessibility Tree

With the DOM and Accessibility tree there is the problem that errors of the web authors are corrected automatically, but not every browser does this in the same way - that's why there was originally 4.1.1.

The problem with source code is that it often has no relevance for DOM and Accessibility tree because of JS and CSS.

[bruce-usab]

Christophe, thank you for the contributions that you have put into issues and other WCAG work.

[yatil]

I think this might be addressed if we would extend 4.1.1 with "markup languages and associated extensions as they relate to accessibility features" (as a tech-independent or at to say HTML+ARIA). Plus the Understanding should probably take steps away from defining parsing as well-formed das, a concept we haven't used on the web for many, many years now.

(Alternatively: Remove 4.1.1, it's probably beyond its usefulness. See #2676)

[scottaohara]

agreed. use 4.1.1 for what people think it's for, rather than making a new SC to do what 4.1.1's normative language already supports - that is unless you know that "elements are nested according to their specifications" doesn't actually mean "elements are nested according to their specifications" in any way that matters to modern web development.

[bruce-usab]

use 4.1.1 for what people think it's for...

No thank you. I know I am just repeating myself from the other thread but I am guessing this issue stays open. It is bad to retcon a standard.

[GreggVan]

It is bad to retcon a standard.

Agree This needs to be clarified -( see other thread )— to ensure that it is interpreted the way it was originally written….. interpreted to mean what the working group meant when it was written - rather than what people think it means, or want it to mean, after the fact. PS retcon means " The depiction of fictional events, as in a television series or comic book, that entail a revision of the narrative presented in an earlier installment. " Here it means - "re-interpreting things later to mean something different than when written" gregg

…

On Nov 10, 2022, at 1:22 PM, Bruce Bailey ***@***.***> wrote: use 4.1.1 for what people think it's for... No thank you. I know I am just repeating myself from the other thread <#2525 (comment)> but I am guessing this issue stays open. It is bad to retcon a standard. — Reply to this email directly, view it on GitHub <#2649 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXR6V266U5SAR2HPTITWHVRSTANCNFSM573UPSWQ>. You are receiving this because you are subscribed to this thread.