Open cstrobbe opened 2 years ago
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.
@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.
There are cases where the parent-child relationship is not achieved via the correct nesting of elements, e.g.
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.
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)
@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.
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)
@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.
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.
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
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.
@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:
ARIA has the following disadvantages:
The wording could be as in the EN and Section 508.
However, it would be good to consider what exactly is to be evaluated:
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.
Christophe, thank you for the contributions that you have put into issues and other WCAG work.
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 https://github.com/w3c/wcag/issues/2676)
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.
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.
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 https://github.com/w3c/wcag/issues/2525#issuecomment-1307219053 but I am guessing this issue stays open. It is bad to retcon a standard.
— Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/2649#issuecomment-1310907479, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNGDXR6V266U5SAR2HPTITWHVRSTANCNFSM573UPSWQ. You are receiving this because you are subscribed to this thread.
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
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 eitherul
,ol
ormenu
, which are also elements with native roles;th
andtd
, which can only occur withintr
, which in turn can only occur within other table elements (thead
,tbody
,tfoot
ortable
),legend
, which can only occur within afieldset
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 typeli
; other element types, such asp
, 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 anhref
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 allowsli
elements as child elements. The content model fordiv
, by contrast, allows a wide range of other elements, including the recursive nesting ofdiv
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
Techniques
[Boiler plate "Each numbered item in this section represents ..." goes here.]
Sufficient Techniques
(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
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
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, thebutton
cannot contain any interactive content descendants, and therefore no links.This example
Example 2
Source: same comment as example 1.
li
is a required child element oful
but here occurs as a child element ofdiv
, where it is not allowed.This example
Example 3
Inspired by the previous example, see my
div
insideul
test page.The
ul
element requiresli
elements as child elements; both element types have native roles.This example
Example 4
Source: a comment by Alastair Campbell on issue #2525.
Both
button
andh2
have native roles but they are not nested according to specification: thebutton
elements content model only allows phrasing content and thus prohibits headings.This example
Example 5
Source: inspired by a comment by Giacomo Petri on issue #2525.
See my earlier discussion of this example. This example
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 firstinput
's accessible name is thelabel
element (including its descendant, theselect
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 butspan
doesn't.This example
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
span
has no native role.Example 8
Source: a comment by Mark Rogers on issue #978, but with added
alt
attribute.table
,tr
andtd
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
img
is not allowed as a sibling oftr
.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.
The
input
element has a native role but is not required as a child element ofform
since it may be wrapped inp
,div
,fieldset
and other elements that can be used as descendants ofform
.If, for simplicity's sake, we ignore HTML 5's adoption agency algorithm, this example
form
has a native role and nested forms are not allowed.Example 10
Source: a comment by Mark Rogers on issue #770.
This example
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.
This example
input
must not appear as a descendant of thea
element),Example 12
Source: same as previous example (with a space inserted before the
aria-label
attributte).This example
a
must not appear as a descendant of an element with the attributerole=button
),Example 13
Source: same as previous example.
This example
button
must not appear as a descendant of thea
element),Example 14
Source: a comment by Mark Rogers on issue #770, dated 14 August 2019 (a real-world example).
This example
input
has a duplicatearia-describedby
attribute (this is not a matter of element nesting),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.
The content model for
label
allows "phrasing content", which includesa
elements. (It does not allow descendant labellable elements except for the labelled control, nor descendantlabel
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 thelabel
before thea
element.This example
Example 16
Source: a discussion on a11y Slack from 26 November 2020.
This example
p
element mapping to accessibility APIs).Example 19
Source: issue 2620: Failure of Success Criterion 1.3.1 due to using th elements.
This example
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.