Opened 5 years ago

Last modified 5 years ago

#9628 open bug

Button: radios are not screen reader and keyboard accessible

Reported by: dylanb Owned by:
Priority: minor Milestone: none
Component: ui.button Version: 1.10.3
Keywords: a11y Cc:
Blocked by: Blocking:

Description (last modified by tj.vantoll)

The radio button implementation (see demo) is not screen reader accessible due to a number of issues.

  • 1) Using role=button instead of role=radio
  • 2) The hidden radio button elements are still visible to the screen reader and so you get duplicated announcements
  • 3) The hidden radio button elements are keyboard accessible and so the keyboard focus disappears for keyboard only users
  • 4) The buttons themselves are not keyboard accessible because of missing tabindex

Change History (3)

comment:1 Changed 5 years ago by tj.vantoll

Description: modified (diff)
Keywords: a11y added
Status: newopen
Summary: UI button - radios are not screen reader and keyboard accessibleButton: radios are not screen reader and keyboard accessible

Hi dylanb,

Using role=button instead of role=radio

Seems sensical and easy enough.

The hidden radio button elements are still visible to the screen reader and so you get duplicated announcements

What screen reader are you seeing this in? I cannot recreate this in VoiceOver.

The hidden radio button elements are keyboard accessible and so the keyboard focus disappears for keyboard only users

This seems valid, we should probably try to preserve the default outline.

The buttons themselves are not keyboard accessible because of missing tabindex

I'm confused about this because you can absolutely interact with the radio buttons with the keyboard. Could you give more details here?

comment:2 Changed 5 years ago by tj.vantoll

Never mind about the duplicate information question, I was just able to recreate that with VoiceOver.

comment:3 Changed 5 years ago by dylanb

What I meant with the last point is that even though you have button roles, you cannot interact with these elements, you actually end up interacting with the offscreen radio elements - which makes these roles redundant altogether.

You either have to choose to hide the input elements and allow the user to interact with the label (turned into a radio with role=radio and associated attributes) or you have to just use the labels for presentation and ensure that they appear focussed when the underlying input element has focus.

Note: See TracTickets for help on using tickets.