-
Notifications
You must be signed in to change notification settings - Fork 125
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
Comments
Tweaking the summary. I'm working on draft text for the ARIA spec. The current content is:
(emphasis added) |
Sorry for the delayed response. Needed to do a little reading to make sure I understood the issue. As I understand it:
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 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 So, in my opinion, the following two changes to the SVG-AAM are necessary:
Does this make sense for you, @joanmarie ? |
>> 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".
As a workaround, we currently use aria-label for that. We struggle with the fact that for labelled data points (things SVG is typically used for) there is no “role” naming convention out there, in turn generally roledescriptions will be ambiguous. Nevertheless describing the role would be better since it allows for additional independent labelling of nodes.
- Stefan
|
Bumping this. To those of you who are familiar with the issues around If so, we can close this & I'll make an issue on the new SVG AAM repo to make the edits. |
Your text makes sense to me.
My primary concern is not with static SVG content, but rather the use of this attribute in ways that obscure the underlying roles of interactive widgets, in which cases would lead to critical accessibility issues, especially for those with cognitive impairments. So are there any interactive roles within SVGs?
|
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
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. |
Thanks, that makes sense to me.
It may have been changed, but I recall one of the first examples given for the use of aria-roledescription was to put aria-roledescription=”Pizza” on a Listbox. This may have colored my perspective a bit. :)
From: Amelia Bellamy-Royds [mailto:notifications@github.com]
Sent: Tuesday, January 30, 2018 4:44 PM
To: w3c/aria <aria@noreply.github.com>
Cc: Bryan Garaventa <bryan.garaventa@whatsock.com>; Mention <mention@noreply.github.com>
Subject: Re: [w3c/aria] SVG-AAM: Identify elements which support aria-roledescription without an explicit or implicit role (#599)
@accdc <https://github.com/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 <http://w3c.github.io/aria/#aria-roledescription> 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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#599 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/ABx1aN-qCBGh_2oAVpE2_uNDExW47zUKks5tP7ddgaJpZM4OOkWT> . <https://github.com/notifications/beacon/ABx1aJUwe8lt9eJYm-Vr4ij9JQW56pg5ks5tP7ddgaJpZM4OOkWT.gif>
|
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 |
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).
Closes #5 in the SVG-AAM, following up on #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).
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
andspan
) when there is no explicit or implicit ARIA role. Alternatively, or in addition, this AAM could explicitly allow the exposure of the value ofaria-roledescription
on certain elements (an example from HTML would bemeter
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 ofaria-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 foraria-roledescription
.The text was updated successfully, but these errors were encountered: