Open Bug 864627 Opened 9 years ago Updated 8 years ago

aria-selected can't be applied to menuitem roles

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

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.
David, do you agree that we should break the spec here?
Flags: needinfo?(dbolter)
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)
(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.
(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
(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.
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.
if the issue https://www.w3.org/WAI/PF/Group/track/issues/504 is resolved then we can close this
You need to log in before you can comment on or make changes to this bug.