From aeafb906d9c8617d451285440315c644a4673598 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Tue, 4 Apr 2023 12:25:25 -0400 Subject: [PATCH 01/38] invalid-form-field-value-36b590: updating failed example 2. --- _rules/invalid-form-field-value-36b590.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_rules/invalid-form-field-value-36b590.md b/_rules/invalid-form-field-value-36b590.md index c24aea1c975..1797def5638 100644 --- a/_rules/invalid-form-field-value-36b590.md +++ b/_rules/invalid-form-field-value-36b590.md @@ -171,7 +171,7 @@ This `input` element has a [form field error indicator][] but its message does n
- Please enter the correct text.
+ Invalid value for age.
``` From 623d26e294430d57879a2cb15c8f2d16e497f21a Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 21 Jun 2023 20:32:41 -0400 Subject: [PATCH 02/38] Rule visible-label-in-accessible-name-2ee8b8: introducing a new "label in name algorithm". It's intended mostly to handle whitespace and punctuation. --- ...visible-label-in-accessible-name-2ee8b8.md | 236 ++++++++++++++++-- package.json | 4 + pages/glossary/label-in-name-algorithm.md | 34 +++ pages/glossary/visible-inner-text.md | 38 +++ pages/glossary/visible-text-content.md | 4 +- 5 files changed, 299 insertions(+), 17 deletions(-) create mode 100755 pages/glossary/label-in-name-algorithm.md create mode 100755 pages/glossary/visible-inner-text.md diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index c17073622e7..fe730165062 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -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 each target element, the [visible inner text][] is contained within the [accessible name][] of the target element 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,7 +71,7 @@ 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 ACT rules @@ -73,23 +79,23 @@ This link has [visible][] text that matches the [accessible name][]. #### 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 -ACT rules +ACT rules ``` #### 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 -ACT rules +ACT rules ``` #### 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 @@ -97,7 +103,7 @@ This button has [visible][] text that is contained within the [accessible name][ #### 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 @@ -117,11 +123,96 @@ This `button` element has the text "search" rendered as an magnifying glass icon ``` +#### 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

tags insert whitespace into the result in the former but not the latter. + +```html + +``` + +#### Passed Example 8 + +Similar to the previous example. + +```html +

Some article

by John Doe

