-
Notifications
You must be signed in to change notification settings - Fork 120
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
roledescription usage should not be limited to elements with defined ARIA roles #500
Comments
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. |
Here's another non-Web Components example. 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:
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 |
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. |
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. |
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. Similarly, there is a big difference between: |
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. |
@mcking65 wrote:
It seems like you missed my examples above, including this comment:
|
On 15 December 2016 at 08:46, James Craig ***@***.***> wrote:
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.
Such conformance requirements would be expressed in ARIA in HTML
<http://w3c.github.io/html-aria/>
Feel free to file an issue https://github.com/w3c/html-aria/issues
…--
Regards
SteveF
Current Standards Work @w3c
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>
|
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 |
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 |
…s for "form" element (#500) Co-authored-by: Scott O'Hara <scottaohara@users.noreply.github.com>
Co-authored-by: Scott O'Hara <scottaohara@users.noreply.github.com>
Originally raised 20 Oct 2016 in ARIA Tracker 1048
The following requirement is overly restrictive:
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.
The text was updated successfully, but these errors were encountered: