Re: Considering order: labels for checkboxes and radio buttons

Hi Allan, 
We do indeed ensure our checkboxes are fully accessible. 

Our environments (interactive simulations for learning science) are somewhat specialized. The checkboxes do not ask questions, and usually toggle a setting like showing or hiding units relative to the simulation. 

We have found that labels, auto state changes accompanied by aria-live alerts about what changed, and on-demand helptext about the purpose of the checkbox support blind students’ exploration and use very well.

My original question was specifically about whether it matters to screen readers if a properly associated label element is read out directly before or directly after the input if reading with the cursor keys.

In both cases the label text is read out twice if reading with cursor keys - once on the label, and once on the input that is associated with the label.

Taliesin 

Sent from my iPhone

> On Jul 5, 2019, at 17:13, ALAN SMITH <alands289@gmail.com> wrote:
> 
> 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
> 
> 
>  
>