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

SVG-AAM: Identify elements which support aria-roledescription without an explicit or implicit role #599

Closed
joanmarie opened this issue Jul 5, 2017 · 8 comments

Comments

@joanmarie
Copy link
Contributor

As described in #500, there is a need to prohibit the exposure of the value of aria-roledescription for certain HTML elements (e.g. div and span) when there is no explicit or implicit ARIA role. Alternatively, or in addition, this AAM could explicitly allow the exposure of the value of aria-roledescription on certain elements (an example from HTML would be meter used without an explicit role).

The purpose/motivation behind this request is that we want to strongly discourage authors from using aria-roledescription on elements which lack useful semantic meaning, and we want to strongly encourage (and perhaps insist) that user agents do not expose the value of aria-roledescription when it is used on an element which lacks useful semantic meaning and also lacks an implicit or explicit ARIA role. But there's no way we can come up with a host-language-agnostic, universally-agreed-upon definition of "useful semantic meaning" or "generic element." If such elements are explicitly identified in the host-language-specific AAMs, we (ARIA spec and/or Core AAM) should be able to point authors and user agents to those specs to get the implementation and user experience desired and intended for aria-roledescription.

@joanmarie joanmarie changed the title SVG-AAM: Identify elements which do not support aria-roledescription SVG-AAM: Identify elements which support aria-roledescription without an explicit or implicit role Jul 5, 2017
@joanmarie
Copy link
Contributor Author

Tweaking the summary. I'm working on draft text for the ARIA spec. The current content is:

User agents MUST expose the aria-roledescription attribute if a valid value is applied to a host language interactive control.

If aria-roledescription is applied to a host language container element, user agents must not expose aria-roledescription unless the author also defines an explicit WAI-ARIA role value, or the host language has explicitly identified the element as supporting aria-roledescription.

(emphasis added)

@AmeliaBR
Copy link
Contributor

AmeliaBR commented Aug 1, 2017

Sorry for the delayed response. Needed to do a little reading to make sure I understood the issue.

As I understand it:

  • There is concern that authors will use aria-roledescription instead of role, and thereby lose functionality.
  • To prevent that, the role description will only have an effect on elements that have clearly defined roles, whether those roles are defined in ARIA or only in the mapping between host language and the OS accessibility API.

However, in SVG things work slightly differently: every renderable element has an implicit role, but that role is only "activated" by the author providing alternative text or ARIA attributes.

An aria-roledescription would be very useful for many graphical contexts, to give a meaningful name to things that would otherwise just be called "group" or "symbol".

I personally think that the role description would be useful even in the absence of alternative text. For example, in a comic strip, you might have groups for each panel image. This is a custom shared role within the document, so a perfect use case for aria-roledescription. But beyond that role description, those elements don't need alternative text, and they already have an implicit role (group for <g>), so I think the aria-roledescription should be sufficient on its own.

So, in my opinion, the following two changes to the SVG-AAM are necessary:

Does this make sense for you, @joanmarie ?

@stes-acc
Copy link

stes-acc commented Aug 1, 2017 via email

@AmeliaBR
Copy link
Contributor

AmeliaBR commented Jan 30, 2018

Bumping this. To those of you who are familiar with the issues around aria-roledescription, are the suggested changes in my earlier comment sufficient?

If so, we can close this & I'll make an issue on the new SVG AAM repo to make the edits.

@accdc
Copy link

accdc commented Jan 31, 2018 via email

@AmeliaBR
Copy link
Contributor

@accdc

That seems to be a separate issue from the concern Joanie raised, and should be dealt with in the core ARIA spec. For reference, the current definition of aria-roledescription in that spec says:

Authors SHOULD limit use of aria-roledescription to clarifying the purpose of non-interactive container roles like group or region, or to providing a more specific description of a widget.

But to answer your question: You can add interactive roles to SVG elements, but the only element with a native interactive role is the link.

@accdc
Copy link

accdc commented Jan 31, 2018 via email

@AmeliaBR
Copy link
Contributor

AmeliaBR commented Feb 5, 2018

I'm closing this issue, with the required edits tracked in the correct repo as w3c/svg-aam#5

If there are still other issues with aria-roledescription after the discussion in last week's ARIA teleconference, please open a separate issue.

@AmeliaBR AmeliaBR closed this as completed Feb 5, 2018
AmeliaBR added a commit to w3c/svg-aam that referenced this issue Mar 9, 2018
Closes #5 in the SVG-AAM, following up on w3c/aria#599

Two edits are included:

- A non-empty, non-whitespace `aria-roledescription` value is a factor triggering the inclusion of a rendered element in the accessibility tree.

- In the section on "Conflicts between native markup semantics and WAI-ARIA", a definition is given for SVG elements with implicit role semantics, for the purpose of the [`aria-roledescription` definition](https://w3c.github.io/aria/#aria-roledescription).
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

4 participants