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.

[jwgoedert]

Image of decoupled discussion options fields, need feedback (indents? hidden/disabled state from parent?)

[jwgoedert]

Working on this locally. I decoupled the options so there would be explicit check boxes followed by additional related inputs.

I am still uncertain the best way to convey the relation of the 'parent' check box element to the affected sub-selections and whether they should be visible but disabled or hidden.

example:'Automatically close comments for old posts' affects whether 'Number of days to keep old comments' is used, but doesn't necessarily have to affect if it is set.

May pursue the way this is handled on 'Reading Settings' with static page selection using a UL for options and disabling selectors.

This patch addresses the difficulty with using input fields inline with text for screen readers.

For example: 'Breaking comments into pages' with inputs on a single line-

Becomes: 'Breaking comments into pages' with a parent checkbox that controls styles(visibility in this case-with a disabled version to come) and displays the options one after the other for better screen reader and tab accessibility.

An 'aria-live' div has been added to announce the state of the checkbox and display or removal of dependent elements.

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

[jwgoedert]

31354 show/hide children patch

[jwgoedert]

Quick video demo with voiceover audio to convey aria-live state changes

Trac ticket:

[jwgoedert]

Disable dependent input fields on parent toggle patch-need feedback on accessibility and structure

[joedolson]

Adding to 6.6 milestone; this is looking promising. In accessibility bug scrub, we discussed this and prefer the disabled model of the hidden model, as it then uses the same pattern as on the Reading settings.

[oglekler]

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

[joedolson]

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

[joedolson]

Updated patch

[joedolson]

This updated patch removes the ARIA live announcement and the aria-expanded attributes. The aria-expanded attribute is not required since the checkboxes do not open and close anything, and their current state is conveyed using the natural semantics of the checkbox input.

The aria-live announcement isn't needed, in my opinion; it would just make things more verbose. If the change was made to something that preceded the current position in the DOM, it might be necessary, but since the change is to items that follow in the DOM, I think it's fine as is.

Also changed the CSS & HTML so to reuse the styles from the Reading options screen, updated the function comments to better describe what the added JS now does, and removed the styles that impacted the label design. It's generally considered acceptable for a disabled input to be below color contrast guidelines, but the label still needs to be visible.

Edit: and I also added the disabled attribute in PHP, so it would apply without JS.

[joedolson]

While I think this is a highly worthwhile change, I also think it has not had sufficient feedback to go into core this late as an enhancement.

It may be reasonable to re-characterize this as a bug - the existing labeling is a poor experience, but is borderline as a bug. WCAG 3.3.2 requires that fields have labels or instructions that describe the input; and whether that's true or not on these is open to discussion.

I'll raise this issue in a bug scrub to determine whether it's viable to change to a bug for 6.6, but in the meanwhile I'm moving to 6.7.

[jwgoedert]

I would have to agree from a screenreader perspective that this falls more under bug territory as the content and quantities to not line up in a discernible way.

[joedolson]

Per discussion in the accessibility bug scrub, transitioning this to a bug.

[jwgoedert]

Adjusted previous patch to remove js and php toggle disable setting to focus on structural changes only(bug related)

Nested child elements in list items to create visual hierarchy, moved input fields to end of labels for screen reader usability
Trac ticket:
https://core.trac.wordpress.org/attachment/ticket/31354/

[jwgoedert]

Patch for structural changes only, no toggles

[sabernhardt]

The new patch does not have testing yet, and it contains new text strings. I'll move the ticket to 6.7 (but it still could move back in the next week if a committer is confident).