E-mail List Archives

Search E-mail List Archives for

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

From: Sumit Patel
Date: Fri, Mar 06 2020 12:32AM
Subject: 2.4.4 Link purpose (In context)
No previous message | Next message →

Hai all,

Hope all of you are doing well...

I was reading about Link purpose and got a small doubt regarding it.
As if link doesn't have descriptive link purpose, then it'll fall into
2.4.4. But, we will give recommendation as to provide descriptive
label using aria-label. So, which SC it will violate? . 2.4.4 or 2.4.6
?

Thanks in advance
Sumit Patel

From: glen walker
Date: Fri, Mar 06 2020 2:05AM
Subject: Re: 2.4.4 Link purpose (In context)
← Previous message | Next message →

2.4.6 is more about the visible label you see for a form element (and other
elements) and does not refer to aria-label.

If a link's text does not have context, then it's 2.4.4

On Fri, Mar 6, 2020 at 12:33 AM Sumit Patel < = EMAIL ADDRESS REMOVED = >
wrote:

> Hai all,
>
> Hope all of you are doing well...
>
> I was reading about Link purpose and got a small doubt regarding it.
> As if link doesn't have descriptive link purpose, then it'll fall into
> 2.4.4. But, we will give recommendation as to provide descriptive
> label using aria-label. So, which SC it will violate? . 2.4.4 or 2.4.6
> ?
>
> Thanks in advance
> Sumit Patel
> > > > >

From: Maxability A11Y
Date: Fri, Mar 06 2020 2:20AM
Subject: Re: 2.4.4 Link purpose (In context)
← Previous message | Next message →

Hi Sumit,
Thats a good question. You will still fail 2.4.4 link purpose. 2.4.6 labels or headings is for form labels, not labels for links.


Regards - Rakesh,
M: 9948243336, E: = EMAIL ADDRESS REMOVED =
Sent from my iPhone

> On 06-Mar-2020, at 1:03 PM, Sumit Patel < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hai all,
>
> Hope all of you are doing well...
>
> I was reading about Link purpose and got a small doubt regarding it.
> As if link doesn't have descriptive link purpose, then it'll fall into
> 2.4.4. But, we will give recommendation as to provide descriptive
> label using aria-label. So, which SC it will violate? . 2.4.4 or 2.4.6
> ?
>
> Thanks in advance
> Sumit Patel
> > > >

From: Sumit Patel
Date: Fri, Mar 06 2020 3:24AM
Subject: Re: 2.4.4 Link purpose (In context)
← Previous message | Next message →

Thanks for both of your response ,
So, If in the case of a "Learn more" button which does not describe
enough in the context, since it is a button it will fall into 2.4.6.
But, still here we'll give recommendation as use aria-label. So, which
SC it will fall into?

On 06/03/2020, Sumit Patel < = EMAIL ADDRESS REMOVED = > wrote:
> Hai all,
>
> Hope all of you are doing well...
>
> I was reading about Link purpose and got a small doubt regarding it.
> As if link doesn't have descriptive link purpose, then it'll fall into
> 2.4.4. But, we will give recommendation as to provide descriptive
> label using aria-label. So, which SC it will violate? . 2.4.4 or 2.4.6
> ?
>
> Thanks in advance
> Sumit Patel
>

From: Birkir R. Gunnarsson
Date: Fri, Mar 06 2020 5:10AM
Subject: Re: 2.4.4 Link purpose (In context)
← Previous message | Next message →

This is where
WCAG shows its age. I think when 2.4.4 vs. 2.4.6 were created we
typically didn't have more than one button per page, the web
experience was link based.
In my interpretation 2.4.4 is about accessible name of links, not visible text.
Links to different destination need to have different accessible
names, even if the visible text is the same.
This is why, yes, you could use aria-label to fix 2.4.4 (or screen
reader only text).
<a href="http://www.1.com" aria-label="learn more about 1">Learn more</a>
<a href="http://www.2.com" aria-label="learn more about 2">Learn more</a>
The requirements for headings and buttons (2.4.6) are less specific
(which is kind of odd, the same principals should apply).


