E-mail List Archives

Search E-mail List Archives for

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

From: JP Jamous
Date: Tue, Sep 03 2019 9:30AM
Subject: Trying to Understand 2.5.3
No previous message | Next message →

Hi folks,



As I am reading WCAG 2.1, I am really struggling with 2.5.3 Label in Name.
Here are the questions I have.



1. Does aria-labelledby have to be used even on <label>?
2. Does this success criterion suggest that we have to add alt and
title attributes to any HTML element? I had developers in the past use alt
attributes on an anchor tag, which is improper markup.
3. Does 2.5.3 target elements that are divs and spans by ensuring that
they have a role and aria-label with the visible text embedded?





I think what I am lacking to understand this success criterion is some
markup to go along with it. Any help will be much appreciated.







--------------------

JP Jamous

Senior Digital Accessibility Engineer

<mailto: = EMAIL ADDRESS REMOVED = > E-Mail Me | <http://linkedin.com/in/JPJamous>; Join
My LinkedIn Network

--------------------

From: Jonathan Avila
Date: Tue, Sep 03 2019 9:41AM
Subject: Re: Trying to Understand 2.5.3
← Previous message | Next message →

> 1. Does aria-labelledby have to be used even on <label>?

Hi JP, SC 2.5.3 is not aimed at this. The goal of label in name is to make sure the visible label text (however it is displayed visually) is included in the accessible name that is provided on interactive controls including inputs and button (however it is provided).

Jonathan

From: Patrick H. Lauke
Date: Tue, Sep 03 2019 9:49AM
Subject: Re: Trying to Understand 2.5.3
← Previous message | Next message →

2.5.3 applies to user interface components (buttons, form controls,
links, etc).

These have an accessible name (what is conveyed by, say, AT when they
receive focus).

This SC wants to ensure that if there's any visible text that also acts
as a visual label for that control (which may well be a properly
associated label element, or the text content of the button, or
whatever), that the accessible name still contains that text, so that
speech users know how they can invoke that particular control.

<button>Press me</button> would be valid, as "Press me" is both the
visible text, and in the absence of anything else that's also the
accessible name.

<button aria-label="Press me for more information">Press me</button>
would also be valid. The aria-label here overrides the visible text, but
the accessible name still includes "Press me".

<button aria-label="For more information, press me and find out">Press
me</button> is valid - although there's other text in the accessible
name provided by the aria-label, it does still contain "press me" in
that exact order (doesn't matter if there's text before/after it)

<button aria-label="Press the button">Press me</button> fails as the
accessible name does not contain "press me".

Everything else you mention (adding aria-labelledby to a label, adding
alt to things, doing stuff with divs and spans) is all
irrelevant/nothing to do with 2.5.3

P

On 03/09/2019 16:30, JP Jamous wrote:
> Hi folks,
>
>
>
> As I am reading WCAG 2.1, I am really struggling with 2.5.3 Label in Name.
> Here are the questions I have.
>
>
>
> 1. Does aria-labelledby have to be used even on <label>?
> 2. Does this success criterion suggest that we have to add alt and
> title attributes to any HTML element? I had developers in the past use alt
> attributes on an anchor tag, which is improper markup.
> 3. Does 2.5.3 target elements that are divs and spans by ensuring that
> they have a role and aria-label with the visible text embedded?
>
>
>
>
>
> I think what I am lacking to understand this success criterion is some
> markup to go along with it. Any help will be much appreciated.
>
>
>
>
>
>
>
> --------------------
>
> JP Jamous
>
> Senior Digital Accessibility Engineer
>
> <mailto: = EMAIL ADDRESS REMOVED = > E-Mail Me | <http://linkedin.com/in/JPJamous>; Join
> My LinkedIn Network
>
> --------------------
>
>
>
>
>
> > > > >


--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Birkir R. Gunnarsson
Date: Tue, Sep 03 2019 10:31AM
Subject: Re: Trying to Understand 2.5.3
← Previous message | Next message →

One point of clarification, this SC does not cover situations where
controls are visuall labeled with an icon but no text, e.g. a search
button labeled with a magnifying glass icon.
The following code could represent button labeled with a Font Awesome
icon, its aria-label text can be anything you like since there is no
visible text on the button.

<button aria-label="search"><I class="fa fa-search"></I></button>

I filed a WCAG 2.1 issue expressing concerns about this, since these
are the widgets that need to be operable by screen readers and speech
recognition software.

This SC does not apply to divs or spans unless those form the basis of
an operabl component (such as a link, dropdown or text input).

The following would violate 2.5.3
<label for="fn">First name</label>
<input type="text" id="fn" aria-label="your name">
(this would also be stupid UI of course)



On 9/3/19, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> 2.5.3 applies to user interface components (buttons, form controls,
> links, etc).
>
> These have an accessible name (what is conveyed by, say, AT when they
> receive focus).
>
> This SC wants to ensure that if there's any visible text that also acts
> as a visual label for that control (which may well be a properly
> associated label element, or the text content of the button, or
> whatever), that the accessible name still contains that text, so that
> speech users know how they can invoke that particular control.
>
> <button>Press me</button> would be valid, as "Press me" is both the
> visible text, and in the absence of anything else that's also the
> accessible name.
>
> <button aria-label="Press me for more information">Press me</button>
> would also be valid. The aria-label here overrides the visible text, but
> the accessible name still includes "Press me".
>
> <button aria-label="For more information, press me and find out">Press
> me</button> is valid - although there's other text in the accessible
> name provided by the aria-label, it does still contain "press me" in
> that exact order (doesn't matter if there's text before/after it)
>
> <button aria-label="Press the button">Press me</button> fails as the
> accessible name does not contain "press me".
>
> Everything else you mention (adding aria-labelledby to a label, adding
> alt to things, doing stuff with divs and spans) is all
> irrelevant/nothing to do with 2.5.3
>
> P
>
> On 03/09/2019 16:30, JP Jamous wrote:
>> Hi folks,
>>
>>
>>
>> As I am reading WCAG 2.1, I am really struggling with 2.5.3 Label in
>> Name.
>> Here are the questions I have.
>>
>>
>>
>> 1. Does aria-labelledby have to be used even on <label>?
>> 2. Does this success criterion suggest that we have to add alt and
>> title attributes to any HTML element? I had developers in the past use
>> alt
>> attributes on an anchor tag, which is improper markup.
>> 3. Does 2.5.3 target elements that are divs and spans by ensuring that
>> they have a role and aria-label with the visible text embedded?
>>
>>
>>
>>
>>
>> I think what I am lacking to understand this success criterion is some
>> markup to go along with it. Any help will be much appreciated.
>>
>>
>>
>>
>>
>>
>>
>> --------------------
>>
>> JP Jamous
>>
>> Senior Digital Accessibility Engineer
>>
>> <mailto: = EMAIL ADDRESS REMOVED = > E-Mail Me | <http://linkedin.com/in/JPJamous>;
>> Join
>> My LinkedIn Network
>>
>> --------------------
>>
>>
>>
>>
>>
>> >> >> >> >>
>
>
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Work hard. Have fun. Make history.

From: Patrick H. Lauke
Date: Tue, Sep 03 2019 10:48AM
Subject: Re: Trying to Understand 2.5.3
← Previous message | Next message →

On 03/09/2019 17:31, Birkir R. Gunnarsson wrote:
> One point of clarification, this SC does not cover situations where
> controls are visuall labeled with an icon but no text, e.g. a search
> button labeled with a magnifying glass icon.
> The following code could represent button labeled with a Font Awesome
> icon, its aria-label text can be anything you like since there is no
> visible text on the button.
>
> <button aria-label="search"><I class="fa fa-search"></I></button>
>
> I filed a WCAG 2.1 issue expressing concerns about this, since these
> are the widgets that need to be operable by screen readers and speech
> recognition software.

Failing to see though how you'd solve this, other than what, mandating
that all controls must have a visible text label, which won't fly (maybe
as a triple-A SC, at a stretch)?

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Mallory
Date: Tue, Sep 03 2019 11:09AM
Subject: Re: Trying to Understand 2.5.3
← Previous message | Next message →

