Sometimes our weekly test sessions unearth issues outside of the scope of the patches and functionality that we’re testing. These issues are usually quick to resolve, but sometimes they require more deliberation to find an elegant solution.

One of those issues is dealing with compound settings. The way they are currently structured makes these settings a bit confusing to screen reader users. There are two reasons for this:

• Shifting from a checkbox to an input field for a sub setting announces partial labels. For example, “Automatically close comments on articles older than [14] days” becomes “Automatically close comments on articles older than” for the checkbox and “days” for the input field.
• Shifting from a radio button group to the “Custom” input field doesn’t properly announce what the field is for. For example, for the “Date Format” setting it will simply announce “Custom” and whatever the value for the input field is (ie. “F j, Y”).

For a more detailed description on these issues, see also tickets #31354 and #31356.

As part of last week’s testing session we had asked some of our expert testers for their opinions on how to properly solve this. This is a summary of their findings.

Checkboxes and input fields (#31354)

Michelle DeYoung

For the more complex labeling, here’s a bin with some example code: http://jsbin.com/rimoqu/

It contains the htmlHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. and css for a complex labeling and text scenario that uses radio buttons as well.

I know normally you don’t want to create a bunch of extra listening for the user, but in cases like these, I think the extra can help define/explain what is needed; hopefully clearer. Ideally, this would be something that would be great to have user testing applied to.

Gabriela Nino de Rivera

For this problem, I think the best strategy is to do like the romans: “divide and conquer”.

Showing all the information in one line could be visually nice, but as you mentioned, it’s not screen reader friendly.

What I would suggest is to break the action in different steps. Something like this: http://jsbin.com/pogefemiha

Malgorzata Mlynarczyk

I think the main problem here is that those problematic options were designed with sighted people in mind, and so it’s as much an UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. as an accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) issue. I’m not a UX person, but here are my thoughts on the subject:

It will be difficult to code these complex options in a way which is not confusing to screen reader users (label for an input field, containing another fields and their labels).

I guess it could be achieved using a combination of label text, some visually hidden text and text hidden from screen reader users (see example below), but it’s a bit complicated and may not work for all the checkboxes (perhaps the wording of some of them would need to be changed).

For the ‘break comments into pages’ checkbox you could use the following code: http://jsbin.com/vafapi/

Another solution would be to simplify the form and split all those complex options into several options (each containing just one form field and label), for example: http://jsbin.com/rimuwo/

Radio buttons and input fields (#31356)

General

Our testers, rightly, pointed out that the legend is properly announced for them – adding context to the Date and Time Format radio buttons. Some investigation reveals that NVDA won’t announce text wrapped by span tags inside of legend tags when using Chrome. The suggestion is to remove these span tags as well.

Gabriela Nino de Rivera

I prepared an example form that include a suggestion for this problem. When I did the tests with VoiceOver and NVDA, I found it easier to navigate and to understand what needs to be fill in to complete the form.

The example can be found at: http://jsbin.com/fuxagu

Things that have been changed:

• I moved the description texts before their input (for example tagline description), so we can listen to the information before we need to fill text.
• I added significant information to the legends attribute, so the user is informed of the actions required inside the fieldset.
• I associated the labels to their ratio buttons and removed the title attribute from them.

About the last change: Here we have a big issue because the title is notifying an important information to the user. But the problem is that not all the screen readers will read the label title. So, when doing the test on NVDA, this information was not notified to me. I don’t have a solution for this, the only thing I can think is to add it inside the span like this:

<span>4:26 PM (g:i A)</span>

But this is only solving the problem in half, because even if the screen reader announce it to the user, I won’t hear the two points (:) and won’t know that the A is capital letter.

Malgorzata Mlynarczyk

• I would change implicit labels to explicit ones (using ‘for’ attribute pointing at the relevant form field)
• I absolutely agree with you that the input field for custom date or time should be disabled and not focusable until the relevant ‘custom’ radio button is selected
• each of those ‘custom’ text input fields needs to have a label, which can be visually hidden
• I would perhaps also add ‘aria-live=”polite”‘ attribute to the showing an example (based on the selected format), so that it would be read out when it’s updated. I’d test it though first with different screen readers to make sure it works as expected.

So my mark-up for the time format fields, for example, would be something like this: http://jsbin.com/jaqehanalo/.

In conclusion

A lot of great feedback here. For solving complex form structure issues there seem to be two viable options:

• Use hidden labels to make sure these fields have additional clarification for screen reader users.

  This option doesn’t compromise the way these settings look right now at all, while still solving the issue with fractured and incomplete labels.

• Split them up into their own stand-alone fields.

  This will definitely clarify things for screen reader users, but could potentially clarify it for sighted users as well. However, it will require rewriting of labels and will also have a visual impact on the settings screen.

#accessibility-usertest