E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: Sailesh Panchang
Date: Wed, Jun 23 2021 3:21PM
Subject: [EXT] Label in name
No previous message | Next message →

Some thoughts for consideration:
The Understanding doc states the SC does not apply when there is no visible label.
In a sense it does not apply also when one has used technique H44 (for-id) method to associate the visible label with the control thereby meeting SC 1.3.1. No further testing of SC 2.5.3 is required in this case.
Therefore, even WCAG 2.0 considered the needs of voice input AT users; only the benefit that accrues by using H44 remains undocumented. Though the native HTML LABEL element (and thus H44) rank lower in the accessible name computation, it has benefits for multiple user groups and should be the preferred technique.
Other techniques to assign an accessible name to a UI control that must be used in other situations (when name and visible text cannot be identical) should include guidance now that are part of G208 / G211.
After all that is the way to permit "different user agents, including assistive technologies, can extract and present this information to users in different modalities" i.e. make the name programmatically determinable.
I believe just the new failure technique "F96: Failure due to the accessible name not containing the visible label text" would reinforce the guidance for existing techniques to ensure conformance and benefit for all user groups.
SC 2.5.3 text: "the name contains the text that is presented visually"
which is hardly different from what the new techniques say:
G208: Including the text of the visible label as part of the accessible name
G211: Matching the accessible name to the visible label

Though this thread discusses SC 2.5.3 in the context of links, the above thoughts still apply.
Thanks,
Sailesh

From: Patrick H. Lauke
Date: Wed, Jun 23 2021 4:57PM
Subject: Re: [EXT] Label in name
← Previous message | Next message →

On 23/06/2021 22:21, Sailesh Panchang wrote:
> Some thoughts for consideration:
> The Understanding doc states the SC does not apply when there is no visible label.
> In a sense it does not apply also when one has used technique H44 (for-id) method to associate the visible label with the control thereby meeting SC 1.3.1.

It's not that it does not apply. I'd rather say that following H44 is
also a good way to satisfy the SC.

> No further testing of SC 2.5.3 is required in this case.

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

<label for="foo">Foo</label>
<input id="foo" aria-label="Bar">

> Therefore, even WCAG 2.0 considered the needs of voice input AT users;

Not really. It's more a side effect.

> Though the native HTML LABEL element (and thus H44) rank lower in the accessible name computation

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.

> it has benefits for multiple user groups and should be the preferred technique.

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.

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

From: Sailesh Panchang
Date: Fri, Jun 25 2021 2:51PM
Subject: Re: [EXT] Label in name
← Previous message | Next message →

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.

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?

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.

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.
The problem happens when instead of using techniques that rely on
native attributes / properties that are designed to help multiple user
groups gets overlooked because of implementer's penchant for using
WAI-ARIA without understanding the situations in which the use of
ARIA techniques is recommended.
e.g. using aria-labelledby in place of H44 for a 1-1 label-control association.

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.

Thanks,
Sailesh


On 6/23/21, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 23/06/2021 22:21, Sailesh Panchang wrote:
>> Some thoughts for consideration:
>> The Understanding doc states the SC does not apply when there is no
>> visible label.
>> In a sense it does not apply also when one has used technique H44
>> (for-id) method to associate the visible label with the control thereby
>> meeting SC 1.3.1.
>
> It's not that it does not apply. I'd rather say that following H44 is
> also a good way to satisfy the SC.
>
>> No further testing of SC 2.5.3 is required in this case.
>
> 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
>
> <label for="foo">Foo</label>
> <input id="foo" aria-label="Bar">
>
>> Therefore, even WCAG 2.0 considered the needs of voice input AT users;
>
> Not really. It's more a side effect.
>
>> Though the native HTML LABEL element (and thus H44) rank lower in the
>> accessible name computation
>
> 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.
>
>> it has benefits for multiple user groups and should be the preferred
>> technique.
>
> 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.
>
> 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
> > > > >

From: Patrick H. Lauke
Date: Fri, Jun 25 2021 6:17PM
Subject: Re: [EXT] Label in name
← Previous message | Next message →

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

From: Sailesh Panchang
Date: Tue, Jul 06 2021 3:40PM
Subject: Re: [EXT] Label in name
← Previous message | No next message

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 ADDRESS 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
> > > > >