Repository navigation
roledescription usage should not be limited to elements with defined ARIA roles #500
Description
Originally raised 20 Oct 2016 in ARIA Tracker 1048
The following requirement is overly restrictive:
User agents must not expose the aria-roledescription property if … The element to which aria-roledescription is applied does not have a valid WAI-ARIA role or does not have an implicit WAI-ARIA role semantic.
This would mean the feature could not be used on any markup element in any host language until such a time as ARIA defined an equivalent role. As we already know ARIA is well behind the current release of HTML, this is an overly restrictive limitation and should be removed.
Activity
cookiecrook commentedon Dec 14, 2016
For clarity, the "Authors SHOULD" statement in the spec is fine. The "UAs MUST NOT map" is the problem. That's overly restrictive, and sets up ARIA to be a bottleneck for continued progress in host languages like HTML, particularly in Web Components where we fully expect web authors to move faster than spec authors or user agents.
cookiecrook commentedon Dec 14, 2016
Here's another non-Web Components example.
https://www.w3.org/TR/html-aam-1.0/
There are 79 matches in HTML Mapping for "No corresponding role." Should we really disallow use of role description on all of them? For example:
<code>Using an explicit ARIA role on<code>would cause the browser to lose functionality, but it'd be fine to define the role description on a per language basis: e.g. "CSS code sample", "Objective C code sample", etc. Sites like GitHub and Stack Overflow could even do this automatically on their language-formatted code samples. How does it benefit us to take this possibility away from web authors?<meter>Am I really not allowed to describe this meter just because ARIA hasn't gotten around to role parity yet?<fieldset>Probably harmless to change the role description, but extremely harmful to require authors to explicitly use a different role in order to do so.I can imagine some talented web authors in the near future saying, "I can technically make it operable, but I can't make it understandable because ARIA 1.1 required browsers to ignore my role description." Overly prescriptive regulations and limitations like this end up more harmful than helpful.
What if you only included this stipulation on generic elements like
<div>and<span>? I'd be okay with that restriction. The goal seems to be to avoid problem cases like<div aria-roledescription="button">and restricting usage on generics would be one way to do that, without penalizing appropriate use on another type of element.cookiecrook commentedon Dec 14, 2016
#500 blocks #464
richschwer commentedon Dec 14, 2016
James, Unfortunately, many of the group members were VERY uncomfortable with aria-roledescription and wanted to limit its use in ARIA 1.1. I also heard similar concerns from Freedom Scientific - both who were blind. I am working very hard to get both FS and NVDA to join the ARIA WG as invite experts as I would like to see their concerns logged officially for all to see. Matt King and Joanie also both voiced their concerns over aria-roledescription. I am certain that you raised this concern before and this was the determination of the group. What the group really wants to do is see how it works in the wild. All of these restrictions were intentional. At this point the CR version is done.
My recommendation is that you create an ARIA 1.2 issue to ask that the restrictions get relaxed. I would support this. Regarding the lack of ARIA role semantic mappings we are going through all the HTML elements as part of ARIA 1.2, in support of Web Components, and in fact we have already begun the element triage work in parallel with the ARIA 1.1 move to CR. As you know we need many new roles in 1.2 to fill these gaps.
cookiecrook commentedon Dec 14, 2016
Rich wrote:
There was nothing mentioned in the tracker issue, and it was still in the raised (unscreened) state. If there was group discussion of the issue, please link it here or cc the contributors to respond inline.
mcking65 commentedon Dec 14, 2016
I don't know where it is minuted, but the jist of my concern is that there need to be role semantics behind the roledescription so assistive tech knows how to present the element.
My expectation is that AT will do everything it normally does with an element that has a roledescription except provide the standard role name for it.
Example: make a listbox into a pizza pie where each option is a slice.
AT will present it like a listbox but call it a pizza pie instead of using whatever words it normally uses to communicate the listbox role.
At can still give the user instructions that it would normally give for a listbox but use the roledescription string instead of its name for the listbox role.
Similarly, there is a big difference between:
<div role="region" aria-roledescription="slide"><div role="group" aria-roledescription="slide">Assistive tech know what to do with either of the above, but they have know idea what to do with:
<div aria-roledescription="slide">In this last case, where there are no role semantics, I would like to be sure that the roledescription is ignored because asking assistive technologies to accomodate it creates infinite ambiguity with respect to defining meaningful presentation.
mcking65 commentedon Dec 14, 2016
I think it is reasonable to move slowly with roledescription because assistive technology developers fear the damage it can do. I think some of their concern is well-founded given that roledescription is designed to replace a fundamental part of the assistive technology experience; it is a transition of UX control from the assistive technology developer to the author.
cookiecrook commentedon Dec 15, 2016
@mcking65 wrote:
It seems like you missed my examples above, including this comment:
stevefaulkner commentedon Dec 15, 2016
first draft addressing Issue #500
cookiecrook commentedon Jun 20, 2017
Discussion happening in the commit referenced above, but if this one is going to be picked up for 1.1, a conceptually related issue to discuss is #529
jnurthen commentedon Nov 13, 2019
With role parity and most HTML elements having implicit roles now (even div and span) this either needs addressing (in HTML-ARIA I believe) or we agree that such restrictions on aria-roledescription are pointless and remove the restrictions as the thing which was being attempted to resolve would be allowed by this
resolves #500, including the missing prohibited roles statement on ar…
resolves #500, including the missing prohibited roles statement on ar…
Editorial - Removed "or" at the beginning of the list of allowed role…
Remove tables and details/summary in favor of unique headings (#500)