+``` + +#### Passed Example 9 + +The [visible inner text][] is "Download specification". The words "the" and "gizmo" aren't part of it. + +```html +Download the gizmo specification +``` + +#### Passed Example 10 + +This example shows that the [visible inner text][] isn't always the same as the [innerText][https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute]. The visible inner text is "Download specification". The innerText is 'Download \ngizmo\nspecification'. This rule uses the visible inner text - not innerText. + +```html + +Download specification +``` + +#### Passed Example 11 + +This example shows that the [label in name algorithm][] handles many kinds of whitespace. + +```html +compose   
email +``` + +#### Passed Example 12 + +This example passes the rule because "YYYY-MM-DD" is in brackets. Text in brackets is removed by the [label in name algorithm][], because its not normally spoken by speech-input users. + +```html + +``` + +#### Passed Example 13 + +The passes for two reasons: 1) because the ellipsis ("…") is [non-text content][], and 2) because the ellipsis is neither a letter nor a digit and so is filtered out by the [label in name algorithm][]. + +```html + +``` + +#### Passed Example 14 + +This passes because the [label in name algorithm][] effectively ignores all punctuation and emoji, in both the visible inner text and the accessible name, as long as they don't break up words. + +```html + +``` + +#### Passed Example 15 + +The "X" is non-text content. + +```html + +``` + + + ### Failed #### Failed Example 1 -This link has [visible][] text that is different from the [accessible name][]. +This link has [visible inner text][] that is very different from the [accessible name][]. ```html ACT rules @@ -129,25 +220,137 @@ This link has [visible][] text that is different from the [accessible name][]. #### Failed Example 2 -This button has [visible][] text that is only partially contained within the [accessible name][]. +This button has [visible inner text][] that is only partially contained within the [accessible name][]. ```html ``` -#### Failed Example 3 +#### Failed Example 3 + +This button has [visible inner text][] that is fully contained within the [accessible name][] when viewed as a character-by-character substring. But that does not satisfy our [label in name algorithm][], which works on full words. So this fails the rule. + +```html +Discover It +``` + +#### Failed Example 4 + +This link's [accessible name][] contains two tokens (according to the[label in name algorithm][]) and the [visible inner text][] contains one token. So it fails the rule. + +```html +justice +``` + +#### Failed Example 5 + +This link has an [accessible name][] which contains a hyphen. The [label in name algorithm][] breaks up words on hyphens. So it turns "non-standard" into two tokens: "non" and "standard". So this fails the rule. + +```html +nonstandard +``` + +#### Failed Example 6 + +The rule has no special handling for acronyms or initialisms. + +```html +W A V E +``` + +#### Failed Example 7 + +The rule has no special handling for abbreviations. + +```html +University Ave. +``` + +#### Failed Example 8 -This link has [visible][] text with mathematical symbols, that does not match the [accessible name][] because the mathematical symbols were written out in the accessible name. This is [explicitly mentioned in WCAG](https://www.w3.org/WAI/WCAG21/Understanding/label-in-name#mathematical-expressions-and-formulae). +This link has [visible inner text][] with mathematical symbols and is not contained within the [accessible name][] because the mathematical symbols are represented as English words (not digits) in the accessible name. This is [explicitly mentioned in WCAG](https://www.w3.org/WAI/WCAG21/Understanding/label-in-name#mathematical-expressions-and-formulae). ```html Proof of 2×2=4 ``` +#### Failed Example 9 + +Similar to the previous example. This rule has no special handling for converting mathematical symbols into words, or vice versa. + +```html + +``` + +#### Failed Example 10 + +This button's accessible name contains the same tokens that are in the visible label. But they aren't in the same order, so it fails the sublist check part of the [label in name algorithm][], and so it fails the rule. + +```html + +``` + +#### Failed Example 11 + +This link's accessible name contains the same digits that are in the visible label, and in the same order. But they have different spaces and punctuation between them, so they are considered separate tokens. So this fails the rule. + +```html +123.456.7890 +``` + +#### Failed Example 12 + +This rule has no special handling which tries to guess when number have the same semantic meaning. It operates on tokens only. + +```html +2021 +``` + +#### Failed Example 13 + +Similar to the previous example. + +```html +fibonacci: 0112358132134 +``` + +#### Failed Example 14 + +This rule has no special handling for converting digits into words, or vice versa. + +```html +two thousand twenty-one +``` + +#### Failed Example 15 + +(Same as above.) This rule has no special handling for converting digits into words, or vice versa. + +```html +2 0 2 3 +``` + +#### Failed Example 16 + +This rule has no special handling for digits that appear next to letters with no spaces in between. + +```html +1 +``` + +#### Failed Example 17 + +The definition of [visible inner text][] doesn't treat text any differently if it's excluded from the accessibility tree with aria-hidden. So this rule effectively ignores aria-hidden. So this element fails the rule. + +```html +Download specification +``` + ### Inapplicable #### Inapplicable Example 1 -This `nav` is not a widget, so the [visible][] text does not need to match the [accessible name][]. +This `nav` is not a widget, so the [visible inner text][] does not need to match the [accessible name][]. ```html @@ -155,7 +358,7 @@ This `nav` is not a widget, so the [visible][] text does not need to match the [ #### Inapplicable Example 2 -This email text field does not need to have its [visible][] text match the [accessible name][]. The content of a textfield shows its value instead of its label; it does not [support name from content][supports name from content]. The label is usually adjacent to the textfield instead. +This email text field does not need to have its [visible inner text][] match the [accessible name][]. The content of a textfield shows its value instead of its label; it does not [support name from content][supports name from content]. The label is usually adjacent to the textfield instead. ```html
E-mail
@@ -164,7 +367,7 @@ This email text field does not need to have its [visible][] text match the [acce #### Inapplicable Example 3 -This `div` element does not have a widget role, so the [visible][] text does not need to match the [accessible name][]. +This `div` element does not have a widget role, so the [visible inner text][]t does not need to match the [accessible name][]. ```html
Next
@@ -172,7 +375,7 @@ This `div` element does not have a widget role, so the [visible][] text does not #### Inapplicable Example 4 -This link has no [visible text content][]. +This link has no [visible inner text][]. ```html @@ -186,6 +389,7 @@ This link has no [visible text content][]. [semantic role]: #semantic-role 'Definition of Semantic role' [supports name from content]: https://www.w3.org/TR/wai-aria-1.1/#namefromcontent 'Definition of Supports name from contents' [visible]: #visible 'Definition of visible' +[visible inner text]: #visible-inner-text 'Definition of Visible inner text' [visible text content]: #visible-text-content 'Definition of Visible text content' [whitespace]: #whitespace 'Definition of Whitespace' [widget role]: https://www.w3.org/TR/wai-aria-1.1/#widget_roles 'Definition of Widget role' diff --git a/package.json b/package.json index 663baf4c39d..4e9fae902df 100644 --- a/package.json +++ b/package.json @@ -48,6 +48,10 @@ "name": "Dagfinn Rømen", "url": "https://github.com/DagfinnRomen" }, + { + "name": "Dan Tripp", + "url": "https://github.com/dan-tripp-siteimprove" + }, { "name": "Daniël Strik", "url": "https://github.com/danistr" diff --git a/pages/glossary/label-in-name-algorithm.md b/pages/glossary/label-in-name-algorithm.md new file mode 100755 index 00000000000..cd3f8418494 --- /dev/null +++ b/pages/glossary/label-in-name-algorithm.md @@ -0,0 +1,34 @@ +--- +title: Label in Name Algorithm +key: label-in-name-algorithm +unambiguous: true +objective: false +input_aspects: + - CSS styling + - DOM tree +--- + +Let 'label' be the [visible inner text][] of the target element. Let 'name' be the [accessible name][] of the target element. Both 'label' and 'name' are strings. + +Sub-algorithm to tokenize a string: + +- Convert the string to lower case. +- For each character that either a) represents non-text content, or b) isn't a letter or a digit: replace that character with a space character. + - For a) Judgement of "non-text" probably can't be fully automated. eg. "X" for "close" probably can be, but presumably there are more cases than this. + - For b) Use the unicode classes Letter, Mark, and "Number, Decimal Digit [Nd]". (This will exclude hyphens, punctuation, emoji, and more.) +- Remove all characters that are within parentheses (AKA round brackets). + - Ignore square brackets and braces. +- Split the string into a list of strings, using a whitespace regular expression as the separator. + - This 'split' operation must: + - Effectively remove leading and trailing whitespace as a pre-processing step. + - If the string was all whitespace before this operation: result in an empty list. + +Then do the check: is the tokenized 'label' a sublist of the tokenized 'name'? +- This 'sublist' check has these properties: + - It checks whether elements are consecutive or not. i.e. it checks for a substring, in the computer science sense of the term. Not a subsequence. + - An empty list is a sublist of any list. + +If the answer is "yes" (i.e. the tokenized 'label' a sublist of the tokenized 'name'), then the target element passes the rule. Otherwise, it fails the rule. + +[accessible name]: #accessible-name 'Definition of accessible name' +[visible inner text]: #visible-inner-text 'Definition of Visible inner text' diff --git a/pages/glossary/visible-inner-text.md b/pages/glossary/visible-inner-text.md new file mode 100755 index 00000000000..9945ad6dd2c --- /dev/null +++ b/pages/glossary/visible-inner-text.md @@ -0,0 +1,38 @@ +# Visible inner text + +(The "visible inner text" defined here is similar to, but not the same as, [visible text content][].) + +The visible inner text of a node depends on the kind of node. + +The visible inner text of a [text node][] is: +- if the [text node][] is [visible][], its visible inner text is its [data][]; +- if the [text node][] is not-[visible][], [rendered][], and contains only [whitespace][], its visible inner text is the string `" "` (a single ASCII whitespace); +- otherwise, the visible inner text of the [text node][] is the empty string (`""`). + + +The visible inner text of an [element][] is: +- if the [element][] is not [rendered][], its visible inner text is the empty string (`""`); +- if the [element][] is a [`
`][
] element, its visible inner text is a newline character (`"\n"`); +- if the [element][] is a [`

`][

] element, its visible inner text is the concatenation a newline character (`"\n"`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]), plus a newline character (`"\n"`); +- if the [computed][] [`display`][display] property of the [element][] has an [outer display type][] of `block`, or an [inner display type][] of `table-caption`, the visible inner text of the [element][] is the concatenation of a newline character (`"\n"`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus a newline character (`"\n"`); +- if the [computed][] [`display`][display] property of the [element][] has an [inner display type][] of `table-cell` or `table-row`, the visible inner text of the [element][] is the concatenation of an ASCII whitespace (`" "`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus an ASCII whitespace (`" "`); +- otherwise, the visible inner text of the [element][] is the concatenation of the visible inner text of its children (in [tree order][] in the [flat tree][]). + + +The visible inner text of any other node is the concatenation of the visible inner text of its children (in [tree order][] in the [flat tree][]). + +[
]: https://html.spec.whatwg.org/#the-br-element +[

]: https://html.spec.whatwg.org/#the-p-element +[computed]: https://drafts.csswg.org/css-cascade/#computed +[data]: https://dom.spec.whatwg.org/#concept-cd-data +[display]: https://drafts.csswg.org/css2/#propdef-display +[element]: https://dom.spec.whatwg.org/#element +[flat tree]: https://drafts.csswg.org/css-scoping/#flat-tree +[inner display type]: https://drafts.csswg.org/css-display/#inner-display-type +[outer display type]: https://drafts.csswg.org/css-display/#outer-display-type +[rendered]: https://html.spec.whatwg.org/#being-rendered +[text node]: https://dom.spec.whatwg.org/#text +[tree order]: https://dom.spec.whatwg.org/#concept-tree-order +[visible]: ./visible.md +[visible text content]: #visible-text-content +[whitespace]: ./whitespace.md diff --git a/pages/glossary/visible-text-content.md b/pages/glossary/visible-text-content.md index f39f0e0a150..c422e31173d 100755 --- a/pages/glossary/visible-text-content.md +++ b/pages/glossary/visible-text-content.md @@ -8,10 +8,12 @@ input_aspects: - DOM tree --- -The _visible text content_ of an [element][] is a set of all [visible][] [text nodes][] that are [descendants][] in the [flat tree][] of this element +The _visible text content_ of an [element][] is a set of all [visible][] [text nodes][] that are [descendants][] in the [flat tree][] of this element. (This is similar to, but not the same as, [visible inner text][].) + [descendants]: https://dom.spec.whatwg.org/#concept-tree-descendant 'DOM tree descendant, 2020/08/18' [element]: https://dom.spec.whatwg.org/#element 'DOM element, 2020/08/18' [flat tree]: https://drafts.csswg.org/css-scoping/#flat-tree 'CSS draft, flat tree, 2020/08/18' [visible]: #visible +[visible inner text]: #visible-inner-text [text nodes]: https://dom.spec.whatwg.org/#text 'DOM text, 2020/08/18' From 81caf8a7c954a6869da49443bf5eef015e9b346a Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Thu, 17 Aug 2023 15:04:08 -0400 Subject: [PATCH 03/38] Adding examples to rule presentational-children-no-focusable-content-307n5z --- ...al-children-no-focusable-content-307n5z.md | 99 +++++++++++++++++-- 1 file changed, 93 insertions(+), 6 deletions(-) diff --git a/_rules/presentational-children-no-focusable-content-307n5z.md b/_rules/presentational-children-no-focusable-content-307n5z.md index 0385a7d541f..aad6939ba85 100755 --- a/_rules/presentational-children-no-focusable-content-307n5z.md +++ b/_rules/presentational-children-no-focusable-content-307n5z.md @@ -67,7 +67,7 @@ None of these `button` elements has [descendants][] that are included in [sequen #### Passed Example 2 -This element with `checkbox` role has no [descendants][] that are included in [sequential focus navigation][]. Instead the link to the terms of service is adjacent, and `aria-labelledby` is used to provide its [accessible name][]. +This element with the `checkbox` role has no [descendants][] that are included in [sequential focus navigation][]. Instead the link to the terms of service is adjacent, and `aria-labelledby` is used to provide its [accessible name][]. ```html

@@ -80,7 +80,7 @@ This element with `checkbox` role has no [descendants][] that are included in [s #### Passed Example 3 -This element with `menuitemcheckbox` role has an `input` element as a descendant. Because the `input` is disabled it is not included in [sequential focus navigation][]. +This element with the `menuitemcheckbox` role has an `input` element as a descendant. Because the `input` is disabled it is not included in [sequential focus navigation][]. **Note**: The `input` checkbox has a `role` [attribute value][] of `none` to ensure it is ignored by browsers that do not support [presentational children][]. @@ -93,6 +93,15 @@ This element with `menuitemcheckbox` role has an `input` element as a descendant ``` +#### Passed Example 4 + +This ` +``` + + ### Failed #### Failed Example 1 @@ -108,7 +117,7 @@ This `button` element has a [child][] `span` element. Because the `span` element #### Failed Example 2 -This element with `checkbox` role has an `a` element as a [child][]. Because the `a` element has an `href` attribute, it is included in [sequential focus navigation][]. +This element with the `checkbox` role has an `a` element as a [child][]. Because the `a` element has an `href` attribute, it is included in [sequential focus navigation][]. ```html

I agree to the terms of service

@@ -116,7 +125,7 @@ This element with `checkbox` role has an `a` element as a [child][]. Because the #### Failed Example 3 -This element with `menuitemcheckbox` role has a checkbox as a child. Because the checkbox is not disabled, it is included in [sequential focus navigation][]. +This element with the `menuitemcheckbox` role has a checkbox as a child. Because the checkbox is not disabled, it is included in [sequential focus navigation][]. ```html ``` +#### Failed Example 4 + +This element with the `tab` role contains an `` element. The `tab` role has [presentational children][]. The `a` element is included in [sequential focus navigation][]. So the element with the `tab` role fails the rule. (This tablist implementation is non-functional for users. It's not meant to function - it's only meant to show roles.) + +```html + +``` + +#### Failed Example 5 + +This element with the `img` role contains an `` element. The `img` role has [presentational children][]. The `` element is included in [sequential focus navigation][]. So the element with the `img` role fails the rule. (Interestingly, no similar failure is possible with a standard HTML `` element, because according to the HTML specification, the `` element has no closing tag. So it's impossible to put anything inside of an `` element.) + +```html +****** This ASCII art ******* contains a link. +``` + ### Inapplicable #### Inapplicable Example 1 -This element has a `link` role which does not have [presentational children][]. +None of the roles involved in this semantic table have [presentational children][]. (The roles are `table`, `row`, and `cell`, respectively, for the ``, ``, and `
` elements.) So this rule does not apply. ```html -W3C Website + + + + + + + + + + + + +
semantic table header
anchor in semantic table - no problem
``` +#### Inapplicable Example 2 + +This `` element has a `link` role, which does not have [presentational children][]. So this element - perhaps surprisingly - does not fail this rule, because it's inapplicable. This is the case even though it's invalid HTML. Any time there's a link as the outer element, that will be inapplicable under this rule. (If the elements were switched - that is, if the ` +``` + +#### Inapplicable Example 3 + +The applicability of this rule does not include elements with an explicit role of `presentation`. Only implicit (through roles with [presentational children][]). This example shows that. + +```html + +``` + +#### Inapplicable Example 4 + +The applicability of this rule does not include hidden elements. It only includes presentational elements (through roles with [presentational children][]). These two terms - "hidden" and "presentational" - are often confused. When an element is "hidden", that means that it is completely omitted from the accessibility tree. When an element is "presentational", that means that its semantic role is omitted from the accessibility tree, but its content remains. + +The [ARIA 1.2 specification]https://www.w3.org/TR/wai-aria-1.2/#presentation) mentions this confusion: +
    +
  • +Many individuals erroneously consider role="presentation" to be synonymous with aria-hidden="true" +
    • +
  • +... the presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessibility tree. +
    • +
+ +Adding to this confusion is a third term: "decorative". The words "decorative" and "presentational" are often used interchangeably, but that usage is inaccurate. The word "decorative" often appears in a sentence such as "marking an image as decorative" - that is, by adding `alt=""` to an `` element. "Decorative" in that context does mean "hidden" - and "hidden", again, is different from "presentational" - so using "decorative" and "presentational" interchangeably is inaccurate. At the time of writing (August 2023), the ACT definition of "[marked as decorative][]" unfortunately encourages this inaccurate usage: it states that An element is marked as decorative if ... it has an explicit role of none or presentation. + +At any rate: this example shows that this rule does not apply to hidden elements. + +```html + +``` + + [accessible name]: #accessible-name 'Definition of Accessible name' [attribute value]: #attribute-value 'Definition of Attribute value' [semantic role]: #semantic-role 'Definition of Semantic role' @@ -147,3 +233,4 @@ This element has a `link` role which does not have [presentational children][]. [sequential focus navigation]: https://html.spec.whatwg.org/#sequential-focus-navigation 'HTML sequential focus navigation, 2020/10/21' [flat tree]: https://drafts.csswg.org/css-scoping/#flat-tree 'CSS Scoping definition of Flat tree, working draft' [html or svg element]: #namespaced-element +[marked as decorative]: /glossary/#marked-as-decorative \ No newline at end of file From 092c849c238dc975a42b356a37a090097512b89f Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Thu, 9 Nov 2023 11:42:04 -0500 Subject: [PATCH 04/38] removing Passed Example 15 because it's a duplicate. --- _rules/visible-label-in-accessible-name-2ee8b8.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index fe730165062..104b1f934ad 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -198,13 +198,6 @@ This passes because the [label in name algorithm][] effectively ignores all punc ``` -#### Passed Example 15 - -The "X" is non-text content. - -```html - -``` From f499d04e03e7f6d3033573a232efca7c13e726bf Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Thu, 9 Nov 2023 11:51:05 -0500 Subject: [PATCH 05/38] - adding frontmatter. (I originally copied this definition from https://github.com/Siteimprove/sanshikan/blob/main/terms/visible-inner-text.md) - changing glossary links' prefixes from "./" to "#". I don't know if the former was working or not. but the latter is the common practice, it seems. --- pages/glossary/visible-inner-text.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/pages/glossary/visible-inner-text.md b/pages/glossary/visible-inner-text.md index 9945ad6dd2c..a7d8db81b4c 100755 --- a/pages/glossary/visible-inner-text.md +++ b/pages/glossary/visible-inner-text.md @@ -1,4 +1,12 @@ -# Visible inner text +--- +title: Visible Inner Text +key: visible-inner-text +unambiguous: true +objective: true +input_aspects: + - CSS styling + - DOM tree +--- (The "visible inner text" defined here is similar to, but not the same as, [visible text content][].) @@ -33,6 +41,6 @@ The visible inner text of any other node is the concatenation of the [rendered]: https://html.spec.whatwg.org/#being-rendered [text node]: https://dom.spec.whatwg.org/#text [tree order]: https://dom.spec.whatwg.org/#concept-tree-order -[visible]: ./visible.md +[visible]: #visible [visible text content]: #visible-text-content -[whitespace]: ./whitespace.md +[whitespace]: #whitespace From 473bcb86e49cec0dbd524ab1277e9c8b545393d5 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Thu, 9 Nov 2023 12:05:27 -0500 Subject: [PATCH 06/38] editing example: WAVE -> WCAG --- _rules/visible-label-in-accessible-name-2ee8b8.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index 104b1f934ad..72b1f64bebc 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -248,7 +248,7 @@ This link has an [accessible name][] which contains a hyphen. The [label in nam The rule has no special handling for acronyms or initialisms. ```html -W A V E +W C A G ``` #### Failed Example 7 From 5c7fc1e327b3009e0f92c7a6c8491bd71e0dc833 Mon Sep 17 00:00:00 2001 From: Dan Tripp <113939352+dan-tripp-siteimprove@users.noreply.github.com> Date: Thu, 9 Nov 2023 12:13:12 -0500 Subject: [PATCH 07/38] Update pages/glossary/visible-inner-text.md Co-authored-by: Jean-Yves Moyen --- pages/glossary/visible-inner-text.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/glossary/visible-inner-text.md b/pages/glossary/visible-inner-text.md index a7d8db81b4c..b178a5363af 100755 --- a/pages/glossary/visible-inner-text.md +++ b/pages/glossary/visible-inner-text.md @@ -12,7 +12,7 @@ input_aspects: The visible inner text of a node depends on the kind of node. -The visible inner text of a [text node][] is: +The visible inner text of a [text node][] is: - if the [text node][] is [visible][], its visible inner text is its [data][]; - if the [text node][] is not-[visible][], [rendered][], and contains only [whitespace][], its visible inner text is the string `" "` (a single ASCII whitespace); - otherwise, the visible inner text of the [text node][] is the empty string (`""`). From 3d3b65783fd6ba531886f78c4132b0d35a9e0b0c Mon Sep 17 00:00:00 2001 From: Dan Tripp <113939352+dan-tripp-siteimprove@users.noreply.github.com> Date: Thu, 9 Nov 2023 12:16:45 -0500 Subject: [PATCH 08/38] Update pages/glossary/visible-inner-text.md Co-authored-by: Jean-Yves Moyen --- pages/glossary/visible-inner-text.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/glossary/visible-inner-text.md b/pages/glossary/visible-inner-text.md index b178a5363af..14b395bfd1d 100755 --- a/pages/glossary/visible-inner-text.md +++ b/pages/glossary/visible-inner-text.md @@ -18,7 +18,7 @@ The visible inner text of a [text node][]< - otherwise, the visible inner text of the [text node][] is the empty string (`""`). -The visible inner text of an [element][] is: +The visible inner text of an [element][] is: - if the [element][] is not [rendered][], its visible inner text is the empty string (`""`); - if the [element][] is a [`
`][
] element, its visible inner text is a newline character (`"\n"`); - if the [element][] is a [`

`][

] element, its visible inner text is the concatenation a newline character (`"\n"`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]), plus a newline character (`"\n"`); From 8ed61b83e118d68e7268bd98cfc182c7d13d4ed4 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Thu, 9 Nov 2023 12:53:26 -0500 Subject: [PATCH 09/38] adding mention of innerText --- pages/glossary/visible-inner-text.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/glossary/visible-inner-text.md b/pages/glossary/visible-inner-text.md index 14b395bfd1d..3bb38553125 100755 --- a/pages/glossary/visible-inner-text.md +++ b/pages/glossary/visible-inner-text.md @@ -8,7 +8,7 @@ input_aspects: - DOM tree --- -(The "visible inner text" defined here is similar to, but not the same as, [visible text content][].) +(The "visible inner text" defined here is similar to, but not the same as, [visible text content][] and [innerText][https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute].) The visible inner text of a node depends on the kind of node. From 24d0ffc340dbcc44ad2bf7ca9cb6879610166227 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Thu, 9 Nov 2023 13:05:58 -0500 Subject: [PATCH 10/38] - removing mention of "the rule" from label-in-name-algorithm.md . replacing it with a new idea: the algorithm 'return value' eg. 'returns "is contained"'. - rewording rule expectation. I think that 'For the target element' is better than 'For each target element' because for this rule, the computation of the expecation for each applicable target element is done in isolation from the other applicable targets on the page. It's simpler if the "for loop" over all applicable targets is done by the tool, not the rule. --- _rules/visible-label-in-accessible-name-2ee8b8.md | 2 +- pages/glossary/label-in-name-algorithm.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index 72b1f64bebc..43be126b552 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -39,7 +39,7 @@ This rule applies to any element for which all the following is true: ## Expectation -For each target element, the [visible inner text][] is contained within the [accessible name][] of the target element according to the [label in name algorithm][]. +For the target element, the [visible inner text][] is contained within the [accessible name][] according to the [label in name algorithm][]. ## Assumptions diff --git a/pages/glossary/label-in-name-algorithm.md b/pages/glossary/label-in-name-algorithm.md index cd3f8418494..39bf2a27a84 100755 --- a/pages/glossary/label-in-name-algorithm.md +++ b/pages/glossary/label-in-name-algorithm.md @@ -28,7 +28,7 @@ Then do the check: is the tokenized 'label' a sublist of the tokenized 'name'? - It checks whether elements are consecutive or not. i.e. it checks for a substring, in the computer science sense of the term. Not a subsequence. - An empty list is a sublist of any list. -If the answer is "yes" (i.e. the tokenized 'label' a sublist of the tokenized 'name'), then the target element passes the rule. Otherwise, it fails the rule. +If the answer is "yes" (that is: the tokenized 'label' is a sublist of the tokenized 'name'), then this algorithm returns "is contained". Otherwise, it returns "is not contained". [accessible name]: #accessible-name 'Definition of accessible name' [visible inner text]: #visible-inner-text 'Definition of Visible inner text' From 46294ddee604791751018a48462b42c5bd3900ec Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Thu, 9 Nov 2023 13:19:34 -0500 Subject: [PATCH 11/38] adding preamble to label-in-name-algorithm.md which mentions what this algorithm is for. --- pages/glossary/label-in-name-algorithm.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/pages/glossary/label-in-name-algorithm.md b/pages/glossary/label-in-name-algorithm.md index 39bf2a27a84..4e15a14d60f 100755 --- a/pages/glossary/label-in-name-algorithm.md +++ b/pages/glossary/label-in-name-algorithm.md @@ -8,6 +8,8 @@ input_aspects: - DOM tree --- +To check whether an [element][] has its label contained in its name, follow this algorithm: + Let 'label' be the [visible inner text][] of the target element. Let 'name' be the [accessible name][] of the target element. Both 'label' and 'name' are strings. Sub-algorithm to tokenize a string: @@ -32,3 +34,4 @@ If the answer is "yes" (that is: the tokenized 'label' is a sublist of the token [accessible name]: #accessible-name 'Definition of accessible name' [visible inner text]: #visible-inner-text 'Definition of Visible inner text' +[element]: https://dom.spec.whatwg.org/#element \ No newline at end of file From a141df88c065e845e2bf49ad8a9481b2f21ea371 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 15 Nov 2023 11:38:18 -0500 Subject: [PATCH 12/38] visible-inner-text definition: now normalizing whitespace in the definition. --- pages/glossary/visible-inner-text.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pages/glossary/visible-inner-text.md b/pages/glossary/visible-inner-text.md index 3bb38553125..d42e0b6a881 100755 --- a/pages/glossary/visible-inner-text.md +++ b/pages/glossary/visible-inner-text.md @@ -13,8 +13,8 @@ input_aspects: The visible inner text of a node depends on the kind of node. The visible inner text of a [text node][] is: -- if the [text node][] is [visible][], its visible inner text is its [data][]; -- if the [text node][] is not-[visible][], [rendered][], and contains only [whitespace][], its visible inner text is the string `" "` (a single ASCII whitespace); +- if the [text node][] is [visible][], its visible inner text is its [data][] with whitespace normalized by replacing contiguous [whitespace][] with the string `" "` (a single ASCII whitespace); +- if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is the string `" "` (a single ASCII whitespace); - otherwise, the visible inner text of the [text node][] is the empty string (`""`). From 5220766f2b0ba7d12624ec0d55a8dbaad22a2e5c Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 15 Nov 2023 11:40:48 -0500 Subject: [PATCH 13/38] visible-inner-text: replacing "ASCII whitespace" with "ASCII space character". --- pages/glossary/visible-inner-text.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pages/glossary/visible-inner-text.md b/pages/glossary/visible-inner-text.md index d42e0b6a881..c6cdcc06278 100755 --- a/pages/glossary/visible-inner-text.md +++ b/pages/glossary/visible-inner-text.md @@ -13,8 +13,8 @@ input_aspects: The visible inner text of a node depends on the kind of node. The visible inner text of a [text node][] is: -- if the [text node][] is [visible][], its visible inner text is its [data][] with whitespace normalized by replacing contiguous [whitespace][] with the string `" "` (a single ASCII whitespace); -- if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is the string `" "` (a single ASCII whitespace); +- if the [text node][] is [visible][], its visible inner text is its [data][] with whitespace normalized by replacing contiguous [whitespace][] with the string `" "` (a single ASCII space character); +- if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is the string `" "` (a single ASCII space character); - otherwise, the visible inner text of the [text node][] is the empty string (`""`). @@ -23,7 +23,7 @@ The visible inner text of an [element][ - if the [element][] is a [`
`][
] element, its visible inner text is a newline character (`"\n"`); - if the [element][] is a [`

`][

] element, its visible inner text is the concatenation a newline character (`"\n"`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]), plus a newline character (`"\n"`); - if the [computed][] [`display`][display] property of the [element][] has an [outer display type][] of `block`, or an [inner display type][] of `table-caption`, the visible inner text of the [element][] is the concatenation of a newline character (`"\n"`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus a newline character (`"\n"`); -- if the [computed][] [`display`][display] property of the [element][] has an [inner display type][] of `table-cell` or `table-row`, the visible inner text of the [element][] is the concatenation of an ASCII whitespace (`" "`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus an ASCII whitespace (`" "`); +- if the [computed][] [`display`][display] property of the [element][] has an [inner display type][] of `table-cell` or `table-row`, the visible inner text of the [element][] is the concatenation of an ASCII space character (`" "`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus an ASCII space character (`" "`); - otherwise, the visible inner text of the [element][] is the concatenation of the visible inner text of its children (in [tree order][] in the [flat tree][]). From b2df0212bcb1ef4a9057c1d7216704a519617f57 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 15 Nov 2023 12:09:42 -0500 Subject: [PATCH 14/38] adding passed example due to review at https://github.com/act-rules/act-rules.github.io/pull/2075#discussion_r1389112958 --- .../visible-label-in-accessible-name-2ee8b8.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index 43be126b552..92af3bc84e0 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -149,6 +149,14 @@ The [visible inner text][] is "Download specification". The words "the" and "gi #### Passed Example 10 +The [visible inner text][] is "Download specification", which includes a space character between the two words due to the second clause of the definition of [visible inner text of a text node][]. + +```html +Download specification +``` + +#### Passed Example 11 + This example shows that the [visible inner text][] isn't always the same as the [innerText][https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute]. The visible inner text is "Download specification". The innerText is 'Download \ngizmo\nspecification'. This rule uses the visible inner text - not innerText. ```html @@ -166,7 +174,7 @@ This example shows that the [visible inner text][] isn't always the same as the Download specification ``` -#### Passed Example 11 +#### Passed Example 12 This example shows that the [label in name algorithm][] handles many kinds of whitespace. @@ -174,7 +182,7 @@ This example shows that the [label in name algorithm][] handles many kinds of wh compose   
email ``` -#### Passed Example 12 +#### Passed Example 13 This example passes the rule because "YYYY-MM-DD" is in brackets. Text in brackets is removed by the [label in name algorithm][], because its not normally spoken by speech-input users. @@ -182,7 +190,7 @@ This example passes the rule because "YYYY-MM-DD" is in brackets. Text in brack ``` -#### Passed Example 13 +#### Passed Example 14 The passes for two reasons: 1) because the ellipsis ("…") is [non-text content][], and 2) because the ellipsis is neither a letter nor a digit and so is filtered out by the [label in name algorithm][]. @@ -190,7 +198,7 @@ The passes for two reasons: 1) because the ellipsis ("…") is [non-text content ``` -#### Passed Example 14 +#### Passed Example 15 This passes because the [label in name algorithm][] effectively ignores all punctuation and emoji, in both the visible inner text and the accessible name, as long as they don't break up words. @@ -383,6 +391,7 @@ This link has no [visible inner text][]. [supports name from content]: https://www.w3.org/TR/wai-aria-1.1/#namefromcontent 'Definition of Supports name from contents' [visible]: #visible 'Definition of visible' [visible inner text]: #visible-inner-text 'Definition of Visible inner text' +[visible inner text of a text node]: #visible-inner-text:for-text 'Definition of Visible inner text of a text node' [visible text content]: #visible-text-content 'Definition of Visible text content' [whitespace]: #whitespace 'Definition of Whitespace' [widget role]: https://www.w3.org/TR/wai-aria-1.1/#widget_roles 'Definition of Widget role' From cde4ad480cfbceb1c43eb76ce22536f28b8f4480 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 15 Nov 2023 12:54:18 -0500 Subject: [PATCH 15/38] handling review thread https://github.com/act-rules/act-rules.github.io/pull/2075#discussion_r1387713135 like this: - changing the visible-inner-text definition to treat

w/ "display: inline" differently. (treats it differently effectively, not explicitly.) - adding a passed example which shows a corresponding

w/ "display: inline" case. --- ...visible-label-in-accessible-name-2ee8b8.md | 23 ++++++++++++++----- pages/glossary/visible-inner-text.md | 1 - 2 files changed, 17 insertions(+), 7 deletions(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index 92af3bc84e0..fd712a6601a 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -141,13 +141,23 @@ Similar to the previous example. #### 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. + +```html + +

A

C

T

+ +``` + +#### Passed Example 10 + The [visible inner text][] is "Download specification". The words "the" and "gizmo" aren't part of it. ```html Download the gizmo specification ``` -#### Passed Example 10 +#### Passed Example 11 The [visible inner text][] is "Download specification", which includes a space character between the two words due to the second clause of the definition of [visible inner text of a text node][]. @@ -155,7 +165,7 @@ The [visible inner text][] is "Download specification", which includes a space c Download specification ``` -#### Passed Example 11 +#### Passed Example 12 This example shows that the [visible inner text][] isn't always the same as the [innerText][https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute]. The visible inner text is "Download specification". The innerText is 'Download \ngizmo\nspecification'. This rule uses the visible inner text - not innerText. @@ -174,7 +184,7 @@ This example shows that the [visible inner text][] isn't always the same as the Download specification ``` -#### Passed Example 12 +#### Passed Example 13 This example shows that the [label in name algorithm][] handles many kinds of whitespace. @@ -182,7 +192,7 @@ This example shows that the [label in name algorithm][] handles many kinds of wh compose   
email ``` -#### Passed Example 13 +#### Passed Example 14 This example passes the rule because "YYYY-MM-DD" is in brackets. Text in brackets is removed by the [label in name algorithm][], because its not normally spoken by speech-input users. @@ -190,7 +200,7 @@ This example passes the rule because "YYYY-MM-DD" is in brackets. Text in brack ``` -#### Passed Example 14 +#### Passed Example 15 The passes for two reasons: 1) because the ellipsis ("…") is [non-text content][], and 2) because the ellipsis is neither a letter nor a digit and so is filtered out by the [label in name algorithm][]. @@ -198,7 +208,7 @@ The passes for two reasons: 1) because the ellipsis ("…") is [non-text content ``` -#### Passed Example 15 +#### Passed Example 16 This passes because the [label in name algorithm][] effectively ignores all punctuation and emoji, in both the visible inner text and the accessible name, as long as they don't break up words. @@ -392,6 +402,7 @@ This link has no [visible inner text][]. [visible]: #visible 'Definition of visible' [visible inner text]: #visible-inner-text 'Definition of Visible inner text' [visible inner text of a text node]: #visible-inner-text:for-text 'Definition of Visible inner text of a text node' +[visible inner text of an element]: #visible-inner-text:for-element 'Definition of Visible inner text of an element' [visible text content]: #visible-text-content 'Definition of Visible text content' [whitespace]: #whitespace 'Definition of Whitespace' [widget role]: https://www.w3.org/TR/wai-aria-1.1/#widget_roles 'Definition of Widget role' diff --git a/pages/glossary/visible-inner-text.md b/pages/glossary/visible-inner-text.md index c6cdcc06278..06533ce04aa 100755 --- a/pages/glossary/visible-inner-text.md +++ b/pages/glossary/visible-inner-text.md @@ -21,7 +21,6 @@ The visible inner text of a [text node][]< The visible inner text of an [element][] is: - if the [element][] is not [rendered][], its visible inner text is the empty string (`""`); - if the [element][] is a [`
`][
] element, its visible inner text is a newline character (`"\n"`); -- if the [element][] is a [`

`][

] element, its visible inner text is the concatenation a newline character (`"\n"`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]), plus a newline character (`"\n"`); - if the [computed][] [`display`][display] property of the [element][] has an [outer display type][] of `block`, or an [inner display type][] of `table-caption`, the visible inner text of the [element][] is the concatenation of a newline character (`"\n"`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus a newline character (`"\n"`); - if the [computed][] [`display`][display] property of the [element][] has an [inner display type][] of `table-cell` or `table-row`, the visible inner text of the [element][] is the concatenation of an ASCII space character (`" "`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus an ASCII space character (`" "`); - otherwise, the visible inner text of the [element][] is the concatenation of the visible inner text of its children (in [tree order][] in the [flat tree][]). From 5dce8e1240330f6c9f0582519f22270d61371d61 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 13 Dec 2023 11:25:51 -0500 Subject: [PATCH 16/38] fixing failing test __tests__/link-reference-has-definition.js --- _rules/visible-label-in-accessible-name-2ee8b8.md | 3 --- pages/glossary/visible-inner-text.md | 1 - 2 files changed, 4 deletions(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index fd712a6601a..efc0607b7fe 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -399,12 +399,9 @@ This link has no [visible inner text][]. [presentational roles conflict resolution]: https://www.w3.org/TR/wai-aria-1.1/#conflict_resolution_presentation_none 'Presentational Roles Conflict Resolution' [semantic role]: #semantic-role 'Definition of Semantic role' [supports name from content]: https://www.w3.org/TR/wai-aria-1.1/#namefromcontent 'Definition of Supports name from contents' -[visible]: #visible 'Definition of visible' [visible inner text]: #visible-inner-text 'Definition of Visible inner text' [visible inner text of a text node]: #visible-inner-text:for-text 'Definition of Visible inner text of a text node' [visible inner text of an element]: #visible-inner-text:for-element 'Definition of Visible inner text of an element' [visible text content]: #visible-text-content 'Definition of Visible text content' -[whitespace]: #whitespace 'Definition of Whitespace' [widget role]: https://www.w3.org/TR/wai-aria-1.1/#widget_roles 'Definition of Widget role' -[text nodes]: https://dom.spec.whatwg.org/#text 'DOM text, 2020/08/18' [understand253]: https://www.w3.org/WAI/WCAG21/Understanding/label-in-name.html diff --git a/pages/glossary/visible-inner-text.md b/pages/glossary/visible-inner-text.md index 06533ce04aa..95402ad8358 100755 --- a/pages/glossary/visible-inner-text.md +++ b/pages/glossary/visible-inner-text.md @@ -29,7 +29,6 @@ The visible inner text of an [element][ The visible inner text of any other node is the concatenation of the visible inner text of its children (in [tree order][] in the [flat tree][]). [
]: https://html.spec.whatwg.org/#the-br-element -[

]: https://html.spec.whatwg.org/#the-p-element [computed]: https://drafts.csswg.org/css-cascade/#computed [data]: https://dom.spec.whatwg.org/#concept-cd-data [display]: https://drafts.csswg.org/css2/#propdef-display From 2cfe5f8b2540fff8017002461d4bf6cea2a11c0d Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 13 Dec 2023 11:32:05 -0500 Subject: [PATCH 17/38] fixing failing test _rules/__tests__/testcase-html-hint.js --- _rules/visible-label-in-accessible-name-2ee8b8.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index efc0607b7fe..985a2430411 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -213,7 +213,7 @@ The passes for two reasons: 1) because the ellipsis ("…") is [non-text content This passes because the [label in name algorithm][] effectively ignores all punctuation and emoji, in both the visible inner text and the accessible name, as long as they don't break up words. ```html - + ``` From 7cdf8c3a8396ab46412aad62f487c49c3a96e763 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 13 Dec 2023 11:56:10 -0500 Subject: [PATCH 18/38] fixing failing tests in __tests__/spelling.js --- __tests__/spelling-ignore.yml | 8 +++++++- _rules/visible-label-in-accessible-name-2ee8b8.md | 2 +- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/__tests__/spelling-ignore.yml b/__tests__/spelling-ignore.yml index f3078a8b641..e519b8764d7 100644 --- a/__tests__/spelling-ignore.yml +++ b/__tests__/spelling-ignore.yml @@ -132,7 +132,7 @@ - ozplayer - GitHub -# Test case anamolies +# Test case anomolies - brewitt-taylor - level2-frame1 - level1-frame2 @@ -142,6 +142,9 @@ - Sumei - Tuttle - lnik # intentional misspelling +- ngizmo +- nspecification +- thelabel # Attributes (repeated words with casing as retext-spell has no config to ignore casing) - href @@ -233,6 +236,9 @@ - focusability - unitless - luminance +- substring +- initialisms +- sublist # Parts of Unicode - 000A diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index 985a2430411..0778a6d5dfc 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -141,7 +141,7 @@ Similar to the previous example. #### 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. ```html From 563ff5edf6315897b4b846499371d4cc882a0e87 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 13 Dec 2023 12:01:37 -0500 Subject: [PATCH 19/38] fixing more failing tests in __tests__/spelling.js --- __tests__/spelling-ignore.yml | 3 +++ pages/glossary/label-in-name-algorithm.md | 4 ++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/__tests__/spelling-ignore.yml b/__tests__/spelling-ignore.yml index e519b8764d7..d6e2dc75dfd 100644 --- a/__tests__/spelling-ignore.yml +++ b/__tests__/spelling-ignore.yml @@ -239,6 +239,9 @@ - substring - initialisms - sublist +- tokenize +- tokenized +- subsequence # Parts of Unicode - 000A diff --git a/pages/glossary/label-in-name-algorithm.md b/pages/glossary/label-in-name-algorithm.md index 4e15a14d60f..39bb39c3112 100755 --- a/pages/glossary/label-in-name-algorithm.md +++ b/pages/glossary/label-in-name-algorithm.md @@ -16,8 +16,8 @@ Sub-algorithm to tokenize a string: - Convert the string to lower case. - For each character that either a) represents non-text content, or b) isn't a letter or a digit: replace that character with a space character. - - For a) Judgement of "non-text" probably can't be fully automated. eg. "X" for "close" probably can be, but presumably there are more cases than this. - - For b) Use the unicode classes Letter, Mark, and "Number, Decimal Digit [Nd]". (This will exclude hyphens, punctuation, emoji, and more.) + - For a) Judgment of "non-text" probably can't be fully automated. eg. "X" for "close" probably can be, but presumably there are more cases than this. + - For b) Use the Unicode classes Letter, Mark, and "Number, Decimal Digit [Nd]". (This will exclude hyphens, punctuation, emoji, and more.) - Remove all characters that are within parentheses (AKA round brackets). - Ignore square brackets and braces. - Split the string into a list of strings, using a whitespace regular expression as the separator. From 53fe350a88598847b961471bf95bd3cdbf3793e6 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 13 Dec 2023 12:06:44 -0500 Subject: [PATCH 20/38] fixing more failing tests in __tests__/spelling.js --- pages/glossary/label-in-name-algorithm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/glossary/label-in-name-algorithm.md b/pages/glossary/label-in-name-algorithm.md index 39bb39c3112..b2e5f53a126 100755 --- a/pages/glossary/label-in-name-algorithm.md +++ b/pages/glossary/label-in-name-algorithm.md @@ -16,7 +16,7 @@ Sub-algorithm to tokenize a string: - Convert the string to lower case. - For each character that either a) represents non-text content, or b) isn't a letter or a digit: replace that character with a space character. - - For a) Judgment of "non-text" probably can't be fully automated. eg. "X" for "close" probably can be, but presumably there are more cases than this. + - For a) Judgment of "non-text" probably can't be fully automated. For example: "X" for "close" probably can be automated, but presumably there are more cases than this. - For b) Use the Unicode classes Letter, Mark, and "Number, Decimal Digit [Nd]". (This will exclude hyphens, punctuation, emoji, and more.) - Remove all characters that are within parentheses (AKA round brackets). - Ignore square brackets and braces. From 821de8138eebabbedd1b4483d4a37cd325ab1bf0 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 13 Dec 2023 12:10:30 -0500 Subject: [PATCH 21/38] more fixing of failing test(s) in __tests__/spelling.js --- _rules/visible-label-in-accessible-name-2ee8b8.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index 0778a6d5dfc..6813cd77b54 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -378,7 +378,7 @@ This email text field does not need to have its [visible inner text][] match the #### Inapplicable Example 3 -This `div` element does not have a widget role, so the [visible inner text][]t does not need to match the [accessible name][]. +This `div` element does not have a widget role, so the [visible inner text][] does not need to match the [accessible name][]. ```html

From f9e72723e74e842e5f6fe280e95883d4bbc8be8b Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Mon, 5 Feb 2024 18:04:04 -0500 Subject: [PATCH 22/38] adding glossary definition inlined section. --- _rules/visible-label-in-accessible-name-2ee8b8.md | 1 + 1 file changed, 1 insertion(+) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index 6813cd77b54..67190ecba41 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -396,6 +396,7 @@ This link has no [visible inner text][]. [accessible name]: #accessible-name 'Definition of accessible name' [non-text content]: https://www.w3.org/TR/WCAG21/#dfn-non-text-content 'WCAG Definition of Non-text content' +[label in name algorithm]: #label-in-name-algorithm 'Definition of Label in Name Algorithm' [presentational roles conflict resolution]: https://www.w3.org/TR/wai-aria-1.1/#conflict_resolution_presentation_none 'Presentational Roles Conflict Resolution' [semantic role]: #semantic-role 'Definition of Semantic role' [supports name from content]: https://www.w3.org/TR/wai-aria-1.1/#namefromcontent 'Definition of Supports name from contents' From ae2273aaedf3b5af26f428158fcf6e439c26ef56 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Mon, 5 Feb 2024 18:09:00 -0500 Subject: [PATCH 23/38] changing example to match kathy's recent merged PR this commit: https://github.com/act-rules/act-rules.github.io/pull/2101/commits/3add10ea229b79f0131a13f60caab529e6968cd2 as per review comment: https://github.com/act-rules/act-rules.github.io/pull/2101/files/9590ae3174691417d13a0096e4330a95d8d27357#r1422056763 --- _rules/visible-label-in-accessible-name-2ee8b8.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index 67190ecba41..529b5201d9d 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -306,7 +306,7 @@ This button's accessible name contains the same tokens that are in the visible l This link's accessible name contains the same digits that are in the visible label, and in the same order. But they have different spaces and punctuation between them, so they are considered separate tokens. So this fails the rule. ```html -123.456.7890 +123.456.7890 ``` #### Failed Example 12 From d4f8076b6337141164d3f6e787af1d06741b421a Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Mon, 5 Feb 2024 18:28:38 -0500 Subject: [PATCH 24/38] adding failed example to emphasize that a word in the middle will cause a rule failure. --- ...visible-label-in-accessible-name-2ee8b8.md | 22 +++++++++++++------ 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index 529b5201d9d..fd7b9787c44 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -301,7 +301,15 @@ This button's accessible name contains the same tokens that are in the visible l ``` -#### Failed Example 11 +#### Failed Example 11 + +This button's accessible name contains the word "the" in the middle of it, which causes the sublist check of the [label in name algorithm][] (in particular: the "consecutive" requirement of that check) to fail. So it fails the rule. + +```html + +``` + +#### Failed Example 12 This link's accessible name contains the same digits that are in the visible label, and in the same order. But they have different spaces and punctuation between them, so they are considered separate tokens. So this fails the rule. @@ -309,7 +317,7 @@ This link's accessible name contains the same digits that are in the visible lab 123.456.7890 ``` -#### Failed Example 12 +#### Failed Example 13 This rule has no special handling which tries to guess when number have the same semantic meaning. It operates on tokens only. @@ -317,7 +325,7 @@ This rule has no special handling which tries to guess when number have the same 2021 ``` -#### Failed Example 13 +#### Failed Example 14 Similar to the previous example. @@ -325,7 +333,7 @@ Similar to the previous example. fibonacci: 0112358132134 ``` -#### Failed Example 14 +#### Failed Example 15 This rule has no special handling for converting digits into words, or vice versa. @@ -333,7 +341,7 @@ This rule has no special handling for converting digits into words, or vice vers two thousand twenty-one ``` -#### Failed Example 15 +#### Failed Example 16 (Same as above.) This rule has no special handling for converting digits into words, or vice versa. @@ -341,7 +349,7 @@ This rule has no special handling for converting digits into words, or vice vers 2 0 2 3 ``` -#### Failed Example 16 +#### Failed Example 17 This rule has no special handling for digits that appear next to letters with no spaces in between. @@ -349,7 +357,7 @@ This rule has no special handling for digits that appear next to letters with no 1 ``` -#### Failed Example 17 +#### Failed Example 18 The definition of [visible inner text][] doesn't treat text any differently if it's excluded from the accessibility tree with aria-hidden. So this rule effectively ignores aria-hidden. So this element fails the rule. From 2dcd941d3a853e5dcee6acfc0332ac9de1b72515 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Mon, 5 Feb 2024 18:54:23 -0500 Subject: [PATCH 25/38] . --- _rules/visible-label-in-accessible-name-2ee8b8.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index fd7b9787c44..bb79629bfee 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -141,7 +141,7 @@ Similar to the previous example. #### 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. ```html From 22ad17ba40c9248947538331fbf8cb5e536a0337 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Tue, 6 Feb 2024 14:01:33 -0500 Subject: [PATCH 26/38] Fixing mistaken branch/merge. This commit replaces this file with the contents from commit 86a8b09d8856c8b93894c52d14e6592bdb0ac5d3 i.e. upstream/develop. I think that my mistake was: I committed a certain unrelated commit (intended for a feature branch unrelated to this one) onto my fork's develop branch. That was commit 81caf8a7c954a6869da49443bf5eef015e9b346a. What I should have done at that time was: make that commit onto my feature branch presentational-children-no-focusable-content-307n5z---examples-aug-2023. --- ...al-children-no-focusable-content-307n5z.md | 99 ++----------------- 1 file changed, 6 insertions(+), 93 deletions(-) diff --git a/_rules/presentational-children-no-focusable-content-307n5z.md b/_rules/presentational-children-no-focusable-content-307n5z.md index c806d471442..a5e541cbbd7 100755 --- a/_rules/presentational-children-no-focusable-content-307n5z.md +++ b/_rules/presentational-children-no-focusable-content-307n5z.md @@ -67,7 +67,7 @@ None of these `button` elements has [descendants][] that are included in [sequen #### Passed Example 2 -This element with the `checkbox` role has no [descendants][] that are included in [sequential focus navigation][]. Instead the link to the terms of service is adjacent, and `aria-labelledby` is used to provide its [accessible name][]. +This element with `checkbox` role has no [descendants][] that are included in [sequential focus navigation][]. Instead the link to the terms of service is adjacent, and `aria-labelledby` is used to provide its [accessible name][]. ```html

@@ -80,7 +80,7 @@ This element with the `checkbox` role has no [descendants][] that are included i #### Passed Example 3 -This element with the `menuitemcheckbox` role has an `input` element as a descendant. Because the `input` is disabled it is not included in [sequential focus navigation][]. +This element with `menuitemcheckbox` role has an `input` element as a descendant. Because the `input` is disabled it is not included in [sequential focus navigation][]. **Note**: The `input` checkbox has a `role` [attribute value][] of `none` to ensure it is ignored by browsers that do not support [presentational children][]. @@ -93,15 +93,6 @@ This element with the `menuitemcheckbox` role has an `input` element as a descen ``` -#### Passed Example 4 - -This ` -``` - - ### Failed #### Failed Example 1 @@ -117,7 +108,7 @@ This `button` element has a [child][] `span` element. Because the `span` element #### Failed Example 2 -This element with the `checkbox` role has an `a` element as a [child][]. Because the `a` element has an `href` attribute, it is included in [sequential focus navigation][]. +This element with `checkbox` role has an `a` element as a [child][]. Because the `a` element has an `href` attribute, it is included in [sequential focus navigation][]. ```html

I agree to the terms of service

@@ -125,7 +116,7 @@ This element with the `checkbox` role has an `a` element as a [child][]. Because #### Failed Example 3 -This element with the `menuitemcheckbox` role has a checkbox as a child. Because the checkbox is not disabled, it is included in [sequential focus navigation][]. +This element with `menuitemcheckbox` role has a checkbox as a child. Because the checkbox is not disabled, it is included in [sequential focus navigation][]. ```html
    @@ -136,93 +127,16 @@ This element with the `menuitemcheckbox` role has a checkbox as a child. Because
``` -#### Failed Example 4 - -This element with the `tab` role contains an `` element. The `tab` role has [presentational children][]. The `a` element is included in [sequential focus navigation][]. So the element with the `tab` role fails the rule. (This tablist implementation is non-functional for users. It's not meant to function - it's only meant to show roles.) - -```html - -``` - -#### Failed Example 5 - -This element with the `img` role contains an `` element. The `img` role has [presentational children][]. The `` element is included in [sequential focus navigation][]. So the element with the `img` role fails the rule. (Interestingly, no similar failure is possible with a standard HTML `` element, because according to the HTML specification, the `` element has no closing tag. So it's impossible to put anything inside of an `` element.) - -```html -****** This ASCII art ******* contains a link. -``` - ### Inapplicable #### Inapplicable Example 1 -None of the roles involved in this semantic table have [presentational children][]. (The roles are `table`, `row`, and `cell`, respectively, for the ``, ``, and `
` elements.) So this rule does not apply. +This element has a `link` role which does not have [presentational children][]. ```html - - - - - - - - - - - - -
semantic table header
anchor in semantic table - no problem
+W3C Website ``` -#### Inapplicable Example 2 - -This `` element has a `link` role, which does not have [presentational children][]. So this element - perhaps surprisingly - does not fail this rule, because it's inapplicable. This is the case even though it's invalid HTML. Any time there's a link as the outer element, that will be inapplicable under this rule. (If the elements were switched - that is, if the ` -``` - -#### Inapplicable Example 3 - -The applicability of this rule does not include elements with an explicit role of `presentation`. Only implicit (through roles with [presentational children][]). This example shows that. - -```html - -``` - -#### Inapplicable Example 4 - -The applicability of this rule does not include hidden elements. It only includes presentational elements (through roles with [presentational children][]). These two terms - "hidden" and "presentational" - are often confused. When an element is "hidden", that means that it is completely omitted from the accessibility tree. When an element is "presentational", that means that its semantic role is omitted from the accessibility tree, but its content remains. - -The [ARIA 1.2 specification]https://www.w3.org/TR/wai-aria-1.2/#presentation) mentions this confusion: -
    -
  • -Many individuals erroneously consider role="presentation" to be synonymous with aria-hidden="true" -
    • -
  • -... the presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessibility tree. -
    • -
- -Adding to this confusion is a third term: "decorative". The words "decorative" and "presentational" are often used interchangeably, but that usage is inaccurate. The word "decorative" often appears in a sentence such as "marking an image as decorative" - that is, by adding `alt=""` to an `` element. "Decorative" in that context does mean "hidden" - and "hidden", again, is different from "presentational" - so using "decorative" and "presentational" interchangeably is inaccurate. At the time of writing (August 2023), the ACT definition of "[marked as decorative][]" unfortunately encourages this inaccurate usage: it states that An element is marked as decorative if ... it has an explicit role of none or presentation. - -At any rate: this example shows that this rule does not apply to hidden elements. - -```html - -``` - - [accessible name]: #accessible-name 'Definition of Accessible name' [attribute value]: #attribute-value 'Definition of Attribute value' [semantic role]: #semantic-role 'Definition of Semantic role' @@ -233,4 +147,3 @@ At any rate: this example shows that this rule does not apply to hidden elements [sequential focus navigation]: https://html.spec.whatwg.org/#sequential-focus-navigation 'HTML sequential focus navigation, 2020/10/21' [flat tree]: https://drafts.csswg.org/css-scoping/#flat-tree 'CSS Scoping definition of Flat tree, working draft' [html or svg element]: #namespaced-element -[marked as decorative]: /glossary/#marked-as-decorative \ No newline at end of file From 2dc429f713159a4b96794fd7f8512ebf226d015d Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 7 Feb 2024 12:15:32 -0500 Subject: [PATCH 27/38] fixing failing test spelling.js / retext-repeated-words --- _rules/visible-label-in-accessible-name-2ee8b8.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index 9fc5c2b9d66..aa82fa886f6 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -103,7 +103,7 @@ This button has [visible inner text][] that is contained within the [accessible #### Passed Example 5 -This button has [visible inner text][] text that does not need to be contained within the [accessible name][], because the "x" text node is [non-text content][]. Note: this would need to meet SC 1.1.1 Non text content. +This button has [visible inner text][] that does not need to be contained within the [accessible name][], because the "x" text node is [non-text content][]. Note: this would need to meet SC 1.1.1 Non text content. ```html From 2ab4489819df718171d3e12cb729014d0827319e Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 7 Feb 2024 12:46:11 -0500 Subject: [PATCH 28/38] Adding some clarity to the algorithm's wording. - being more specific with regards to whitespace and  . as per dd8's comment at https://github.com/act-rules/act-rules.github.io/pull/2101#pullrequestreview-1759747573 - misc. other edits. --- pages/glossary/label-in-name-algorithm.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/pages/glossary/label-in-name-algorithm.md b/pages/glossary/label-in-name-algorithm.md index b2e5f53a126..a73fc111e2e 100755 --- a/pages/glossary/label-in-name-algorithm.md +++ b/pages/glossary/label-in-name-algorithm.md @@ -20,18 +20,20 @@ Sub-algorithm to tokenize a string: - For b) Use the Unicode classes Letter, Mark, and "Number, Decimal Digit [Nd]". (This will exclude hyphens, punctuation, emoji, and more.) - Remove all characters that are within parentheses (AKA round brackets). - Ignore square brackets and braces. -- Split the string into a list of strings, using a whitespace regular expression as the separator. +- Split the string into a list of strings, using a greedy [whitespace][] regular expression as the separator. - This 'split' operation must: - - Effectively remove leading and trailing whitespace as a pre-processing step. - - If the string was all whitespace before this operation: result in an empty list. + - Effectively remove leading and trailing [whitespace][]. + - If the input string contains nothing but [whitespace][] before this operation: return an empty list. + - A consequence of using the ACT definition of [whitespace][] here is that all kinds of whitespace are covered. That includes the Unicode code point U+00A0 - the "No-Break Space" - which can be represented by the HTML named character reference ` `. Then do the check: is the tokenized 'label' a sublist of the tokenized 'name'? - This 'sublist' check has these properties: - - It checks whether elements are consecutive or not. i.e. it checks for a substring, in the computer science sense of the term. Not a subsequence. + - It checks whether elements are consecutive or not. That is: it checks for a substring, in the computer science sense of the term. Not a subsequence. - An empty list is a sublist of any list. If the answer is "yes" (that is: the tokenized 'label' is a sublist of the tokenized 'name'), then this algorithm returns "is contained". Otherwise, it returns "is not contained". [accessible name]: #accessible-name 'Definition of accessible name' +[element]: https://dom.spec.whatwg.org/#element [visible inner text]: #visible-inner-text 'Definition of Visible inner text' -[element]: https://dom.spec.whatwg.org/#element \ No newline at end of file +[whitespace][]: #whitespace 'Definition of whitespace' From db37b3b2dfe580a358195654617cd27246a0eb06 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 7 Feb 2024 13:23:56 -0500 Subject: [PATCH 29/38] fixing failing test spelling.js --- __tests__/spelling-ignore.yml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/__tests__/spelling-ignore.yml b/__tests__/spelling-ignore.yml index fe890bf902d..6d2d8bbc531 100644 --- a/__tests__/spelling-ignore.yml +++ b/__tests__/spelling-ignore.yml @@ -177,6 +177,9 @@ - x1 - y1 +# HTML character references +- nbsp + # DOM Events - auxclick - compostionend @@ -252,6 +255,7 @@ - 000B - 000C - 000D +- 00A0 # JSON attributes/ metadata/ methods - testcases From 7b2a05308cd402addfc88253a3b3d65ed7448c9d Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 10 Apr 2024 15:55:53 -0400 Subject: [PATCH 30/38] Visible inner text: handling some uncommon whitespace / visibility cases. Cases handled better as of this commit: - Downloadxspecification - desired visible inner text: "Download specification" - visible inner text before this commit: "Downloadxspecification" - visible inner text as of this commit: "Download specification" - desired == actual. this is good. - Downloadxspecification - desired visible inner text: "Downloadspecification" - visible inner text before this commit: "Downloadxspecification" - visible inner text as of this commit: "Downloadspecification" - desired == actual. this is good. Case not changed by this commit: - Downloadxspecification - desired visible inner text: "Downloadspecification" - visible inner text before this commit: "Downloadxspecification" - visible inner text as of this commit: "Downloadxspecification" - desired != actual. this is (still) bad. it violates this assumption of the rule (visible-label-in-accessible-name-2ee8b8.md): "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." --- pages/glossary/visible-inner-text.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/pages/glossary/visible-inner-text.md b/pages/glossary/visible-inner-text.md index 95402ad8358..4a3c629a934 100755 --- a/pages/glossary/visible-inner-text.md +++ b/pages/glossary/visible-inner-text.md @@ -20,6 +20,8 @@ The visible inner text of a [text node][]< The visible inner text of an [element][] is: - if the [element][] is not [rendered][], its visible inner text is the empty string (`""`); +- if the [element][] is [rendered][] and not [visible][] and has a [bounding box][] which has width greater than 0, its visible inner text is an ASCII space character (`" "`); +- if the [element][] is [rendered][] and not [visible][] and has a [bounding box][] which has width of 0, its visible inner text is the empty string (`""`); - if the [element][] is a [`
`][
] element, its visible inner text is a newline character (`"\n"`); - if the [computed][] [`display`][display] property of the [element][] has an [outer display type][] of `block`, or an [inner display type][] of `table-caption`, the visible inner text of the [element][] is the concatenation of a newline character (`"\n"`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus a newline character (`"\n"`); - if the [computed][] [`display`][display] property of the [element][] has an [inner display type][] of `table-cell` or `table-row`, the visible inner text of the [element][] is the concatenation of an ASCII space character (`" "`) plus the visible inner text of its children (in [tree order][] in the [flat tree][]) plus an ASCII space character (`" "`); @@ -28,6 +30,7 @@ The visible inner text of an [element][ The visible inner text of any other node is the concatenation of the visible inner text of its children (in [tree order][] in the [flat tree][]). +[bounding box]: https://www.w3.org/TR/css-ui-3/#valdef-box-sizing-border-box [
]: https://html.spec.whatwg.org/#the-br-element [computed]: https://drafts.csswg.org/css-cascade/#computed [data]: https://dom.spec.whatwg.org/#concept-cd-data From 9723ed1562c24c28ed16251683b3f4931c63bb53 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Thu, 25 Jul 2024 00:29:24 -0400 Subject: [PATCH 31/38] - adding assumption to handle spelling and hyphenation. because of https://github.com/act-rules/act-rules.github.io/pull/2075#discussion_r1638221266 - adding Unicode case folding and normalization form KD. because of https://github.com/act-rules/act-rules.github.io/pull/2075#discussion_r1563102336 - making the word-breaking step of the algorithm generic to more languages than english. because of https://github.com/act-rules/act-rules.github.io/pull/2075#discussion_r1582880870 --- _rules/visible-label-in-accessible-name-2ee8b8.md | 4 +++- pages/glossary/label-in-name-algorithm.md | 9 ++++++--- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index aa82fa886f6..167d8cbf470 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -45,7 +45,9 @@ For the target element, the [visible inner text][] is contained within the [acce 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 neither the label nor the [visible inner text][] are rearranged with CSS so that they appear to the user in a different order than they appear in the DOM. + +This rule assumes that for any word which appears in both the accessible name and the visible label, the same spelling and hyphenation is used in both places. For example: if "non-negative" is used in the accessible name and "nonnegative" is used in the visible label, that would violate this assumption. Or if "color" is used in the accessible name and "colour" is used in the visible label, that would also violate this assumption. 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). diff --git a/pages/glossary/label-in-name-algorithm.md b/pages/glossary/label-in-name-algorithm.md index a73fc111e2e..747bcb99802 100755 --- a/pages/glossary/label-in-name-algorithm.md +++ b/pages/glossary/label-in-name-algorithm.md @@ -14,17 +14,18 @@ Let 'label' be the [visible inner text][] of the target element. Let 'name' be Sub-algorithm to tokenize a string: -- Convert the string to lower case. +- Do Unicode [case folding][] on the string then convert it to [normalization form KD][]. - For each character that either a) represents non-text content, or b) isn't a letter or a digit: replace that character with a space character. - For a) Judgment of "non-text" probably can't be fully automated. For example: "X" for "close" probably can be automated, but presumably there are more cases than this. - For b) Use the Unicode classes Letter, Mark, and "Number, Decimal Digit [Nd]". (This will exclude hyphens, punctuation, emoji, and more.) - Remove all characters that are within parentheses (AKA round brackets). - Ignore square brackets and braces. -- Split the string into a list of strings, using a greedy [whitespace][] regular expression as the separator. +- Split the string into a list of strings, one string per word, according to the word segmentation rules for the inherited programmatic language. - This 'split' operation must: - Effectively remove leading and trailing [whitespace][]. - If the input string contains nothing but [whitespace][] before this operation: return an empty list. - - A consequence of using the ACT definition of [whitespace][] here is that all kinds of whitespace are covered. That includes the Unicode code point U+00A0 - the "No-Break Space" - which can be represented by the HTML named character reference ` `. + - In English and most other European languages, a greedy [whitespace][] regular expression will accomplish this. In languages such as Thai, Chinese, and Japanese, it won't. + - A consequence of using the ACT definition of [whitespace][] here is that all kinds of whitespace are covered. That includes the Unicode code point U+00A0 - the "No-Break Space" - which can be represented by the HTML named character reference ` `. Then do the check: is the tokenized 'label' a sublist of the tokenized 'name'? - This 'sublist' check has these properties: @@ -34,6 +35,8 @@ Then do the check: is the tokenized 'label' a sublist of the tokenized 'name'? If the answer is "yes" (that is: the tokenized 'label' is a sublist of the tokenized 'name'), then this algorithm returns "is contained". Otherwise, it returns "is not contained". [accessible name]: #accessible-name 'Definition of accessible name' +[case folding]: https://www.w3.org/TR/charmod-norm/#dfn-case-folding [element]: https://dom.spec.whatwg.org/#element +[normalization form KD]: https://www.unicode.org/glossary/#normalization_form_kd [visible inner text]: #visible-inner-text 'Definition of Visible inner text' [whitespace][]: #whitespace 'Definition of whitespace' From 4da530099d4349bd0c53f46ed1b2292070a5d108 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Thu, 26 Sep 2024 10:39:46 -0400 Subject: [PATCH 32/38] Assumptions: - adding "whitespace via CSS" clause to address review comment https://github.com/act-rules/act-rules.github.io/pull/2075#issuecomment-2371761443 - rewording other parts. --- _rules/visible-label-in-accessible-name-2ee8b8.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index 167d8cbf470..3542f2d02b6 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -43,9 +43,11 @@ For the target element, the [visible inner text][] is contained within the [acce ## 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 the [visible inner text][] is equal to the [label][https://www.w3.org/WAI/WCAG21/Understanding/label-in-name#dfn-label], 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 so that they appear to the user in a different order than they appear in the DOM. +This rule assumes that the visible label isn't rearranged with CSS so that it appears to the user in a different order than it appears in the DOM. + +This rule assumes that the visible label doesn't use CSS to add whitespace where none exists in the DOM. This rule assumes that for any word which appears in both the accessible name and the visible label, the same spelling and hyphenation is used in both places. For example: if "non-negative" is used in the accessible name and "nonnegative" is used in the visible label, that would violate this assumption. Or if "color" is used in the accessible name and "colour" is used in the visible label, that would also violate this assumption. From 6be702c4418e0129ef78ba1c14ba38409f400bd8 Mon Sep 17 00:00:00 2001 From: Daniel Date: Tue, 18 Feb 2025 14:37:06 +0100 Subject: [PATCH 33/38] Put back removed exceptions --- __tests__/spelling-ignore.yml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/__tests__/spelling-ignore.yml b/__tests__/spelling-ignore.yml index 9126ede0077..4355be43a4d 100644 --- a/__tests__/spelling-ignore.yml +++ b/__tests__/spelling-ignore.yml @@ -136,7 +136,7 @@ - ozplayer - GitHub -# Test case anomolies +# Test case anomalies - brewitt-taylor - level2-frame1 - level1-frame2 @@ -244,6 +244,9 @@ - focusability - unitless - luminance +- disambiguated +- superclass +- grey - substring - initialisms - sublist @@ -256,6 +259,9 @@ - 000B - 000C - 000D +- 4E00 +- 9FFF +- 4E00–9FFF - 00A0 # JSON attributes/ metadata/ methods From 0d4c543d520190f3eb9c7890d7f07da5d1b407aa Mon Sep 17 00:00:00 2001 From: Daniel Date: Tue, 18 Feb 2025 14:41:12 +0100 Subject: [PATCH 34/38] Add missing exxception --- __tests__/spelling-ignore.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/__tests__/spelling-ignore.yml b/__tests__/spelling-ignore.yml index 4355be43a4d..1bc759851fb 100644 --- a/__tests__/spelling-ignore.yml +++ b/__tests__/spelling-ignore.yml @@ -263,6 +263,7 @@ - 9FFF - 4E00–9FFF - 00A0 +- KD # JSON attributes/ metadata/ methods - testcases From a959b09e92c3fc9371d72d0c7aa71b46b3ed9043 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Wed, 19 Feb 2025 07:19:34 -0500 Subject: [PATCH 35/38] minor rewording. based on review. --- _rules/visible-label-in-accessible-name-2ee8b8.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index db23b6250b9..3f941944b4e 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -56,7 +56,7 @@ This rule assumes that the visible label isn't rearranged with CSS so that it ap This rule assumes that the visible label doesn't use CSS to add whitespace where none exists in the DOM. -This rule assumes that for any word which appears in both the accessible name and the visible label, the same spelling and hyphenation is used in both places. For example: if "non-negative" is used in the accessible name and "nonnegative" is used in the visible label, that would violate this assumption. Or if "color" is used in the accessible name and "colour" is used in the visible label, that would also violate this assumption. +This rule assumes that for any word which appears in both the accessible name and the visible label, the same spelling and hyphenation is used in both places. For example: if "non-negative" is used in the accessible name and "nonnegative" is used in the visible label, that would violate this assumption. Similarly, if "color" is used in the accessible name and "colour" is used in the visible label, that would also violate this assumption. 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). From f1219c84e9e740c409853a46e1b0ea1038e69799 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Mon, 24 Feb 2025 13:53:59 -0500 Subject: [PATCH 36/38] Adding an assumption about round brackets and the human language. As per review comment https://github.com/act-rules/act-rules.github.io/pull/2075#discussion_r1961630462 --- _rules/visible-label-in-accessible-name-2ee8b8.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index 3f941944b4e..f43e003f6c2 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -58,6 +58,8 @@ This rule assumes that the visible label doesn't use CSS to add whitespace where This rule assumes that for any word which appears in both the accessible name and the visible label, the same spelling and hyphenation is used in both places. For example: if "non-negative" is used in the accessible name and "nonnegative" is used in the visible label, that would violate this assumption. Similarly, if "color" is used in the accessible name and "colour" is used in the visible label, that would also violate this assumption. +This rule - specifically, the [label in name algorithm][] that this rule relies on - assumes that the algorithm's treatment of parentheses is appropriate in the given human language. "Parentheses" are also known as "round brackets". The algorithm's treatment of parentheses is to remove them and all characters within them. This assumption can be reworded as: content within parentheses can be ignored. This assumption is almost always true in English. It is known to be often false in other languages, such as German (where parentheses indicate dual states) and Arabic (where parentheses are often used as quotation marks). Violations of this assumption will, in real-world scenarioes, more often result in a false negative for this rule rather than a false positive. + 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 From f9850c8d9faffc8af2fc1029812f3d651d8101e4 Mon Sep 17 00:00:00 2001 From: "U-CPHDOMAIN\\dtr" Date: Mon, 24 Feb 2025 13:55:57 -0500 Subject: [PATCH 37/38] Fixing typo. --- _rules/visible-label-in-accessible-name-2ee8b8.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index f43e003f6c2..aef70454f25 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -58,7 +58,7 @@ This rule assumes that the visible label doesn't use CSS to add whitespace where This rule assumes that for any word which appears in both the accessible name and the visible label, the same spelling and hyphenation is used in both places. For example: if "non-negative" is used in the accessible name and "nonnegative" is used in the visible label, that would violate this assumption. Similarly, if "color" is used in the accessible name and "colour" is used in the visible label, that would also violate this assumption. -This rule - specifically, the [label in name algorithm][] that this rule relies on - assumes that the algorithm's treatment of parentheses is appropriate in the given human language. "Parentheses" are also known as "round brackets". The algorithm's treatment of parentheses is to remove them and all characters within them. This assumption can be reworded as: content within parentheses can be ignored. This assumption is almost always true in English. It is known to be often false in other languages, such as German (where parentheses indicate dual states) and Arabic (where parentheses are often used as quotation marks). Violations of this assumption will, in real-world scenarioes, more often result in a false negative for this rule rather than a false positive. +This rule - specifically, the [label in name algorithm][] that this rule relies on - assumes that the algorithm's treatment of parentheses is appropriate in the given human language. "Parentheses" are also known as "round brackets". The algorithm's treatment of parentheses is to remove them and all characters within them. This assumption can be reworded as: content within parentheses can be ignored. This assumption is almost always true in English. It is known to be often false in other languages, such as German (where parentheses indicate dual states) and Arabic (where parentheses are often used as quotation marks). Violations of this assumption will, in real-world scenarios, more often result in a false negative for this rule rather than a false positive. 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). From b77023cd3694a00cb7e9789b83f09b68e513be4e Mon Sep 17 00:00:00 2001 From: Dan Tripp <113939352+dan-tripp-siteimprove@users.noreply.github.com> Date: Thu, 27 Mar 2025 14:20:17 -0400 Subject: [PATCH 38/38] Update _rules/visible-label-in-accessible-name-2ee8b8.md Co-authored-by: Mike Gower --- _rules/visible-label-in-accessible-name-2ee8b8.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index aef70454f25..837d7257852 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -223,7 +223,7 @@ This example passes the rule because "YYYY-MM-DD" is in brackets. Text in bracke #### Passed Example 15 -The passes for two reasons: 1) because the ellipsis ("…") is [non-text content][], and 2) because the ellipsis is neither a letter nor a digit and so is filtered out by the [label in name algorithm][]. +This passes for two reasons: 1) because the ellipsis ("…") is [non-text content][], and 2) because the ellipsis is neither a letter nor a digit and so is filtered out by the [label in name algorithm][]. ```html