Skip to content

Update visible-label-in-accessible-name-2ee8b8.md #2101

New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Jan 11, 2024
Merged

Update visible-label-in-accessible-name-2ee8b8.md #2101

Changes from 8 commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
0267d32
Update visible-label-in-accessible-name-2ee8b8.md
kengdoj Aug 21, 2023
ffd53a2
Update visible-label-in-accessible-name-2ee8b8.md
kengdoj Aug 21, 2023
c929457
Update visible-label-in-accessible-name-2ee8b8.md
kengdoj Aug 22, 2023
9590ae3
Update _rules/visible-label-in-accessible-name-2ee8b8.md
kengdoj Aug 22, 2023
f19e9eb
Update _rules/visible-label-in-accessible-name-2ee8b8.md
kengdoj Nov 9, 2023
b4d18a5
Update _rules/visible-label-in-accessible-name-2ee8b8.md
kengdoj Nov 9, 2023
d1b8f91
Merge branch 'develop' into kengdoj-labelinname
Jym77 Nov 30, 2023
818d342
Update visible-label-in-accessible-name-2ee8b8.md
kengdoj Nov 30, 2023
3401bfb
Merge branch 'develop' into kengdoj-labelinname
Jym77 Dec 7, 2023
3add10e
Update _rules/visible-label-in-accessible-name-2ee8b8.md
kengdoj Dec 12, 2023
f3f701b
Merge branch 'develop' into kengdoj-labelinname
kengdoj Jan 11, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 20 additions & 3 deletions _rules/visible-label-in-accessible-name-2ee8b8.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ 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, all [text nodes][] in the [visible text content][] [match characters][] and 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.

## Assumptions

Expand Down Expand Up @@ -97,10 +97,10 @@ 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][].
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][]. Note: this would need to meet SC 1.1.1 Non text content.

```html
<button aria-label="close">X</button>
<button aria-label="anything">X</button>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we keep the "Close" label, which makes this pass 1.1.1?
(assuming this is indeed a close button)

Copy link
Collaborator Author

@kengdoj kengdoj Oct 30, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the Expectation says

except for characters in the [text nodes][] used to express [non-text content][]

there is no expectation, and this example passes. I used aria-label="anything" to make it clear that really any description would pass this rule. But, you are right that SC 1.1.1 would then be not satisfied. But I'd like to consider SC 1.1.1 being secondary and handle that in a separate PR.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comes up often around here: when passed examples fail something else.

I like it best when there is a note on the passed example which documents that "something else". In this case that note could be: "This example passes the rule and will fail SC 1.1.1".

We could call these "curve ball passed examples".

To have examples like these, and to document them as such, meets two goals, both important:

  • It emphasizes why the example passes the rule. (In this case: "to make it clear that really any description would pass this rule", as Kathy put it). I think that this aids understanding, a lot.
  • It tells everyone that even though this is a "passed example" for this rule, it's not a good example overall, so no one should copy and paste the code.

Jean-Yves did this a lot in the examples for his recent PR 2084:

  • "Using an explicit role of generic for any element is globally not recommended, but not an error by itself."
  • "Using an explicit role which is the same as the implicit role is not recommended, but not an error by itself."
  • "The btn token is not a valid role and is therefore ignored."
  • "Even though the alert role is not allowed, the first token is a valid role and is therefore used."

I think it's a good thing

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works, but perhaps a cleaner way to handle this would be to modify the second condition of the applicability to filter out not just non-visible text content, but also non-text content. That would cause this example to move to the non-applicable section.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, Tom.

But, Applicability has to be objective at this time, so the except non-text content part is under the Expectation section for now.

```

#### Passed Example 6
Expand Down Expand Up @@ -143,6 +143,22 @@ This link has [visible][] text with mathematical symbols, that does not match th
<a href="/" aria-label="Proof of two multiplied by two is four">Proof of 2&times;2=4</a>
```

#### Failed Example 4

This link has [visible][] text does not match the [accessible name][] because there is a hyphen in the accessible name.

```html
<a href="#" aria-label="non-standard">nonstandard</a>
```

#### Failed Example 5

This link has [visible][] text does not match the [accessible name][] because there are extra spaces in the accessible name.

```html
<a aria-label="Call 1 2 3. 4 5 6. 7 8 9 0." href="tel:1234567890">123.456.7890</a>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was the inclusion of a full stop at the end of the aria-label attribute value deliberate? If so, do we need to provide clarification regarding its potential impact on the outcome? In the issue description only extra spaces are mentioned.

Copy link
Collaborator Author

@kengdoj kengdoj Dec 12, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks! I edited the aria-label.

```

### Inapplicable

#### Inapplicable Example 1
Expand Down Expand Up @@ -181,6 +197,7 @@ This link has no [visible text content][].
```

[accessible name]: #accessible-name 'Definition of accessible name'
[match characters]: #matching-characters 'Definition of matching characters'
[non-text content]: https://www.w3.org/TR/WCAG21/#dfn-non-text-content 'WCAG Definition of Non-text content'
[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'
Expand Down