On 3/6/20, Sumit Patel < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks for both of your response ,
> So, If in the case of a "Learn more" button which does not describe
> enough in the context, since it is a button it will fall into 2.4.6.
> But, still here we'll give recommendation as use aria-label. So, which
> SC it will fall into?
>
> On 06/03/2020, Sumit Patel < = EMAIL ADDRESS REMOVED = > wrote:
>> Hai all,
>>
>> Hope all of you are doing well...
>>
>> I was reading about Link purpose and got a small doubt regarding it.
>> As if link doesn't have descriptive link purpose, then it'll fall into
>> 2.4.4. But, we will give recommendation as to provide descriptive
>> label using aria-label. So, which SC it will violate? . 2.4.4 or 2.4.6
>> ?
>>
>> Thanks in advance
>> Sumit Patel
>>
> > > > >


--
Work hard. Have fun. Make history.

From: glen walker
Date: Fri, Mar 06 2020 4:05PM
Subject: Re: 2.4.4 Link purpose (In context)
← Previous message | Next message →

Birkir: "In my interpretation 2.4.4 is about accessible name of links, not
visible text."

Yeah, kinda sorta. It's definitely about links but not necessarily about
the accessible name. You could have a crappy accessible name of "read
more" and if that link was embedded in a paragraph, technically it has
context so would pass 2.4.4. But if I bring up the list of links on the
page, all I'll hear is "read more" without the context. It's a terrible
user experience and requires the user to hunt for the context. Yes, some
screen readers have shortcut keys to let you read the paragraph or the
table cell where the link is contained, but it still requires one to do
more exploring than you should have to do.

I always lean towards 2.4.9 even though it's AAA. I'll use aria-labelledby
on "read more" links so that it's labelled by itself ("read more") as well
as whatever context it should be associated with, whether a heading or a
sentence or even a few key phrases from a sentence. That makes the link
sound beautiful with the screen reader and also makes it sound good when
you bring up the list of links.

But from a conceptual view, Birkir is right. Sometimes I get a bit OCD
about the technicalities.

Back to Sumit's question, there seems to be some confusion that the
remediation suggestion (whether to use aria-label or aria-labelledby or
whatever) affects which success criteria to use for the failure. The two
are unrelated. How you fix a problem has nothing to do with the success
criteria.

And going back to 2.4.6, as noted earlier, 4.1.2 says a form element, such
as a button, has to have an accessible name. As long as a name can be
computed (and role and value), then it passes 4.1.2. The name of the
button could be terrible, such as "click here", but technically it has an
accessible name so 4.1.2 is ok. Where it would fail is 2.4.6. The button
has a name/label but the name/label does not describe the purpose.

So when working with buttons (or other form elements), 4.1.2 and 2.4.6 come
into play.
When working with links, 2.4.4 comes into play.

Just be careful because your original question said "if link doesn't have
descriptive link purpose, then it'll fall into 2.4.4". If it doesn't have
a descriptive purpose *by itself*, it doesn't necessarily fail 2.4.4. If
it's not descriptive even with its context, then it would fail.


And now for our next fun topic, what's the difference between "labels" in
2.4.6 and "labels" in 3.3.2? Both have a definition link in the success
criterion but the links point to the same place.

To me, 3.3.2 is similar to 4.1.2 in that it says the label has to exist.
It could be a crappy label, but if it exists then 3.3.2 would pass.
Whether it's a good label is up to 2.4.6.

It would have been fun to have these discussions at CSUN.

From: Birkir R. Gunnarsson
Date: Fri, Mar 06 2020 5:00PM
Subject: Re: 2.4.4 Link purpose (In context)
← Previous message | Next message →

Yes, 3.3.2 requires that a form control has a persistent visible label
(no, it can't be labeled by placeholder text alone), any label passes
3.3.2, 2.4.6 requires that the label describes topic/purpose.
2.4.6 does not say that the label has to uniquely describe topic pr
purpose, so "delete" or "read more" seem to be sufficient, at least on
the surface, even if you really want users to be able to clearly
distinguish between multiple "delete" buttons on the same page, or at
least be damn sure what they are deleting (3.3.4 comes into play here,
to some extent, if the deletion affects user data or financial info).
Yes, I stayed clear of the programmatic context for links discussion.
Htere is plenty to unpack there, but since I get to set standards for
my organization I simply don't allow it, (links in a data table being
the only exception).
I just use visually hidden text and have people write out the
clarification text, rather ann using id connections and
aria-labelledby, but only because it is less technical and easier for
the content team to solve.
<a href="http://2">Read more <span class="ScreenReader"> about 2</span></a>



