3.1.2 Language of Parts - Computed acc name clarification + ambiguous example #4423
Conversation
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
@@ -141,14 +141,27 @@ Alternative language links |
|||
| ... | |||
| <li><a href="..." lang="zh-hant">繁體中文</a></li> | |||
| </ul> | |||
|
|
|||
Element's content used as accessible name |
|||
There was a problem hiding this comment.
I'd preface this section with a preamble about the limitation of current assistive technologies in handling changes of language as part of their accessible name calculation. Explaining that while theoretically correct, switching language inside the accname is not currently supported. This then leads into the first example as simple mitigation.
Would be interested to know if this issue just happens in forms mode or also in browse mode? Does it also affect accessible description? Any other scenarios?
in the second example, you're technically not "setting" the parent element to the primary language ... you're letting it inherit the language from the document's overall language. and it's perhaps not that this is "acceptable", but rather that it's still required to do so (but being aware that AT may not switch language when announcing the link).
Closes: #4420
Description:
This PR aims to clarify the last scenario in the understanding doc
Españolediting a little bit the example.Additionally, it introduces a few more examples to address previously uncovered scenarios. It highlights the recommendation that when an element with an accessible name calculated from its content is in a different language, the lang attribute should be applied directly to that element. It also acknowledges that if the computed name includes multiple languages, it's acceptable to use the primary language of the sentence for that portion.