Compound settings confusing with screen readers (checkboxes)

[Cheffheid]

There are a number of settings in the admin that are made out of multiple variables. That is, they combine a checkbox/radio button toggle and a value.

When you can see it, it makes sense because it forms a logical sentence and everything works out great.

When you rely on a screen reader, it doesn't really come across as such and there's no link between the different inputs in the setting.

For example:

As you tab through the different fields, NVDA (with default settings) will announce:

• Break comments into page with - checkbox (not) checked.
• top level comments per page and the - edit fifty.
• page displayed by default - combo box last collapsed.

We need to come up with a pattern that can be applied to split up these toggle/value inputs and clear up confusion this may create.

It would be nice if the inputs for the actual values stay disabled until the appropriate toggle is enabled as well (similar to how the home/blog static page selectors work).

This issue concerns the following fields:

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

• Automatically close comments on articles older than X days
• Enable threaded (nested) comments X levels deep
• Break comments into pages with X top level comments per page and the X page displayed by default.
• Comments should be displayed with the X comments at the top of each page

On /wp-admin/network/settings.php

• Limit total size of files uploaded to X MB

Could use input from accessibility and UI teams on how to best tackle this. :)

[anthakkar08]

Patch for the issue

[anthakkar08]

Created a patch for this this requires to be tested with both Normal and Multisite installation so please check this out and do share the feedback

[anthakkar08]

patch based on ​https://core.svn.wordpress.org/trunk/ @ 31465

[anthakkar08]

Previous Patch was creating Some conflict so have updated the Patch with the Latest Trunk copy of ​https://core.svn.wordpress.org/trunk/ @ 31465

[Cheffheid]

@anthakkar08 Thank you sir! Could you create the patch from the root folder though (Where the src folder and wp-config.php file resides as well)? I'm having some issues applying it on my install.

[DrewAPicture]

regenerated from root

[DrewAPicture]

Replying to Cheffheid:

@anthakkar08 Thank you sir! Could you create the patch from the root folder though (Where the src folder and wp-config.php file resides as well)? I'm having some issues applying it on my install.

31354.3.patch​ is .2 regenerated from the project root.

If you can't get a patch to apply via the grunt patch command, you can always attempt to do it manually by downloading the patch to the sub-directory in question, in this case /wp-admin, and applying it there with the patch command e.g.

$ patch -p0 < 31354.2.patch

[Cheffheid]

Thank you sir! I'm one of those noobs that uses TortoiseSVN instead of grunt to apply patches, because Windows, and it kept suggesting me the parent folder of where-ever I was trying to apply it. And then failed to apply it, even on /wp-admin.

In any case, the patch is a good start and the subfields seem to enable/disable appropriately based on the checkbox state.

Would still like a good solution for the labels though. @afercia had already suggested splitting them up so the labels can make sense by themselves. Something like this (rough example):

I'll solicit for some more feedback from the a11y peoples too. :)

[afercia]

I'm not sure playing with JavaScript can really help here, I'd say it would be a possible enhancement to evaluate after the main issue is solved. IMHO the first thing to do here should be using proper labels that make sense also when read out of context and probably restructure a bit the form. Just use Plain Old Semantic HTML (POSH), nothing fancy, consider HTML give us fieldset and legend elements for free and use them when appropriate.

About the first example:

• the checkbox is meant to enable/disable the setting, it's a general "switch" and this should be clear even when the label is read out of context
• the other two, are sort of "sub settings", it should be clear they're discarded if the main checkbox is not checked

What I would suggest:

fieldset
legend:                 Comments pagination
checkbox + label:       Break comments into pages
label + input field:    Top level comments per page
label + select:         Comments page to display by default: last page|first page
(added) label + select: Comments to display at the top of each page: older comments|newer comments

Consider this other example:

Here, the labels are:

"Automatically close comments on articles older than"
"days"

The first one doesn't tell me it's an on/off switch, but says something about "older than". Confusing. The second one says just "days", I don't have a clue what it refers to, when read out of context. This second example is a bit more difficult to handle, still thinking about a proper solution :)

I understand this would require some minor UI changes, so it needs UI feedback and I'm pretty confident we could find a good balance between functionality and visual. Any thougths more than welcome.