On 3/6/20, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> Birkir: "In my interpretation 2.4.4 is about accessible name of links, not
> visible text."
>
> Yeah, kinda sorta. It's definitely about links but not necessarily about
> the accessible name. You could have a crappy accessible name of "read
> more" and if that link was embedded in a paragraph, technically it has
> context so would pass 2.4.4. But if I bring up the list of links on the
> page, all I'll hear is "read more" without the context. It's a terrible
> user experience and requires the user to hunt for the context. Yes, some
> screen readers have shortcut keys to let you read the paragraph or the
> table cell where the link is contained, but it still requires one to do
> more exploring than you should have to do.
>
> I always lean towards 2.4.9 even though it's AAA. I'll use aria-labelledby
> on "read more" links so that it's labelled by itself ("read more") as well
> as whatever context it should be associated with, whether a heading or a
> sentence or even a few key phrases from a sentence. That makes the link
> sound beautiful with the screen reader and also makes it sound good when
> you bring up the list of links.
>
> But from a conceptual view, Birkir is right. Sometimes I get a bit OCD
> about the technicalities.
>
> Back to Sumit's question, there seems to be some confusion that the
> remediation suggestion (whether to use aria-label or aria-labelledby or
> whatever) affects which success criteria to use for the failure. The two
> are unrelated. How you fix a problem has nothing to do with the success
> criteria.
>
> And going back to 2.4.6, as noted earlier, 4.1.2 says a form element, such
> as a button, has to have an accessible name. As long as a name can be
> computed (and role and value), then it passes 4.1.2. The name of the
> button could be terrible, such as "click here", but technically it has an
> accessible name so 4.1.2 is ok. Where it would fail is 2.4.6. The button
> has a name/label but the name/label does not describe the purpose.
>
> So when working with buttons (or other form elements), 4.1.2 and 2.4.6 come
> into play.
> When working with links, 2.4.4 comes into play.
>
> Just be careful because your original question said "if link doesn't have
> descriptive link purpose, then it'll fall into 2.4.4". If it doesn't have
> a descriptive purpose *by itself*, it doesn't necessarily fail 2.4.4. If
> it's not descriptive even with its context, then it would fail.
>
>
> And now for our next fun topic, what's the difference between "labels" in
> 2.4.6 and "labels" in 3.3.2? Both have a definition link in the success
> criterion but the links point to the same place.
>
> To me, 3.3.2 is similar to 4.1.2 in that it says the label has to exist.
> It could be a crappy label, but if it exists then 3.3.2 would pass.
> Whether it's a good label is up to 2.4.6.
>
> It would have been fun to have these discussions at CSUN.
> > > > >


--
Work hard. Have fun. Make history.

From: Patrick H. Lauke
Date: Fri, Mar 06 2020 6:00PM
Subject: Re: 2.4.4 Link purpose (In context)
← Previous message | Next message →

