RE: Considering order: labels for checkboxes and radio buttons

Taliesin,

I do hope you are making sure that the grouping label or leading question for your check boxes is being announced when focus lands on the checkboxes or radio buttons in each group.

If not, users will not know what they are answering. 

If you have a question What is your favorite ice-cream? With radio buttons for Chocolate and one for Vanilla and all they hear is Chocolate and Vanilla as they tab through the page, they will not know what the question is and what one is the one they should select.

Alan Smith

From: Taliesin Smith
Sent: Friday, July 5, 2019 5:03 AM
To: Karen Lewellen; Sean Murphy (seanmmur); mark.rogers@powermapper.com; bim.egan1@gmail.com; steve.green@testpartners.co.uk
Cc: w3c WAI List
Subject: Re: Considering order: labels for checkboxes and radio buttons

Thanks Karen, Sean, Mark, Bim and Steve for your comments.

I should have been more clear. We make interactive science simulations. In our situation, we have 2 parallel experiences, a visual one and a non-visual one. The visual one does indeed always place the checkboxes and radio buttons to the left of the associated input element's label (i.e., the accessible name).

In our parallel, accessible and non-visual experience we use native HTML, sometimes enhanced with ARIA. Screen reader users access this parallel non-visual layer, and on the screen, at the same time, the visual experience is always present and updating. 

Within our architecture, it is not possible to wrap form control elements inside label elements, therefore the label element has to come before or after the input element. If reading with the cursor keys, the accessible name is always read out twice, which I find is not optimal, but I do not use a screen reader out of need.

Based on the feedback (and for consistency) I think, the general case should be that the label element comes after the input element. For some reason in my last project I had them reversed, and I was unsure as to why I had done it that way. In interviews with screen reader users, I have NOT noticed any trouble with either order.

Sean, thanks for letting me know about the setting in JAWS that can change the reading order.
Steve, thanks for the tip about the "aria-flowto” attribute. I am unfamiliar with that attribute, and will look into it.

The reading order in VoiceOver for those who would like to know is: accessible name, state, then functional role. I do not not know if there is a VoiceOver setting that allows you to change the order, like in JAWS.

If the input element has a value (e.g., input type=range), the value is read our before the accessible name, and the functional (i.e., slider).

Again, thanks everyone for your comments, and if any one is interested in the parallel experience I mentioned, please see the accessibility research section of our website. The accessible science simulations we are working on can be found here: https://phet.colorado.edu/en/accessibility/prototypes

Sincerely,
Taliesin
~.~.~
Also available off-list at:
Taliesin.Smith@colorado.edu
Inclusive Design Researcher
PhET Interactive Simulations
https://phet.colorado.edu/en/accessibility
Physics Department
University of Colorado, Boulder











On Jul 5, 2019, at 3:05 AM, Karen Lewellen <klewellen@shellworld.net> wrote:

Well, another screen reader user, but not using any  of the products referenced below..there are lots more after all.
At its most basic, a screen reader is a talking monitor.  therefore if you arrange items, labels and checkboxes alike in the most understandable order if read aloud, you serve everyone I feel speaking personally.
Of course you want things ordered together,  not labels interspersed with checkboxes, all of the latter managed as well with an entre key as with other types of interactions.
Best,
Kare


On Fri, 5 Jul 2019, Sean Murphy (seanmmur) wrote:


My response is from a screen reader user point of view. Not a standards view. As standards are good, but user experience and expectation is more important. Consistency is key here by the way.

Jaws and NVDA announces the label first then the state. In Jaws you can change the behaviour from memory. This is a screen reader functionality. Do not recall if NVDA can do the same functionality.


I do not recall what the Mac Voiceover says as I do not use this on a daily bases.


Sean Murphy
SR ENGINEER.SOFTWARE ENGINEERING
seanmmur@cisco.com
Tel: +61 2 8446 7751

Cisco Systems, Inc.
The Forum 201 Pacific Highway
ST LEONARDS
2065
Australia
cisco.com

Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html
-----Original Message-----
From: Taliesin Smith <talilief@gmail.com>
Sent: Thursday, 4 July 2019 9:00 PM
To: w3c WAI List <w3c-wai-ig@w3.org>
Subject: Considering order: labels for checkboxes and radio buttons

Hi Folks,
For blind access and accessibility does it matter if the HTML label element comes before or after its associated input element?

This seems like a really basic question, and I am not sure why I don’t actually have a solid answer for myself. Obvious for some control elements the label should, indeed come first, but for checkboxes, does it matter? Is there a preferred order?

Code sample:
<label for=“my-checkbox”>My Accessible Checkbox</label> <input type=“checkbox” id=“my-checkbox” >

<input type=“checkbox” id=“my-checkbox” > <label for=“my-checkbox”>My Accessible Checkbox</label>

Taliesin