Closed Bug 1022939 Opened 7 years ago Closed 7 years ago

Add accessibility markup to gaia-radio

Categories

(Firefox OS Graveyard :: Gaia, defect)

All
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: eeejay, Unassigned)

References

Details

(Keywords: access)

Attachments

(1 file)

No description provided.
I have been playing with different approaches with this, and gaia-switch. As opposed to solution I proposed in bug 1014887, I think the better way to do this is apply the role to the primary click target element. Once gaia-switch is redone, its a11y markup should follow the same approach.

This works better with our accessibility engine, and is generally flexible enough to do more interesting things, like radio/check menu items.
Attachment #8437270 - Flags: review?(kgrandon)
Comment on attachment 8437270 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/20255

Eitan - nice work. I am still really looking to see if there is some way that we can be more proactive about accessibility with these components, and have a better experience if app authors don't use the right role or even provide a role at all. Few questions: 

1 - Have we done an audit for most radio input roles in gaia? Could we potentially have any smart default the the radio that would work in most cases?

2 - What happens if we supply a role=menuitemradio by default, if the radio is not in a menu?
Attachment #8437270 - Flags: review?(kgrandon)
Flags: needinfo?(eitan)
(In reply to Kevin Grandon :kgrandon from comment #2)
> Comment on attachment 8437270 [details] [review]
> Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/20255
> 
> Eitan - nice work. I am still really looking to see if there is some way
> that we can be more proactive about accessibility with these components,

Check out our new a11y-review flag, and don't be shy to use it.

> and
> have a better experience if app authors don't use the right role or even
> provide a role at all. Few questions: 
> 
> 1 - Have we done an audit for most radio input roles in gaia? 

Last year I introduced a horribly disruptive patch that changed all the pack-[radio/switch/check] building blocks and made them more screen reader friendly. So I guess we could call that an audit :P

> Could we
> potentially have any smart default the the radio that would work in most
> cases?

Yeah, I think this patch introduces that. If you don't provide any role info, it will 90% of the time expose the right stuff for our screen reader.

> 
> 2 - What happens if we supply a role=menuitemradio by default, if the radio
> is not in a menu?

Theoretically, it would break things. Why would you want to do that? The default role should be "radio", and it should be possible to override it, like I show in the example html.
Flags: needinfo?(eitan)
What other steps would you need for me to get this reviewed?
Flags: needinfo?(kgrandon)
Comment on attachment 8437270 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/20255

Looks good to me, thanks!
Attachment #8437270 - Flags: review+
Flags: needinfo?(kgrandon)
Landed: https://github.com/mozilla-b2g/gaia/commit/5b3d1bddec7d12c7fb7ae8e3d4ede59b09183432
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.