-
Notifications
You must be signed in to change notification settings - Fork 82
Rule 2ee8b8 ("Visible label is part of accessible name"): introducing a new "label in name algorithm". #2075
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
base: develop
Are you sure you want to change the base?
Changes from 18 commits
aeafb90
5a07973
a75c7f8
623d26e
f920a47
ee3e993
75a9878
81caf8a
2928be6
5cd8b2c
092c849
f499d04
473bcb8
5c7fc1e
3d3b657
8ed61b8
24d0ffc
46294dd
a141df8
5220766
b2df021
cde4ad4
83d0e10
5dce8e1
2cfe5f8
7cdf8c3
563ff5e
53fe350
821de81
f9e7272
ae2273a
d4f8076
2dcd941
09f668c
a37cfd3
22ad17b
2dc429f
2ab4489
db37b3b
7b2a053
9723ed1
4da5300
5617755
6be702c
0d4c543
a959b09
f1219c8
f9850c8
b77023c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -23,6 +23,7 @@ acknowledgments: | |||||
| authors: | ||||||
| - Anne Thyme Nørregaard | ||||||
| - Bryn Anderson | ||||||
| - Dan Tripp | ||||||
| - Jey Nandakumar | ||||||
| funding: | ||||||
| - WAI-Tools | ||||||
|
|
@@ -38,10 +39,14 @@ This rule applies to any element for which all the following is true: | |||||
|
|
||||||
| ## Expectation | ||||||
|
|
||||||
| For each target element, all [text nodes][] in the [visible text content][] either match or are contained within the [accessible name][] of this target element, except for characters in the [text nodes][] used to express [non-text content][]. Leading and trailing [whitespace][] and difference in case sensitivity should be ignored. | ||||||
| For the target element, the [visible inner text][] is contained within the [accessible name][] according to the [label in name algorithm][]. | ||||||
|
|
||||||
| ## Assumptions | ||||||
|
|
||||||
| This rule assumes that the [visible inner text][] is equal to the [label][https://www.w3.org/WAI/WCAG21/Understanding/label-in-name#dfn-label] in most cases (enough cases to be useful) even though "label" is not precisely defined at this point in history. | ||||||
|
|
||||||
| This rule assumes that neither the label nor the [visible inner text][] are rearranged with CSS in some way so that they appear to the user in a different order than they do in the DOM. | ||||||
|
|
||||||
| This rule assumes that all resources needed for rendering the page are properly loaded. Checking if resources are missing is out of the scope of rules. Missing resources may be rendered as text (for example, missing `img` are rendered as their `alt` attribute). | ||||||
|
|
||||||
| ## Accessibility Support | ||||||
|
|
@@ -54,6 +59,7 @@ This rule applies to elements with a [widget role][] that [support name from con | |||||
|
|
||||||
| The understanding document of [2.5.3 Label in Name][understand253] use the term "symbolic text characters" to refer to a type of [non-text content][] that uses text characters as symbols, such as using "x" to mean "close". This rule considers them as "characters expressing non-text content". Unicode emojis are another example of characters expressing non-text content, although these are not "symbolic text characters". | ||||||
|
|
||||||
|
|
||||||
| ### Bibliography | ||||||
|
|
||||||
| - [Understanding Success Criterion 2.5.3: Label in Name][understand253] | ||||||
|
|
@@ -65,39 +71,39 @@ The understanding document of [2.5.3 Label in Name][understand253] use the term | |||||
|
|
||||||
| #### Passed Example 1 | ||||||
|
|
||||||
| This link has [visible][] text that matches the [accessible name][]. | ||||||
| This link has [visible inner text][] that is equal to the [accessible name][]. | ||||||
|
|
||||||
| ```html | ||||||
| <a href="https://act-rules.github.io/" aria-label="ACT rules">ACT rules</a> | ||||||
| ``` | ||||||
|
|
||||||
| #### Passed Example 2 | ||||||
|
|
||||||
| This link has [visible][] text that, ignoring trailing whitespace, matches the [accessible name][]. | ||||||
| This link has [visible inner text][] that, ignoring whitespace, is equal to the [accessible name][]. | ||||||
|
|
||||||
| ```html | ||||||
| <a href="https://act-rules.github.io/" aria-label=" ACT rules ">ACT rules</a> | ||||||
| <a href="https://act-rules.github.io/" aria-label=" ACT rules ">ACT rules</a> | ||||||
| ``` | ||||||
|
|
||||||
| #### Passed Example 3 | ||||||
|
|
||||||
| This link has [visible][] text that, ignoring case, matches the [accessible name][]. | ||||||
| This link has [visible inner text][] that, ignoring case, is equal to the [accessible name][]. | ||||||
|
|
||||||
| ```html | ||||||
| <a href="https://act-rules.github.io/" aria-label="act rules">ACT rules</a> | ||||||
| <a href="https://act-rules.github.io/" aria-label="act Rules">ACT rules</a> | ||||||
| ``` | ||||||
|
|
||||||
| #### Passed Example 4 | ||||||
|
|
||||||
| This button has [visible][] text that is contained within the [accessible name][]. | ||||||
| This button has [visible inner text][] that is contained within the [accessible name][] according to the [label in name algorithm][]. | ||||||
|
|
||||||
| ```html | ||||||
| <button aria-label="Next Page in the list">Next Page</button> | ||||||
| ``` | ||||||
|
|
||||||
| #### Passed Example 5 | ||||||
|
|
||||||
| This button has [visible][] text that does not need to be contained within the [accessible name][], because the "x" text node is [non-text content][]. | ||||||
| The "X" is [non-text content][], so it doesn't need to be contained within the [accessible name][]. | ||||||
|
|
||||||
| ```html | ||||||
| <button aria-label="close">X</button> | ||||||
|
|
@@ -117,45 +123,253 @@ This `button` element has the text "search" rendered as an magnifying glass icon | |||||
| <button aria-label="Find">search</button> | ||||||
| ``` | ||||||
|
|
||||||
| #### Passed Example 7 | ||||||
|
|
||||||
| This button has [visible inner text][] that, according to the [label in name algorithm][], is contained within the [accessible name][]. This example shows why the [label in name algorithm][] uses the [visible inner text][] and not the [visible text content][]: the <p> tags insert whitespace into the result in the former but not the latter. | ||||||
|
|
||||||
| ```html | ||||||
| <button aria-label="Hello world"><p>Hello</p><p>world</p></button> | ||||||
| ``` | ||||||
|
|
||||||
| #### Passed Example 8 | ||||||
|
|
||||||
| Similar to the previous example. | ||||||
|
|
||||||
| ```html | ||||||
| <a href="#" aria-label="Some article by John Doe"><h6>Some article</h6><p>by John Doe</p></a> | ||||||
| ``` | ||||||
|
|
||||||
| #### Passed Example 9 | ||||||
|
|
||||||
| The [visible inner text][] of this link is "ACT" (with no spaces) because of the explicit styles of "display: inline" on the <p> elements and the absence of whitespace between the <p> elements. The cases of "display: inline" and "display: block" are handled by the definition of [visible inner text of an element][]. This example shows that the definition agrees with the visual rendering done by the browser. | ||||||
|
||||||
| The [visible inner text][] of this link is "ACT" (with no spaces) because of the explicit styles of "display: inline" on the <p> elements and the absence of whitespace between the <p> elements. The cases of "display: inline" and "display: block" are handled by the definition of [visible inner text of an element][]. This example shows that the definition agrees with the visual rendering done by the browser. | |
| The [visible inner text][] of this link is "ACT" (with no spaces) because of the explicit styles of `display: inline` on the `p` elements and the absence of whitespace between the `p` elements. The cases of `display: inline` and `display: block` are handled by the definition of [visible inner text of an element][]. This example shows that the definition agrees with the visual rendering done by the browser. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 2dcd941.
dan-tripp-siteimprove marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think adding the "First Name:" pass example from the Understanding document would be useful (since it's very common).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a strong example for the SC, but I can't see how to adapt it to this ACT rule. That example (<label for="firstname">First Name:</label> <input id="firstname" type="text" name="firstname">) doesn't meet the applicability of this ACT rule because <input> doesn't support "name from content". For us to add an example which uses that visible label "First Name:" on an element which does support "name from content" (mostly <a> and <button>) seems unrealistic to me. Suggestions welcome on how to reconcile this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rule has no special handling for abbreviations.
This seems problematic. For many abbreviations it is much more natural (in English) to say the full word when encountering an abbreviations (for example, abbreviations in an address like "Rd.", "St.", "Pl.", etc).
Perhaps it is just another shortcoming of this SC, but the calculation seems to me to need to be more fuzzy, and bias towards passing, not failing an abbreviation construct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, I agree, but I consider this problem to be in the category of problems that this PR didn't create and didn't make worse. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess two points.
The SC wording is: "the name contains the text that is presented visually."
We already have a rule stating that punctuation can be disregarded, so in this example, the displayed wording can be interpreted as "University Ave" and the name is "University Avenue". The accessible name literally contains the text that is presented visually (plus three more characters). So why is it a fail? It should be a pass, no?
The second point is just about abbreviations as synonyms. I can think of situations in English where it would be unusual to say only the abbreviation. For instance, if someone sees "Main St." or "First Rd.", they are going to say the abbreviation as the full word ("main street", "first road"). On the other hand "Ave" may be spoken as the full word or as the abbreviation. Part of me believes it is reasonable to compile a set of abbreviations which are commonly spoken as the full word, and not the abbreviation. But that seems unsustainable/unscalable.
On consideration, I reluctantly agree that failing a mismatch where the name does not contain all the characters of the displayed abbreviation (less punctuation) makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Referencing "previous example" is a bit risky since nothing guarantees they will stay in the same order next time we rewrite the rule.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree there is a risk. In this case I think that the risk is worth it. With "previous", I claim that the readability is improved now. If I remove "previous", I can't think of a way to rewrite it that doesn't make it significantly less readable.