Editorial: I18n considerations for translatable attributes - #2862
Editorial: I18n considerations for translatable attributes#2862daniel-montalvo wants to merge 12 commits into
Conversation
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
daniel-montalvo
added
i18n-needs-resolution
|
🚀 Deployed on https://deploy-preview-2862--wai-aria.netlify.app |
xfq
left a comment
xfq
left a comment
There was a problem hiding this comment.
A full stop needs to be added after the last sentence. Otherwise looks good to me.
| The web accessibility stack does not currently provide a mechanism to specify language and directionality for a translatable attribute other than the language and directionality of its containing element. This includes <pref>aria-labelledby</pref> and <pref>aria-describedby</pref> because the <a href="" class="accname">Accessible Name and Description Computation</a> [[ACCNAME-1.2]] results in a flat string. | ||
| </p> | ||
| <p> | ||
| Translatable attribute values that don't match the language and directionality of their containing element can also cause other accessibility problems. It is best practice for authors to ensure that the language and directionality of the value of a translatable attribute matches the language and directionality of its containing element. |
There was a problem hiding this comment.
If you call out "other problems," it would be wise to list a known example.
Alternately, cut the first sentence for brevity, because the second stands on its own.
There was a problem hiding this comment.
I'd just cut off the first sentence as you suggest. Listing individual problems here may end up making this a maintenance burden if the guidance changes in the future.
There was a problem hiding this comment.
I think this is an important sentence to keep. I gave an example in https://github.com/w3c/aria/pull/2849/changes#r3614624182, almost straight from a WCAG failure document.
There was a problem hiding this comment.
I'd be very intrigued to see an intentionally authored example where aria-label is in a different language from the element's content without being problematic.
There was a problem hiding this comment.
Someone kindly pointed me to https://html.spec.whatwg.org/multipage/dom.html#the-lang-and-xml:lang-attributes:
The lang attribute [...] specifies the primary language for the element's contents and for any of the element's attributes that contain text.
Generally speaking, having different (primary) languages in accname and visible content seems to invariably fail WCAG 2.5.3.
Co-authored-by: James Craig <cookiecrook@users.noreply.github.com>
Co-authored-by: James Nurthen <jnurthen@users.noreply.github.com>
daniel-montalvo
moved this to Needs Review
in ARIA Editorial (Spec Prose Updates) PR Tracking
|
@aphillips @xfq I've updated this based on other ARIA members review as well as on our conversation on 6 august. Let me know if you are happy with this or you would propose further tweaks. |
|
I’m a bit confused. The first paragraph seems to suggest that the |
5 participants
🚀 Netlify Preview:
🔄 this PR updates the following sspecs:
Closes #2827