WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: [EXT] Label in name

for

From: Patrick H. Lauke
Date: Jun 25, 2021 6:17PM

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