WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: [EXT] Label in name

for

From: Sailesh Panchang
Date: Jul 6, 2021 3:40PM


Hello Patrick,
1. The reference to users of "speech input software" in the stated
intent for SC 2.1.1 of WCAG 2.0.
In Understanding SC 2.1.1, it unequivocally states, "Keyboard
emulators include speech input software, sip-and-puff software,
on-screen keyboards, scanning software and a variety of assistive
technologies and alternate keyboards...."

So perhaps you are mistaken in assuming I am "apparently describing
some intent on the part of authors of WCAG 2.0"? Because, in fact, I
am referring to their stated intent. So the needs of speech input
users was not unknown to or overlooked by authors of WCAG 2.0 and
hence it is difficult to comprehend why an SC explicitly *conceived*
and written with voice input AT users in mind" is needed.
2. In the context of a situation where multiple potential sources for
the accessible name are present, perhaps you are again mistaken in
claiming, my " assertion of 'ranks lower' makes it sound like a value
judgement, when really it's not".
I am not making any value judgment, I am merely referring to the order
of preference for determining the accessible name documented in
W3C recommendation for Accessible Name and Description Computation 1.1
where WAI-ARIA attributes like aria-labelledby trump native HTML
naming elements like LABEL suggested in H44.

3. In order to test an SC one needs to test if a sufficient technique
(or other method) is implemented in a manner that the SC is met. Again
it is not me, but the documented techniques for multiple success
criteria including SC 1.1.1, 1.3.1 etc. that group different
techniques by the situation they apply too. Indeed an accessibility
consultant must employ his / her professional expertise and highlight
the one that is most suited when there may be more than one that does
the job of meeting the SC. That should be driven by considerations
like:
- identifying the situation / context in which the accessibility
problem occurs, having regard to the design employed;
- which technique will benefit the widest PWD user groups.
The accessibility SME should also highlight the risk inherent in
employing a technique like aria-label (whose value needs to be changed
in case of a visual UI modification) when the visual text could have
been associated instead.

Again the term "programmatically determinable" is used in SCs and is
normatively defined so that's where the accessibility SME is able to
suggest which technique is most appropriate in the situation.
Beyond that, it is up to the developers.

Thanks and best regards,
Sailesh



On 6/25/21, Patrick H. Lauke < <EMAIL REMOVED> > wrote:
> On 25/06/2021 21:51, Sailesh Panchang wrote:
>> Patrick comments: It's not that it does not apply. I'd rather say that
>> following H44 is also a good way to satisfy the SC.
>> Sailesh: That SC does not need to be tested when H44 is correctly
>> implemented. It increases the cost of testing / checking another box
>> needlessly.
>
> You test the SC. You don't test "have they used this or that particular
> technique".
>
>> Patrick comments: You'd still want to test to check that the
>> accessible name wasn't overridden on the control, negating the benefit
>> of H44...something like...
>> Sailesh:So one needs an SC to test that an accessibility technique
>> that has passed the tests for its correct implementation has not been
>> mauled by some other markup?
>
> *If* developers use techniques exactly as they are, without any other
> additions/modifications, yeah it should pass the SC. But
> life/development are more complex than the often quite stripped down and
> artificial techniques.
>
>> Patrick comments: Not really. It's more a side effect.
>> Sailesh: About the same side effect as an aria-label that is identical
>> to the visible text helps voice input users in addition to screen
>> reader user.
>
> With your original "Therefore, even WCAG 2.0 considered the needs of
> voice input AT users" you were apparently ascribing some intent on the
> part of the authors of 2.0. That was not the case. This is clearly
> different from 2.5.3 Label in Name which was explicitly *conceived* and
> written with voice input AT users in mind.
>
>> Patrick comments: The "ranks lower" part only comes into play if there
>> are multiple potential sources for the accessible name in play, as in
>> the above example.
>> Sailesh: The example is a very poor one. What purpose will one have in
>> using aria-label other than the intent to break correctly implemented
>> H44? If "Bar" is the label that makes sense for that control, then the
>> "Foo" label already fails SC 2.4.6 and several user groups.
>
> I'm merely pointing out that your assertion of "ranks lower" makes it
> sound like a value judgement, when really it's not any less valid if all
> other factors are equal.
>
>> Patrick comments: Is there a point in having a "preferred" technique?
>> What matters is the end result, regardless of how the author achieved
>> it. There may well be valid situations where an author couldn't use
>> H44 directly, but still achieved the same result in another way. Which
>> is fine and passes.
>> Sailesh: I referred to situations when one cannot use H44 to make
>> content programmatically determinable or "extract and present
>> information to users in different modalities" . And I suggested those
>> techniques need to include guidance now contained in G208 / G211 which
>> is identical pretty much to SC 2.5.3. Accessibility consultants should
>> nudge developers to use the right technique for a particular
>> situation so that it helps the widest PWD user groups. Sometimes a
>> fallback technique may also need to be implemented to enhance
>> inclusivity without breaking other accessibility techniques.
>
> If alternative techniques still manage to achieve the ask of the SC,
> they're no worse nor better than H44. Suggesting that one technique is
> "more correct" than another negates the idea that it's the outcomes /
> satisfying the success criterion that matters, and goes into subjective
> territory of ranking different types of techniques which, in the end,
> lead to the same end result.
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >