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

Implicit role of SVG element is different in html-aria and html-aam #158

Closed
Jym77 opened this issue Jul 18, 2019 · 5 comments · Fixed by #264
Closed

Implicit role of SVG element is different in html-aria and html-aam #158

Jym77 opened this issue Jul 18, 2019 · 5 comments · Fixed by #264

Comments

@Jym77
Copy link

Jym77 commented Jul 18, 2019

I'm a bit new to all this, and not sure I'm reading the docs correctly…

Anyway, it seems that the implicit aria semantics of the <svg> element (in HTML) is defined as "No corresponding role" in html-aria, with allowed roles or "application, document or img".

But in the HTML AAM, the <svg> element is listed with a WAI-ARIA role of graphics-document which contradicts both the default and allowed roles of html-aria…

@scottaohara
Copy link
Member

ARIA does not have a role=graphics-document for use by authors, so there is no corresponding role for ARIA in HTML to list.

HTML AAM specifies how elements map to different accessibility APIs. Following the WAI ARIA mapping link for graphics-document will take you to the Graphics Accessibility API Mappings specification, and notes the different platform mappings for this role.

Does this help answer your question/issue?

@Jym77
Copy link
Author

Jym77 commented Jul 22, 2019

Does this help answer your question/issue?

A bit, but I'm still quite confused…

ARIA does not have a role=graphics-document for use by authors, so there is no corresponding role for ARIA in HTML to list.

But if I look at the WAI-ARIA Graphics Module I do find a role of graphics-document, and the example is using it (as role="graphics-document document"). Thus, I do not fully understand why you say that it's not for use by authors…

Is it because this is part of an extension module for WAI-ARIA and not part of the core of it? Or am I missing something else?

HTML AAM specifies how elements map to different accessibility APIs. Following the WAI ARIA mapping link for graphics-document will take you to the Graphics Accessibility API Mappings specification, and notes the different platform mappings for this role.

Hum, that's a part where I start getting really confused about all these documentations. I am not sure I understand the meaning of the different tables correctly…

  1. WAI-ARIA defines some roles in its Section 5.4. These do not include any graphics-* role.
  2. WAI-ARIA Graphics Module adds 3 graphics-* roles to WAI-ARIA (Section 4.1). I am not entirely sure what is the status of the WAI-ARIA modules (is it something that may optionally be used?)
  3. ARIA in HTML has a table in Section 2 that gives, for each HTML tag (or rather "language feature"), the corresponding implicit ARIA role. For SVG (not svg, I sort of assume that this mean something a bit different than just the svg tag, but includes it (link goes to a spec starting with "The SVG svg element"…)), the implicit ARIA semantics is "No corresponding role" and the allowed roles are application, document, img.
    At first glance, it seems that ARIA in HTML only uses "base" WAI-ARIA roles as implicit roles (and not roles from the modules). I am not completely sure why this is the case (it seems to point to the optionality of using the modules…)
  4. HTML AAM also has a table for HTML element role mappings. I am not completely sure of what this table really is about. I understand that it tells how each element (not "language feature" this time…) is mapped by each accessibility API into some role which can either be WAI-ARIA roles (especially for the WAI-ARIA accessibility API) but also some technology specific things (e.g. name of a constant to use for that role).
    I am not entirely sure why there is a W3C normative document saying how Microsoft is expected to map stuff… I probably have misunderstood something about that table…
    In the case of the svg element, WAI-ARIA is mapping it to graphics-document (making it use the WAI-ARIA Graphics module, raising the question of how optional these modules are).
  5. Graphics AAM seems to be to the WAI-ARIA Graphics module what the HTML AAM is to the "base" of WAI-ARIA and has a Role mapping table telling how the "extra" graphics-* roles (from the WAI-ARIA Graphics module) are mapped by the various Accessibility APIs.

Was is still not clear for me is the status of the element role mapping table in the HTML AAM, and the reason why it as a WAI-ARIA role column.

  1. It seems that this table tells how each element is actually mapped into the various Accessibility APIs, but I do not understand why this is part of a normative W3C document (or draft/WIP).
  2. it seems that the roles listed in the WAI-ARIA column of the element role mapping table are just an indirection (especially when other columns say "Use WAI-ARIA mapping"). The ARIA in HTML table list what the implicit role of each element (language feature) is, the table in the AAM is using an alias. So, for example, ARIA in HTML says that the an "a element with a href" has an implicit role of link, while the HTML AAM says that an a element is mapped by MSAA to whatever MSAA maps something with the alias role of link (and the Core AAM tells me that this is ROLE_SYSTEM_LINK). That makes me feel that the WAI-ARIA column in that table is listing something which are more alias of some mapping rather than role. Especially, this doesn't seem to be the default implicit role for those element (which is defined in ARIA in HTML) and it is just"random" than the AAM are using the same names…
    In other words, if the HTML AAM said that a is mapped to the "foobar thingie" and the Core AAM said that "foobar thingie" is mapped by MSAA to ROLE_SYSTEM_LINK, would something break somewhere? Is the fact that the AAM are using the literal name "link", exactly as it is in the WAI-ARIA definition, important?

To go back to my svg example, I seem to understand now that it has no default role (as per HTML in ARIA) and that MSAA is mapping it to ROLE_SYSTEM_DOCUMENT + STATE_SYSTEM_READONLY (according to the HTML AAM and the redirection to the Graphics AAM)…

That at least makes the specs not inconsistent :-D


Sorry, for the long rant, I sort of derailed the conversation…

@LJWatson
Copy link

I think the ARIA in HTML spec needs updating.

The ARIA Graphics module defines the graphics-document role, and the SVG AAM maps the graphics-document role to the <svg> element when used in a stand-alone SVG document.

Because the <svg> element can also be used inside an HTML document, the HTML AAM maps the graphics-document role to the <svg> element when used in an HTML document.

The rules for using ARIA in HTML should, I think, explain that the implicit role for the <svg> element is graphics-document, and that "Any role" may be applied explicitly.

@stevefaulkner
Copy link
Collaborator

@LJWatson why?

"Any role" may be applied explicitly.

@pkra pkra mentioned this issue Feb 15, 2021
@scottaohara
Copy link
Member

see also discussion in #232 (closed as duplicative of this issue)

scottaohara added a commit that referenced this issue Feb 18, 2021
reference svg aam and `role=graphics-document`
allow any role on svg

closes #261
closes #158
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

Successfully merging a pull request may close this issue.

4 participants