On Tue, Sep 3, 2019, at 6:48 PM, Patrick H. Lauke wrote:
> Failing to see though how you'd solve this, other than what, mandating
> that all controls must have a visible text label, which won't fly (maybe
> as a triple-A SC, at a stretch)?

I would LUV if this were taken up by browsers. Make it a user setting to show text labels visibly if they exist. No idea how browsers would implement this, unless they simply exposed whatever the computed accessible name of all controls was in a little overlay rather than attempting to find hidden names like stuff in "sr-only" classes.

Developers could do this by hand, similar to how they can deal with users wanting to reduce/remove animations due to a setting (using JS and CSS as we did before prefers-reduced-motion ever was a thing), though it would be a pain. Gmail, for example, mostly does this (with many exceptions): you can choose if you want hieroglyphic buttons, hieroglyphs+text, or text-only.

The fact that visual designers may cry out "oh noes, our precious precious heiroglyphic beauty is befouled with hideous unclean texts!" could make it a AAA, sure. But reducing nausea-inducing animations is also AAA so...

cheers,
_mallory

From: Jonathan Avila
Date: Tue, Sep 03 2019 11:38AM
Subject: Re: Trying to Understand 2.5.3
← Previous message | Next message →

iOS 13's new voice control feature has a "show labels" command. Hopefully it pulls the accessible name and displays that -- that way users can learn what the name is easily and in the future be able to speak that. This would have the side benefit of learning what those cryptic icons mean for everyone.

Jonathan

From: Patrick H. Lauke
Date: Tue, Sep 03 2019 11:51AM
Subject: Re: Trying to Understand 2.5.3
← Previous message | Next message →

On 03/09/2019 18:09, Mallory wrote:

> The fact that visual designers may cry out "oh noes, our precious precious heiroglyphic beauty is befouled with hideous unclean texts!" could make it a AAA, sure.

It's also more the idea of "if we make this a normative SC, we're
essentially going to insta-fail 2/3rds of the internet one way or
another" that makes this a dangerous proposition, not just sparing the
soulds of designers...

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Birkir R. Gunnarsson
Date: Tue, Sep 03 2019 1:45PM
Subject: Re: Trying to Understand 2.5.3
← Previous message | Next message →

My proposal was essentially to treat this situation as an assistive
technology problem, speech recognition software should implement a way
to display the accessible name of operable controls on the screen when
they are provided with aria-label, aria-labelledby or title, so I
didn't really see how this new SC really adds anything useful and
proposed to drop it or make it a level AAA.


On 9/3/19, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 03/09/2019 18:09, Mallory wrote:
>
>> The fact that visual designers may cry out "oh noes, our precious precious
>> heiroglyphic beauty is befouled with hideous unclean texts!" could make it
>> a AAA, sure.
>
> It's also more the idea of "if we make this a normative SC, we're
> essentially going to insta-fail 2/3rds of the internet one way or
> another" that makes this a dangerous proposition, not just sparing the
> soulds of designers...
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Work hard. Have fun. Make history.

From: Patrick H. Lauke
Date: Tue, Sep 03 2019 4:40PM
Subject: Re: Trying to Understand 2.5.3
← Previous message | Next message →

On 03/09/2019 20:45, Birkir R. Gunnarsson wrote:
> My proposal was essentially to treat this situation as an assistive
> technology problem, speech recognition software should implement a way
> to display the accessible name of operable controls on the screen when
> they are provided with aria-label, aria-labelledby or title, so I
> didn't really see how this new SC really adds anything useful and
> proposed to drop it or make it a level AAA.

However, "until user agents..." (to have a little throwback to WCAG 1.0
days) implement this sort of behavior, actual users here and now would
potentially still face problems that the SC tries to mitigate by placing
some of the onus on authors.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Birkir R. Gunnarsson
Date: Tue, Sep 03 2019 5:32PM
Subject: Re: Trying to Understand 2.5.3
← Previous message | Next message →

