8000 3.1.2 Language of Parts - Computed acc name clarification + ambiguous example · Issue #4420 · w3c/wcag · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

3.1.2 Language of Parts - Computed acc name clarification + ambiguous example #4420

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
giacomo-petri opened this issue May 26, 2025 · 4 comments · May be fixed by #4423
Open

3.1.2 Language of Parts - Computed acc name clarification + ambiguous example #4420

giacomo-petri opened this issue May 26, 2025 · 4 comments · May be fixed by #4423
Assignees
@giacomo-petri
Labels
3.1.2 Language of Parts

Comments

@giacomo-petri
Copy link
Contributor

In the Understanding of 3.1.2 Language of Parts, I think we need to more clearly define the expected outcome for cases where the computed accessible name is derived from an (or the sum of) element's content.

Assumption: All examples are part of an English (lang="en") page.

  • Scenario 1: 
    <html lang="en">
    ...
    <a href="#">Italiano</a>
    ...
</html>
    Failure, missing lang
  • Scenario 2: 
    <html lang="en">
    ...
    <a href="#" lang="it">Italiano</a>
    ...
</html>
    Pass, lang properly set
  • Scenario 3: 
    <html lang="en">
    ...
    <a href="#" title="Italian"><span lang="it">Italiano</span></a>
    ...
</html>
    IMO ambiguous.
    Based on the last example in the Understanding Language of Parts (The element's content and attribute values are in different languages), it appears this pattern is intended to pass.
    However, it's a confusing implementation. The accessible name is derived solely from the span's content, which is correctly marked with lang="it". Yet the link element itself lacks a lang attribute, which cause screen readers, like VO, to announce the link using the page's default language (English), resulting in a mismatched accent or pronunciation. The title attribute (in English) does not contribute to the accessible name and does not resolve the issue.
    Without additional context, it would be cleaner and more reliable to write:
    <a href="#" lang="it">Italiano</a>
    If the current implementation (with title) is intentional, we should provide more explanation to clarify the rationale, why the title is included and how it supports accessibility in that particular scenario.
  • Scenario 4: 
    <html lang="en">
    ...
    <a href="#"><span lang="it">Italiano</span></a>
    ...
</html>
    This scenario is similar to the previous one but omits the use of the title attribute. In my opinion, unless this implementation is essential for a specific reason, it should be considered a failure of the Success Criterion, since the intended outcome, having the link text "Italiano" announced with the correct pronunciation, is not achieved, as it is instead read with an English accent.
  • Scenario 5: 
    <html lang="en">
    ...
    <a href="#">Read this book: <span lang="it">La Divina Commedia</span></a>
    ...
</html>
    One could argue that "Read this book" doesn't necessarily need to be part of the link, but let's set that aside for now.
    The accessible name contains a mixture of languages (English + Italian). There is currently no way to set multiple languages for a single accessible name.
    In this case, I think we should accept the scenario due to practical limitations (and clarify that in the Understanding). However, scenarios like 3 and 4 (where the entire name is in a different language) are more problematic and arguably should fail, unless this behavior is essential for the content.

Also, in light of the above discussion, the final example titled "The element's content and attribute values are in different languages" should be better described.

This example assumes that the page's default content is in English. The link's title attribute is in English, but the nested span element that contains the word Español has a lang="es" attribute.

<a title="Spanish" href="qa-html-language-declarations-es.html"><span lang="es">Español</span></a>

We should also clarify whether this solution is:

  • Always acceptable, even if the accessible name of the link (in Spanish) is announced with an English accent, and, if so, explain why the presence of the title attribute is considered sufficient.
  • Acceptable only in specific contexts, and if that's the case, clearly explain why it is acceptable in this particular scenario, so that users can understand the conditions under which this pattern is appropriate.
@patrickhlauke
Copy link
Member

I suspect that some of the examples are based mostly on wishful thinking of what screen readers should be doing. Logically, they make sense, but support for it is not there yet.

@mbgower
Copy link
Contributor
mbgower commented May 28, 2025 •
edited
Loading

@giacomo-petri I'm inclined to agree with @patrickhlauke that you are partly surfacing issues with screen reader implementation.

The SC wording is that "The human language of each passage or phrase in the content can be programmatically determined

In those cases where they can be determined from the code, I think they pass. There is the whole question around how one supports/reports "accessibility supported", but I have seen no agreement on how to treat that.

Another thing you could do is review https://www.w3.org/WAI/standards-guidelines/act/rules/de46e4/ or other established ACT rules and see if you agree with their assessments of various examples, and even propose some of yours as tests they could consider.

If you feel this response is sufficient, please close the ticket. Otherwise, indicate what further action you'd like on the TF's part.

@patrickhlauke
Copy link
Member

I'd suggest at the very least adding a note next to those examples saying that they MAY not reflect current support...don't want to mislead authors by giving examples (even though just in non-normative documents) that don't actually work in practice

@mbgower
Copy link
Contributor
mbgower commented May 29, 2025

Oh, hold on. I missed the point about the last example in the existing Understanding document already existing, sorry!
@giacomo-petri feel at liberty to make a PR updating the wording and final example in whatever way you think is most consistently supported.

@giacomo-petri giacomo-petri self-assigned this May 29, 2025
@giacomo-petri giacomo-petri linked a pull request Jun 3, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@giacomo-petri giacomo-petri

Labels
3.1.2 Language of Parts
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

3.1.2 Language of Parts - Computed acc name clarification + ambiguous example w3c/wcag
3 participants
@patrickhlauke @mbgower @giacomo-petri
0