Rule 2ee8b8 ("Visible label is part of accessible name"): introducing a new "label in name algorithm".

dan-tripp-siteimprove commented 1 year ago

<< Describe the changes >>

Closes issue(s):

closes #2051, closes #1989, closes #1619, closes #1615, closes #1458
does not handle: #2040 #1500 #451

Need for Call for Review: This will require a 2 weeks Call for Review

Pull Request Etiquette

When creating PR:

[ x] Make sure you're requesting to pull a branch (right side) to the develop branch (left side).
[x ] Make sure you do not remove the "How to Review and Approve" section in your pull request description

After creating PR:

[ x] Add yourself (and co-authors) as "Assignees" for PR.
[ x] Add label to indicate if it's a Rule, Definition or Chore.
[x ] Link the PR to any issue it solves. This will be done automatically by referencing the issue at the top of this comment in the indicated place.
[ x] Optionally request feedback from anyone in particular by assigning them as "Reviewers".

When merging a PR:

[ ] Close any issue that the PR resolves. This will happen automatically upon merging if the PR was correctly linked to the issue, e.g. by referencing the issue at the top of this comment.

How to Review And Approve

Go to the “Files changed” tab
Here you will have the option to leave comments on different lines.
Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
Make sure to also review the proposed Call for Review period. In case of disagreement, the longer period wins.

WilcoFiers commented 1 year ago

@dan-tripp-siteimprove Since this is being worked on still by @kengdoj, can we set this to draft?

dan-tripp-siteimprove commented 1 year ago

@dan-tripp-siteimprove Since this is being worked on still by @kengdoj, can we set this to draft?

Done

dan-tripp-siteimprove commented 4 months ago

I just pushed a commit a few minutes ago (7b2a05308cd402addfc88253a3b3d65ed7448c9d) which handles some more cases. Namely:

Cases handled better as of this commit:

<a aria-label="Download specification" href="#">Downloadxspecification</a>
- 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.
<a aria-label="Download specification" href="#">Downloadxspecification</a>
- 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:

<a aria-label="Download specification" href="#">Downloadxspecification</a>
- 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: "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."

I think this is enough progress that I'll take this PR out of draft.

dan-tripp-siteimprove commented 4 months ago

Hi Mark - thank you for commenting. Now for some reason I can't see your comment on the github page for this PR. Only in this email. Did you delete the comment? Or am I looking at it wrong?

Regardless, I'll respond to your comments in this email:

One reason I used a "list of strings" (instead of a whitespace-normalized-string) is this case:

(failure) Discover It

I can't think of a way to handle the above case correctly without using a "list of strings". Do you know of one? And either way: is that the only part you thought was too implementation-specific, or are there others?

From: Mark Rogers @.> Sent: Friday, April 12, 2024 3:30 PM To: act-rules/act-rules.github.io @.> Cc: Dan Tripp @.>; Mention @.> Subject: Re: [act-rules/act-rules.github.io] Rule 2ee8b8 ("Visible label is part of accessible name"): introducing a new "label in name algorithm". (PR #2075)

@dd8 commented on this pull request.

In pages/glossary/label-in-name-algorithm.mdhttps://url.avanan.click/v2/___https://github.com/act-rules/act-rules.github.io/pull/2075%23discussion_r1563084831___.YXAxZTpzaXRlaW1wcm92ZS1ldTphOm86ZTFjZGYwZjI2NjcyOTZlYTMwZDI0MDIwMGQ4YTBmNjg6NjpjODIyOjA1MjlhYWNlZmQ0NzJmODVlZjM4YzM4NmY5NGM2NzA2YTgzZTkwODkzOGUxNTg4NThjN2RkZTQ3MzhhODIzMGY6aDpU:

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:

+

+- 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. 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.

This part seems too implementation specific - normalising the strings by trimming and collapsing runs of [whitespace][] then looking for a substring match does the same thing (and is probably faster). Is there a way to write the algorithm in a more general way? (Counter example: the algorithms in specs like the URL Standard are very detailed and describe incrementing pointers)

- Reply to this email directly, view it on GitHubhttps://url.avanan.click/v2/___https://github.com/act-rules/act-rules.github.io/pull/2075%23pullrequestreview-1998291445___.YXAxZTpzaXRlaW1wcm92ZS1ldTphOm86ZTFjZGYwZjI2NjcyOTZlYTMwZDI0MDIwMGQ4YTBmNjg6Njo0NDhiOmY4N2NiMGVmNGZmYmJkZmUxMzJlNTQwY2M3ZDNiODk4ZTljYTY2OGY2M2IxNTZjMTViMzBkZGI5OGM4MWYyMGM6aDpU, or unsubscribehttps://url.avanan.click/v2/___https://github.com/notifications/unsubscribe-auth/A3FJHGELNTR2ELUIU6SG65LY5AY4LAVCNFSM6AAAAAAZPPNL5KVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSOJYGI4TCNBUGU___.YXAxZTpzaXRlaW1wcm92ZS1ldTphOm86ZTFjZGYwZjI2NjcyOTZlYTMwZDI0MDIwMGQ4YTBmNjg6NjoyYWIzOjFmNWJmNmRiYzBlMzBjMjMyOTM4ZDVmZmM2NDVjNWJmOGM4N2EyZDA4MzNhZGI4ODU1YmI5NzY5NmJjY2RmNWM6aDpU. You are receiving this because you were mentioned.Message ID: @.***>

dan-tripp-siteimprove commented 3 weeks ago

@dd8 I just pushed commit 9723ed1562c24c28ed16251683b3f4931c63bb53 which addresses some of your concerns.

dan-tripp-siteimprove commented 3 weeks ago

@dd8 I learned that the conversion of the German "ß" to "ss" is not handled by normalization and is handled by "case folding".

act-rules / act-rules.github.io