Consider accessible description in the rules that use link context (5effbb, fd3a94)#1845
Consider accessible description in the rules that use link context (5effbb, fd3a94)#1845carlosapaduarte wants to merge 27 commits intodevelopfrom
Conversation
Jym77
left a comment
There was a problem hiding this comment.
I feel it would be cleaner to remove aria-describedby from "Programmatically determined link context". Since the rules now explicitly mention the accessible description, that already includes aria-describedby references (and actually a few more things such as children of aria-describedby references, if I get the accessible name computation correctly).
So, the PDLC would be some set of elements defined by some DOM tree relationship, and rules about context would look at PDLC + accessible description.
(it would also means that aria-describedby="foo bar" and aria-describedby="bar foo" would be considered as different accessible descriptions while they are currently the same PDLC, which sounds bad)
kengdoj
left a comment
There was a problem hiding this comment.
Minor suggestions made.
| #### Passed Example 1 | ||
|
|
||
| These two HTML `a` elements have the same [accessible name][] and [context][programmatically determined link context] and link to the [same resource][]. | ||
| These two HTML `a` elements have the same [accessible name][], [accessible description][] and [context][programmatically determined link context] and link to the [same resource][]. |
There was a problem hiding this comment.
Would be helpful to say "same non-empty accessible name, empty accessible description..."?
There was a problem hiding this comment.
I added it in a couple other spots.
WilcoFiers
left a comment
There was a problem hiding this comment.
I like Kathy's suggestions on these, would like to see them made.
Good suggestion. I'm updating the definition accordingly. |
Co-authored-by: Kathy Eng <kengdoj@users.noreply.github.com>
_rules/links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md
Outdated
Show resolved
Hide resolved
_rules/links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md
Outdated
Show resolved
Hide resolved
…-purpose-fd3a94.md Co-authored-by: Kathy Eng <kengdoj@users.noreply.github.com>
…-purpose-fd3a94.md Co-authored-by: Kathy Eng <kengdoj@users.noreply.github.com>
| ``` | ||
|
|
||
| [accessible name]: #accessible-name 'Definition of Accessible Name' | ||
| [accessible description]: https://www.w3.org/TR/wai-aria-1.2/#dfn-accessible-description 'Definition of accessible description' |
There was a problem hiding this comment.
Should we have our own def of it (like for accessible name?), I'm notably thinking we should link it to the "accessible name and description computation" document.
There was a problem hiding this comment.
Added a definition of accessible description
_rules/links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md
Outdated
Show resolved
Hide resolved
| ## Expectation | ||
|
|
||
| The [accessible name][] of each target element together with its [programmatically determined link context][] describes the purpose of the link. | ||
| The [accessible name][] of each target element together with its [accessible description][] and [programmatically determined link context][] describes the purpose of the link. |
There was a problem hiding this comment.
I'm not sure this is obviously correct. The SC talks about link text and programmatically determined context. Its probably worth putting in the assumption that we're using "link text" from WCAG to mean accessible name and description. Links that fail label in name could have visible text that isn't considered "link text" in this rule. I think that should be in the assumption.
|
|
|
Closing and reopening to trigger checks |
✅ Deploy Preview for act-rules ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Call for review ends July 10 |
|
|
||
| For native markup languages, such as HTML and SVG, additional information on how to calculate the accessible description can be found in [HTML Accessibility API Mappings 1.0, Accessible Name and Description Computation (working draft)](https://www.w3.org/TR/html-aam/#accessible-name-and-description-computation) and [SVG Accessibility API Mappings, Name and Description (working draft)](https://www.w3.org/TR/svg-aam/#mapping_additional). | ||
|
|
||
| **Note:** As per the [accessible name and description computation][], each element with the 'aria-describedby' property always has an accessible description. |
There was a problem hiding this comment.
| **Note:** As per the [accessible name and description computation][], each element with the 'aria-describedby' property always has an accessible description. | |
| **Note:** As per the [accessible name and description computation][], each element with the 'aria-describedby' property pointing to an existing element which content is not the empty string, always has an accessible description. |
| #### Passed Example 9 | ||
|
|
||
| These two HTML `a` elements have the same [accessible name][] and [context][programmatically determined link context], but resolve to different resources. However, the purpose of these links is [ambiguous to users in general](https://www.w3.org/TR/WCAG22/#dfn-ambiguous-to-users-in-general). Thus all readers are unsure about the destination and the person with a disability is not at any disadvantage. | ||
| These two HTML `a` elements have the same [accessible name][], the same [accessible description][], and the same [context][programmatically determined link context], but go to different resources. However, there is no visual information to let users know that both links resolve to non-equivalent resources. |
There was a problem hiding this comment.
Starting with this example, we began using "the same accessible description", whereas in previous cases we used "empty accessible description". I recommend maintaining consistency throughout. It might also be helpful to include examples that uses title or aria-describedby attributes both in passed and failed for comparison.
| - the elements have [matching][] [accessible names][accessible name] that are not empty (`""`); and | ||
| - the elements have the same [programmatically determined link context][]. | ||
| - the elements have [matching][] [accessible descriptions][accessible description]; and | ||
| - have the same [programmatically determined link context][]. |
There was a problem hiding this comment.
| - have the same [programmatically determined link context][]. | |
| - the elements have the same [programmatically determined link context][]. |
consistent with bullets above
| #### Passed Example 9 | ||
|
|
||
| These two HTML `a` elements have the same [accessible name][] and [context][programmatically determined link context], but resolve to different resources. However, the purpose of these links is [ambiguous to users in general](https://www.w3.org/TR/WCAG22/#dfn-ambiguous-to-users-in-general). Thus all readers are unsure about the destination and the person with a disability is not at any disadvantage. | ||
| These two HTML `a` elements have the same [accessible name][], the same [accessible description][], and the same [context][programmatically determined link context], but go to different resources. However, there is no visual information to let users know that both links resolve to non-equivalent resources. |
There was a problem hiding this comment.
| These two HTML `a` elements have the same [accessible name][], the same [accessible description][], and the same [context][programmatically determined link context], but go to different resources. However, there is no visual information to let users know that both links resolve to non-equivalent resources. | |
| These two HTML `a` elements have the same [accessible name][], empty [accessible description][], and the same [context][programmatically determined link context], but go to different resources. However, there is no visual information to let users know that both links resolve to non-equivalent resources. |
| #### Passed Example 1 | ||
|
|
||
| These two HTML `a` elements have the same [accessible name][] and [context][programmatically determined link context] and link to the [same resource][]. | ||
| These two HTML `a` elements have the same non-empty [accessible name][], empty [accessible description][], the same [context][programmatically determined link context], and resolve to the [same resource][]. |
There was a problem hiding this comment.
I think these texts are gettin pretty verbose. Not a blocker if people prefer this language, but I would suggest this:
| These two HTML `a` elements have the same non-empty [accessible name][], empty [accessible description][], the same [context][programmatically determined link context], and resolve to the [same resource][]. | |
| These two links with the same [name][]accessible name], [description][]accessible description] and [context][programmatically determined link context] resolve to the [same resource][]. |
The same for other example descriptions.
WilcoFiers
left a comment
There was a problem hiding this comment.
There are a couple editorial suggestions to consider
Update rules that use link context to consider the title attribute. Although the original resolution in #1766 requested the changes to be made on the "Programmatically Determined Link Context" definition, given that this specifies a set of elements, it does not seem doable. As an alternative, I've added the accessible description to the expectation of "Link in context is descriptive" and to the applicability of "Links with identical accessible names and context serve equivalent purpose"
Closes issue(s):
b20e66,5effbb,aizyf1,fd3a94) consider thetitleattribute? #1766Need for Call for Review:
This will require a 2 weeks Call for Review
How to Review And Approve