Re: Some discussion points for Label in Name

So it looks like a strict interpretation of what the label is in the 
context of this SC works for speech rec users -- the original target group 
of the SC. That's heartening. I also agree that where it is just "yes" or 
"no" labels for a bunch of inputs, the practice of most speech recog. ATs 
to number the possible choices is a feature which makes this 
interpretation palatable.

However, I'm concerned with your statement "Put the focus on the question 
when you say the question." Putting the focus on the question won't be 
achieved with a narrow reading of the meaning of 'label', or at least not 
alone.
This, I think underscores an important consideration with how ATs 'make 
up' their own rules for implementation.
Screen readers, for instance, do not just read out the accessible name on 
inputs. All the ones I've tested provide the text associated through group 
roles and fieldset/legend. If there is additional info offered through 
TITLE, most will throw that in by default. To my knowledge, there is no 
spec for these enhancements (they certainly aren't in Acc Name). It's just 
how they've decided to incorporate useful info for their user base.
Similarly, I don't think we can assume that Dragon and other speech rec. 
ATs will only use the accessible name for navigation. They may decide to 
also use the group name's programmatic link with a control to offer a 
means of navigation. But that isnt part of the Acc Name standard, which 
this SC covers.

If we began telling everyone to incorporate the question text into the acc 
name, we would make the screenreader experience untenable. Imagine having 
those long questions read at the start of every one of the choices for a 
checkbox set, etc. You wouldn't even hear the important bit until the end 
of a potentially very long string.

Even with a restricted take on interpreting 'label', in the example of the 
Work Phone a perfectly useful implementation for screen readers (assign 
Work Phone as a group label, and give each input an aria-label) is going 
to be made less palatable because Work Phone will now not only be the 
group label but must also be in the accessible name for the first input. 
It can be accommodated without too much additional chatter if it's done 
properly, but there is real danger (especially with liberal 
interpretations of what constitutes a label) that changes to align with 
this SC will significantly degrade the screen reader experience. I can 
provide more examples if it isn't obvious.

Michael Gower
Senior Consultant
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
cellular: (250) 661-0098 *  fax: (250) 220-8034



From:   Kim Patch <kim@redstartsystems.com>
To:     Michael Gower <michael.gower@ca.ibm.com>, WCAG <w3c-wai-gl@w3.org>
Date:   2019-01-22 07:37 AM
Subject:        Re: Some discussion points for Label in Name



Thoughts on these 2.5.3 examples from the speech user perspective:

"Work phone" for the first component. Getting around the separate elements 
would use arrows/tabs and/or its automatic as you fill it out

"Call me…" for the explanation. 
Yes
No

"What do…" for the explanation
Courtesy
Promptness
Store Hours
Knowledge

Put the focus on the question when you say the question, then tab/arrow to 
fill in a radio button or get to the text field. 
Also enable yes/no as usual (when a speech user says yes and there are 10 
yeses on the page they are numbered).

Enable the labels and enable arrows in the radio button array. A speech 
user would say, for instance "The Interaction…", "2  Right" and then 
either say the next label  and "2 Right", or just use arrow commands from 
that location to fill in the rest. 

Question for you – do any of these conflict with the needs of screen 
reader users and if so how?

Hope this helps. 

Cheers,
Kim


On 1/21/2019 5:51 PM, Michael Gower wrote:
"Success Criterion 2.5.3 Label in Name (Level A): For user interface 
components with labels that include text or images of text, the name
 contains the text that is presented visually."
Time permitting, here are some topics I'd like to delve into on our next 
call in relation to 2.5.3 Label in Name.

Problem 1: When we ignore the programmatic stuff, getting agreement on 
what exactly constitutes a 'label' for a component isn't always simple.

Problem 2: The Accessible Name Rec has a specific method for determining 
name. It affects implementation, especially when you try to satisfy 
various interpretations of what IS a label. (Key considerations: group 
role not in calculation, aria-label/labelledby have priority in 
calculation, aria-describedy not calculated)

Problem 3: It is harder than anticipated to balance the needs of screen 
reader users with the needs of speech recognition.

Five examples. What is the label for each UI Component (or does it have 
one)?













Michael Gower
Senior Consultant
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
cellular: (250) 661-0098 *  fax: (250) 220-8034

-- 
___________________________________________________ 

Kimberly Patch
(617) 325-3966
kim@scriven.com

www.redstartsystems.com
- making speech fly

PatchonTech.com
@PatchonTech 
www.linkedin.com/in/kimpatch
___________________________________________________