Skip to content
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.

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

Should the mappings of a nested 'svg' be different from that of a root 'svg'? #18

Open
joanmarie opened this issue Oct 18, 2021 · 1 comment

Comments

@joanmarie
Copy link
Contributor

The SVG-AAM's role mappings does not state any distinction between a nested svg element and the root svg element. Thus every svg is a graphics-document role (modulo the pending issue #12).

I wasn't sure if that was intended or not. Nor is it what Chromium currently does. Before filing a silly bug here, I asked my silly question on Twitter. @AmeliaBR said:

It should at least be the same rules as a <g> (which means, role/whether it gets exposed depends on the presence of a name or other ARIA attributes).

and

Yeah, I think a group role would usually be better than calling out <svg><svg> as a nested graphic. Although the graphics-doc role allows for nesting, using a nested <svg> vs <g> is usually a technical distinction with no semantics.

pull bot pushed a commit to luojiguicai/chromium that referenced this issue Oct 19, 2021
Map nested 'svg' elements to the group role rather than the generic-
container role. Doing so should increase the likelihood that assistive
technologies will present the author-provided names of nested 'svg'
elements.

Note that at the present time the SVG-AAM does not have distinct role
mappings for root and nested 'svg' elements. However, initial feedback
is that treating nested 'svg' elements as 'g' is the right thing to do.
See w3c/svg-aam#18

AX-Relnotes: Expose nested 'svg' as a group rather than a generic
container so that ATs are more likely to present author-provided names.

Bug: 231654
Change-Id: I7ca09e425b46704f43fbb29cd38139849012b660
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3231175
Commit-Queue: Joanmarie Diggs <[email protected]>
Reviewed-by: Aaron Leventhal <[email protected]>
Cr-Commit-Position: refs/heads/main@{#933052}
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
Map nested 'svg' elements to the group role rather than the generic-
container role. Doing so should increase the likelihood that assistive
technologies will present the author-provided names of nested 'svg'
elements.

Note that at the present time the SVG-AAM does not have distinct role
mappings for root and nested 'svg' elements. However, initial feedback
is that treating nested 'svg' elements as 'g' is the right thing to do.
See w3c/svg-aam#18

AX-Relnotes: Expose nested 'svg' as a group rather than a generic
container so that ATs are more likely to present author-provided names.

Bug: 231654
Change-Id: I7ca09e425b46704f43fbb29cd38139849012b660
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3231175
Commit-Queue: Joanmarie Diggs <[email protected]>
Reviewed-by: Aaron Leventhal <[email protected]>
Cr-Commit-Position: refs/heads/main@{#933052}
NOKEYCHECK=True
GitOrigin-RevId: 6892d3a75290f138c2cc815344c50e8105ac45da
@brennanyoung
Copy link

brennanyoung commented Dec 8, 2022

I ended up doing the foolish thing, and trusting the spec. Turns out, the browsers don't follow the spec, and map SVG to group by default. The specs about default accessibility mappings for SVG are extremely confusing, scattered over at least three documents, which refer to each other, and even then, there are gaps.

Perhaps we should start with the question: In which spec should the default mapping for SVG-in-HTML belong?

Clarity please!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants