Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

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

Merged
merged 11 commits into from
Jan 11, 2024
Prev Previous commit
Next Next commit
Update visible-label-in-accessible-name-2ee8b8.md
kengdoj authored Aug 22, 2023

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
commit c929457363c0e71614d2ce7795c77a3c58618295
6 changes: 3 additions & 3 deletions _rules/visible-label-in-accessible-name-2ee8b8.md
Original file line number Diff line number Diff line change
@@ -38,7 +38,7 @@ This rule applies to any element for which all the following is true:

## Expectation

For each target element, all and only the [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 the [text nodes][] in the [visible text content][] match in sequence 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.
kengdoj marked this conversation as resolved.
Show resolved Hide resolved

## Assumptions

@@ -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][]. Note: this example passes this rule because characters in the text nodes used to express non-text content are not included in the Expectation, but it would need to meet SC 1.1.1 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.
kengdoj marked this conversation as resolved.
Show resolved Hide resolved

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

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