Open dan-tripp-siteimprove opened 1 year ago
@dan-tripp-siteimprove Since this is being worked on still by @kengdoj, can we set this to draft?
@dan-tripp-siteimprove Since this is being worked on still by @kengdoj, can we set this to draft?
Done
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="#"><span>Download</span><span style="visibility: hidden">x</span><span>specification</span></a>
<a aria-label="Download specification" href="#"><span>Download</span><span style="visibility: hidden; width: 0; display: inline-block">x</span><span>specification</span></a>
Case not changed by this commit:
<a aria-label="Download specification" href="#"><span>Download</span><span style="position: absolute; left: -9999px">x</span><span>specification</span></a>
I think this is enough progress that I'll take this PR out of draft.
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.
+- Remove all characters that are within parentheses (AKA round brackets).
+- 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: @.***>
@dd8 I just pushed commit 9723ed1562c24c28ed16251683b3f4931c63bb53 which addresses some of your concerns.
@dd8 I learned that the conversion of the German "ß" to "ss" is not handled by normalization and is handled by "case folding".
<< Describe the changes >>
Closes issue(s):
Need for Call for Review: This will require a 2 weeks Call for Review
Pull Request Etiquette
When creating PR:
develop
branch (left side).After creating PR:
Rule
,Definition
orChore
.When merging a PR:
How to Review And Approve