But if we always put the responsibility on the authors we'll never
make accessibility simple.
There are millions of people who write webpages, even with the rapidly
growing ranks of accessibility experts we're never going to make every
single one of those authors use proper ARIA and understand screen
reader and speech recognition interactions (the latest WebAIm study of
top million webpages found strong correlation between us of ARIA and
bad accessibility).
User agent vendors understand how web markup is processed (browsers)
and the needs of the end users (assistive technology vendors), they
can even work together through the W3C to develop the necessary
mechanisms by which accessible markup is translated to an accessible
experience for users.
That's the key to demystifying accessibility and ensure a consistent
and accessible user experience, even if it takes a bit longer.
This SC is new, does not change much for assistive technology users
and does not address the biggest problem speech recognition users deal
with in this regard, missing text labels for icon controls.
This should have been handled by user agents.



On 9/3/19, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 03/09/2019 20:45, Birkir R. Gunnarsson wrote:
>> My proposal was essentially to treat this situation as an assistive
>> technology problem, speech recognition software should implement a way
>> to display the accessible name of operable controls on the screen when
>> they are provided with aria-label, aria-labelledby or title, so I
>> didn't really see how this new SC really adds anything useful and
>> proposed to drop it or make it a level AAA.
>
> However, "until user agents..." (to have a little throwback to WCAG 1.0
> days) implement this sort of behavior, actual users here and now would
> potentially still face problems that the SC tries to mitigate by placing
> some of the onus on authors.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Work hard. Have fun. Make history.

From: JP Jamous
Date: Tue, Sep 03 2019 7:27PM
Subject: Re: Trying to Understand 2.5.3
← Previous message | Next message →

Thank you Patrick. This made more sense than all of the paragraphs I read.

It is crystal clear now.



--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------

From: Mallory
Date: Wed, Sep 04 2019 1:11PM
Subject: Re: Trying to Understand 2.5.3
← Previous message | No next message

Birkir R. Gunnarsson wrote:
>This SC is new, does not change much for assistive technology users
>and does not address the biggest problem speech recognition users deal
>with in this regard, missing text labels for icon controls.
>This should have been handled by user agents.

I would love user agents to handle this. Maybe Label In Name should have been proposed to the UUAG. Be aware many see speech recognition as nothing more than a convenience for abled people, not assistive technology *coughNuanceCough*

We know in real life that while browsers may take this up within 5 years, Nuance sure won't.

This SC is new but mostly so is one particular problem: we now have a generation of developers doing this sort of thing:

<button type="button" aria-label="You can purchase the new kazoo now for just €9!">
BUY NOW
</button>

In some ways, aria-* is getting developer attention the way alt never did. I see aria-label being thrown all over the place. It's surprisingly popular, and sometimes I see it more than "sr-only" offscreen texts.
In general, devs are going to trigger Label In Name because they did the work of adding some hidden text "for screen readers" and they didn't bother to think about anyone else (and they assumed all screen reader users are totally blind). Having AT work around developers who still don't understand the scope of their job can get you ending up back to when JAWS would see this:

<span>I am label!</span>
<input type="text">

And heuristically see that clearly, the input's accessible name is "I am label!"

Yes, it's hard to teach developers to use labels correctly, but I'm not a fan of some of the hacks on the AT side either. Part of the problem of developers suddenly needing to know all this new ARIA blah-blah is because they *choose* to use ARIA blah-blah instead of semantic HTML (I get that semantic HTML isn't an option for most widgets, but lots of what I audit is forms, nav menus, and articles which could easily be populated with HTML from the late 90's). I'm kinda done with worrying can they handle it? when they seem to have no issue learning the ins and outs of the latest shiny JS framework with that youthful enthousiasm I envy.

Also they tell each other on social media that it's fine to use divs + lots of aria "because the end result is accessible". Fine, then they need to do all the hard work required to do it right. Their choice, their responsibility. That means piling up more guidelines (at least until/unless browsers step in and are able to do an extreme Postel's law).

cheers,
_mallory