WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 3 years ago

#31356 new enhancement

Compound settings confusing with screen readers (radio buttons)

Reported by: Cheffheid Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.1
Component: Administration Keywords: settings-api
Focuses: accessibility Cc:
PR Number:

Description

Similar to #31354, #31144 - but worth noting separately.

As mentioned in #31144, the "main" label for radio buttons is never announced which is removing the context for them.

Additional issues with this arise when the setting has a "Custom" option with an input field. When tabbing from the radio button to the "Custom" input field two things happen:

  • It will automatically set the radio button option to "Custom"
  • It announces the current value of said input field without further context. Ie. 'F j, Y'.

The former is not a huge deal, because it automatically updates the input field for "Custom" to whatever the value of the previously selected radio button was.

The latter is a bit odd and confusing if you have no further context as to why it's being announced or what it's announcing even means.

Having the input field inactive/unfocusable unless "Custom" is selected would probably help with this and remove unnecessary focus on this field when it's ultimately unwanted.

This applies to:

On /wp-admin/options-general.php:

  • Date Format
  • Time Format

On /wp-admin/options-permalink.php:

  • Main permalinks setting

Here, too, additional input from accessibility and UI teams more than welcome.

Change History (8)

This ticket was mentioned in Slack in #accessibility by cheffheid. View the logs.


5 years ago

#2 in reply to: ↑ description @Cheffheid
5 years ago

the "main" label for radio buttons is never announced which is removing the context for them.

Apparently, this has more to do with the fact that using NVDA on Chrome is a bit buggy. As it turns out, the <legend> tag isn't announced like it's supposed to. The reason for this seems to be the <span> tag. Unless there's a specific purpose to those span tags being there, they can be removed.

Last edited 5 years ago by Cheffheid (previous) (diff)

#3 @afercia
4 years ago

Just noticed there's also a sort of "keyboard trap" here. When using only the keyboard, say users want to change the permalink structure from "Month and name" to "Numeric": they will use the arrow keys to check the "Numeric" radio button.

https://cldup.com/_hYVWMazvr.png

Then, to move away from the radio buttons, keyboard users will have to press the Tab key and thus the Custom format field will receive focus because it's the next focusable element in the tab order. At this point, a bit of JavaScript will make the "Custom Structure" radio button checked. There's no way to escape this trap other than tabbing backwards.

This could be fixed with some JavaScript, by the way I'd recommend to use a simpler, more semantic markup in the first place (and some PHP adjustment to handle the POST). As I see it, the first 5 ones are "preset" options and it makes perfectly sense to group them together. "Custom Structure" should be a separate option and maybe use just the text field. Something like "Choose one of the preset URL structures or build your custom one".

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


4 years ago

#5 @rianrietveld
4 years ago

  • Milestone changed from Awaiting Review to Future Release

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 years ago

#7 @afercia
3 years ago

  • Keywords settings-api added

This ticket was mentioned in Slack in #core by afercia. View the logs.


3 years ago

Note: See TracTickets for help on using tickets.