Compound settings confusing with screen readers (radio buttons)

[Cheffheid]

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.

[Cheffheid]

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.

[afercia]

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.

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".

[rcreators]

Just new to the contribution. I have worked on the permalink page and this is something i comeup with.

Default Custom Input field and below buttons will be disabled. So when user click on tab, it will directly go to next section rather then custom permalink input.

Once user change their selection in permalink structure and go to custom structor, than javasript will remove the disabled from the input type and from secondry buttons as well. So now user can tab to them change the custom strcture as usual.

I am not aware yet on creating patch/diff file yet but will create wordpress mirror with ticket no for pull request once someone review this video.

​https://screenpal.com/watch/cZnilqVdrTp

[rcreators]

options-permalink.php file patch as described..

Updated Option-permalink.php file code. So now by default custom permalink input and below tags will be disabled. So when users with a keyboard use the tab key, it will take them directly to the next section rather than custom input. Also if the user selects the custom permalink option, it will enable the input field. So with the tab, they can use the input field as well as the below button tags.

​https://screenpal.com/watch/cZnilqVdrTp

Trac ticket: https://core.trac.wordpress.org/ticket/31356

[joedolson]

Adding to 6.6 milestone.

[oglekler]

We have 2 days before Beta 1 and no time to test, so I am moving it into the next milestone.

@joedolson feel free to move it back if you can tackle it in time. Thank you!

[joedolson]

Moving back to 6.6. This is on my schedule for today and tomorrow.

[joedolson]

The keyboard traps mentioned for both the general options and the permalinks were resolved in [40897] and [40568]. The missing label on the custom date and time format field was resolved in [31993], and the label in permalinks was resolved in [53706].

So, it seems like all of the actual problems on this ticket have been resolved against other tickets, without ever resolving this open ticket.

While there could be some minor benefit to marking the permalink custom structure field as disabled, all of the practical accessibility issues have already been resolved on this ticket.

What's really missing is that @cheffheid should have gotten props for the various issues that have been solved but the relationships to this ticket were consistently missed.

I'm going to close this issue as fixed against version 6.1 and add props for Jeff in the props channel. Thanks for your work, @rcreators! If you hadn't worked on this, I may not have done the research to identify that it was already fixed, so that's also extremely valuable.