Open
Bug 864627
Opened 12 years ago
Updated 2 years ago
aria-selected can't be applied to menuitem roles
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
NEW
People
(Reporter: surkov, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: access)
ARIA spec says that aria-selected is applied to role menuitemradio (http://www.w3.org/TR/wai-aria/roles#menuitemradio). It doesn't say this about menuitem and menuitemcheckbox which is I believe ARIA spec error. I suggest to enable aria-selected for all types of ARIA menuitem.
Reporter | ||
Comment 1•12 years ago
|
||
David, do you agree that we should break the spec here?
Flags: needinfo?(dbolter)
Comment 2•12 years ago
|
||
I think so. BTW I once argued that all aria state/properties should be global but didn't win (yet).
Is there pushback from active ARIA people?
I see it inherits aria-selected from the radio superclass (which inherits it from the option super-superclass).
In gecko we've allowed menu items to have the selected state for 100 years. I wonder if there is a nuance the ARIA editors are trying to uncover. Perhaps between the idea of "selected for some later activity" vs "selected as indicating/activating some persistent state even when dismissed". I dunno.
Flags: needinfo?(dbolter)
Comment 3•12 years ago
|
||
(In reply to David Bolter [:davidb] from comment #2)
> I wonder if there is a nuance the ARIA editors are trying to uncover.
> Perhaps between the idea of "selected for some later activity" vs "selected
> as indicating/activating some persistent state even when dismissed". I dunno.
Although checked works for that.
Reporter | ||
Comment 4•12 years ago
|
||
(In reply to David Bolter [:davidb] from comment #2)
> I think so. BTW I once argued that all aria state/properties should be
> global but didn't win (yet).
Less work for a browser vendor, more confusion for AT. I'm not sure who is best for error correction.
> Is there pushback from active ARIA people?
No, just suggesting to be consistent and do what we do for UI
Comment 5•12 years ago
|
||
(In reply to alexander :surkov from comment #4)
> (In reply to David Bolter [:davidb] from comment #2)
> > I think so. BTW I once argued that all aria state/properties should be
> > global but didn't win (yet).
>
> Less work for a browser vendor, more confusion for AT. I'm not sure who is
> best for error correction.
My thinking is more about patterns (like in UIA) than about restricting states to certain roles. HTML + js allows quite a UI playground.
Reporter | ||
Comment 6•12 years ago
|
||
Note, we don't fire selection change events on desktop menus, IE doesn't expose selectable/selected states on menus (except top level menu which has selectable state). It seems like focusable/focused states + focus events is enough for menus.
Probably ARIA doesn't need to allow aria-selected on menuitems.
Reporter | ||
Comment 7•11 years ago
|
||
if the issue https://www.w3.org/WAI/PF/Group/track/issues/504 is resolved then we can close this
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•