On 07/03/2020 00:00, Birkir R. Gunnarsson wrote:
> Yes, 3.3.2 requires that a form control has a persistent visible label
> (no, it can't be labeled by placeholder text alone), any label passes
> 3.3.2, 2.4.6 requires that the label describes topic/purpose.
> 2.4.6 does not say that the label has to uniquely describe topic pr
> purpose, so "delete" or "read more" seem to be sufficient, at least on
> the surface, even if you really want users to be able to clearly
> distinguish between multiple "delete" buttons on the same page, or at
> least be damn sure what they are deleting (3.3.4 comes into play here,
> to some extent, if the deletion affects user data or financial info).

I've recently pondered if having various "delete", "read more" etc
buttons (not links) that are visually clearly related to something but
lack any other association/hint in their accessible name may be failing
1.3.1 Info and Relationships. Seems a reasonable SC to hang a failure
against.

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: Greg Jellin
Date: Fri, Mar 06 2020 7:29PM
Subject: Re: 2.4.4 Link purpose (In context)
← Previous message | Next message →

I realize this isn't the purpose of this discussion, so apologies for
taking this thread on a tangent, but Birkir, you mention 3.3.2 requires
a PERSISTENT visible label. I advise this as well, but I've yet to be
able to identify where in 3.3.2 I can find support to enforce that as
required. Can anyone explain how we can interpret it as required?

-Greg

On 3/6/2020 5:00 PM, Patrick H. Lauke wrote:
> On 07/03/2020 00:00, Birkir R. Gunnarsson wrote:
>> Yes, 3.3.2 requires that a form control has a persistent visible label
>> (no, it can't be labeled by placeholder text alone), any label passes
>> 3.3.2, 2.4.6 requires that the label describes topic/purpose.
>> 2.4.6 does not say that the label has to uniquely describe topic pr
>> purpose, so "delete" or "read more" seem to be sufficient, at least on
>> the surface, even if you really want users to be able to clearly
>> distinguish between multiple "delete" buttons on the same page, or at
>> least be damn sure what they are deleting (3.3.4 comes into play here,
>> to some extent, if the deletion affects user data or financial info).
>
> I've recently pondered if having various "delete", "read more" etc
> buttons (not links) that are visually clearly related to something but
> lack any other association/hint in their accessible name may be
> failing 1.3.1 Info and Relationships. Seems a reasonable SC to hang a
> failure against.
>
> P

From: Birkir R. Gunnarsson
Date: Sat, Mar 07 2020 12:50AM
Subject: Re: 2.4.4 Link purpose (In context)
← Previous message | Next message →

With some "creative interpretation".
The success criterion requires visible labels, it doesn't say "visible
label when empty " or "visible labels when filled in", which I take to
mean the form control labels have to be visible in both states.
In other words, the visible labels have to be there when you load the
page and they also have to be there after you've filled in the text
inputs, the value of a text input is not a visible and descriptive
label for the input (2.4.6 again).

Theoretically, does it pass if visible label is only display on
hover/focus? It's up to interpretation I guess (and possibly it could
be argued that it would suffice).
I choose not to believe it. *grin*
I've seen a stronger argument in the past, I'm sure about it, but I
also fail to find it now.


On 3/6/20, Greg Jellin < = EMAIL ADDRESS REMOVED = > wrote:
> I realize this isn't the purpose of this discussion, so apologies for
> taking this thread on a tangent, but Birkir, you mention 3.3.2 requires
> a PERSISTENT visible label. I advise this as well, but I've yet to be
> able to identify where in 3.3.2 I can find support to enforce that as
> required. Can anyone explain how we can interpret it as required?
>
> -Greg
>
> On 3/6/2020 5:00 PM, Patrick H. Lauke wrote:
>> On 07/03/2020 00:00, Birkir R. Gunnarsson wrote:
>>> Yes, 3.3.2 requires that a form control has a persistent visible label
>>> (no, it can't be labeled by placeholder text alone), any label passes
>>> 3.3.2, 2.4.6 requires that the label describes topic/purpose.
>>> 2.4.6 does not say that the label has to uniquely describe topic pr
>>> purpose, so "delete" or "read more" seem to be sufficient, at least on
>>> the surface, even if you really want users to be able to clearly
>>> distinguish between multiple "delete" buttons on the same page, or at
>>> least be damn sure what they are deleting (3.3.4 comes into play here,
>>> to some extent, if the deletion affects user data or financial info).
>>
>> I've recently pondered if having various "delete", "read more" etc
>> buttons (not links) that are visually clearly related to something but
>> lack any other association/hint in their accessible name may be
>> failing 1.3.1 Info and Relationships. Seems a reasonable SC to hang a
>> failure against.
>>
>> P
> > > > >


--
Work hard. Have fun. Make history.

From: Patrick H. Lauke
Date: Sat, Mar 07 2020 3:04AM
Subject: Re: 2.4.4 Link purpose (In context)
← Previous message | No next message

On 07/03/2020 07:50, Birkir R. Gunnarsson wrote:
> With some "creative interpretation".
> The success criterion requires visible labels, it doesn't say "visible
> label when empty " or "visible labels when filled in", which I take to
> mean the form control labels have to be visible in both states.
> In other words, the visible labels have to be there when you load the
> page and they also have to be there after you've filled in the text
> inputs, the value of a text input is not a visible and descriptive
> label for the input (2.4.6 again).

Agree. By saying that it requires a visible label - without qualifiers
about how long the label remains visible, when it shows up, etc - the SC
is admittedly vague and left up to interpretation, but when considering
the intent that essentially says "user must know what they're actually
expected to put in" and imagining a scenario where a field is pre-filled
or the user set focus on a field, then got distracted/had to do
something else, and then returns to the page again...and they find that
none of the prefilled fields and the field that currently has focus show
any label, that would then fail.

See https://github.com/w3c/wcag/issues/864 where at least one other AGWG
agrees :)

> Theoretically, does it pass if visible label is only display on
> hover/focus? It's up to interpretation I guess (and possibly it could
> be argued that it would suffice).
> I choose not to believe it. *grin*
> I've seen a stronger argument in the past, I'm sure about it, but I
> also fail to find it now.

I've strongly argued against a particular example given in WCAG, but
opinion seems to be split https://github.com/w3c/wcag/issues/755

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