E-mail List Archives

Search E-mail List Archives for

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

From: glen walker
Date: Mon, Apr 06 2020 4:07PM
Subject: programmatically determined link context (2.4.4)
No previous message | Next message →

Is the definition of "programmatically determined link context" an
exhaustive list of what constitutes "context" or just an example list
(meaning other things could be considered context)?

https://www.w3.org/TR/WCAG21/#dfn-programmatically-determined-link-context

The definition says:

*"In HTML, information that is programmatically determinable from a link in
English includes text that is in the same paragraph, list, or table cell as
the link or in a table header cell that is associated with the table cell
that contains the link"*

There are only 4 conditions in that definition:

1. text in the same paragraph
2. text in the same list
3. text in the same table cell
4. text in the table header cell

Anything beyond that is not considered programmatically determined link
context?

The definition of "programmatically determined link context" is in the
glossary section and there's a note regarding the glossary as:

*"Many of these success criteria reference new terms that have also been
added to the glossary and form part of the normative requirements of the
success criteria."*

So the glossary is considered normative.

I have a situation with the following basic DOM layout:

<h3>heading</h3>
<p>stuff</p>
<a href="...">read more</a>

I've seen people argue that the heading is "context" for the link but that
doesn't fall into the glossary definition of context.

Personally, I always recommend 2.4.9 instead of 2.4.4 so that you don't
have to rely on figuring out what the context is, so in the case above, I'd
put an ID on the heading then use aria-labelledby on the link to reference
the heading.

<h3 id="id1">heading</h3>
<p>stuff</p>
<a href="..." id="id2" aria-labelledby="id2 id1">read more</a>

I wasn't sure if I was being too pedantic on the definition of context or
if the glossary definition was just a few examples and not an exhaustive
list. I don't like the slippery slope or nebulousness of who defines what
"context" is. I like using what's in the glossary and if none of those 4
contexts apply, then it fails 2.4.4.

From: Patrick H. Lauke
Date: Mon, Apr 06 2020 4:51PM
Subject: Re: programmatically determined link context (2.4.4)
← Previous message | Next message →

On 06/04/2020 23:07, glen walker wrote:
[...]
> Anything beyond that is not considered programmatically determined link
> context?

Correct. The glossary is normative, and it has been worded as an
exhaustive list.

In the past, there had been a vague understanding/interpretation that
preceding headings also provided context, but at some point AGWG decided
that no, that's not the case (can't find the exact decision, which I
seem to remember may have been on WAI mailing list, but this closed
issue in github refers to it https://github.com/w3c/wcag/issues/819).

Personally, I disagree with the decision, but...that wouldn't be the
first time.

[...]

> I have a situation with the following basic DOM layout:
>
> <h3>heading</h3>
> <p>stuff</p>
> <a href="...">read more</a>
>
> I've seen people argue that the heading is "context" for the link but that
> doesn't fall into the glossary definition of context.
>
> Personally, I always recommend 2.4.9 instead of 2.4.4 so that you don't
> have to rely on figuring out what the context is, so in the case above, I'd
> put an ID on the heading then use aria-labelledby on the link to reference
> the heading.
>
> <h3 id="id1">heading</h3>
> <p>stuff</p>
> <a href="..." id="id2" aria-labelledby="id2 id1">read more</a>
>
> I wasn't sure if I was being too pedantic on the definition of context or
> if the glossary definition was just a few examples and not an exhaustive
> list. I don't like the slippery slope or nebulousness of who defines what
> "context" is. I like using what's in the glossary and if none of those 4
> contexts apply, then it fails 2.4.4.

I agree both that this is pedantic, but also that it's likely the
correct interpretation for 2.4.4 based on the restrictive normative
definition of context. (Unless, due to styling of the actual page, you
could make an argument that that link is "ambiguous to everybody".)

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: Birkir R. Gunnarsson
Date: Mon, Apr 06 2020 5:57PM
Subject: Re: programmatically determined link context (2.4.4)
← Previous message | Next message →

I agree on the preceiding heading. The argument was something like,
you can read the same sentence or paragraph using a screen reader
shortcut but not the preceeding heading.
This is not really true, not in all screen readers anyway, but I ain't
gonna argue the case.

Speaking of which, the two links are probably in different paragraph
tags I would imagine, and paragraph is one of the programmatically
determined passes.

I recommend visually hidden text to give the link a readable text by
adding words such as "about" in along with the heading.
The aria-labelledby approach works fine, as well as using
aria-describedby to reference the id of the heading, simpler than
aria-labelledby referring to the link itself.



On 4/6/20, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 06/04/2020 23:07, glen walker wrote:
> [...]
>> Anything beyond that is not considered programmatically determined link
>> context?
>
> Correct. The glossary is normative, and it has been worded as an
> exhaustive list.
>
> In the past, there had been a vague understanding/interpretation that
> preceding headings also provided context, but at some point AGWG decided
> that no, that's not the case (can't find the exact decision, which I
> seem to remember may have been on WAI mailing list, but this closed
> issue in github refers to it https://github.com/w3c/wcag/issues/819).
>
> Personally, I disagree with the decision, but...that wouldn't be the
> first time.
>
> [...]
>
>> I have a situation with the following basic DOM layout:
>>
>> <h3>heading</h3>
>> <p>stuff</p>
>> <a href="...">read more</a>
>>
>> I've seen people argue that the heading is "context" for the link but
>> that
>> doesn't fall into the glossary definition of context.
>>
>> Personally, I always recommend 2.4.9 instead of 2.4.4 so that you don't
>> have to rely on figuring out what the context is, so in the case above,
>> I'd
>> put an ID on the heading then use aria-labelledby on the link to
>> reference
>> the heading.
>>
>> <h3 id="id1">heading</h3>
>> <p>stuff</p>
>> <a href="..." id="id2" aria-labelledby="id2 id1">read more</a>
>>
>> I wasn't sure if I was being too pedantic on the definition of context or
>> if the glossary definition was just a few examples and not an exhaustive
>> list. I don't like the slippery slope or nebulousness of who defines
>> what
>> "context" is. I like using what's in the glossary and if none of those 4
>> contexts apply, then it fails 2.4.4.
>
> I agree both that this is pedantic, but also that it's likely the
> correct interpretation for 2.4.4 based on the restrictive normative
> definition of context. (Unless, due to styling of the actual page, you
> could make an argument that that link is "ambiguous to everybody".)
>
> 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
> > > > >


--
Work hard. Have fun. Make history.

From: Patrick H. Lauke
Date: Mon, Apr 06 2020 6:06PM
Subject: Re: programmatically determined link context (2.4.4)
← Previous message | Next message →

On 07/04/2020 00:57, Birkir R. Gunnarsson wrote:
> I agree on the preceiding heading. The argument was something like,
> you can read the same sentence or paragraph using a screen reader
> shortcut but not the preceeding heading.
> This is not really true, not in all screen readers anyway, but I ain't
> gonna argue the case.

It's also based purely on the current (or even more so, the "then"
current) state of AT. There's nothing preventing AT from being able to
easily expose/query "what's the closest preceding heading that this link
falls under, hierarchically". But instead of basing the requirement on
how the hierarchy/structure could be (programmatically) determined, it
instead focused on the UA support...

But yes, this argument is likely not one that the working group will
want to reopen once again (at least not for WCAG 2.x).

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: Mon, Apr 06 2020 6:20PM
Subject: Re: programmatically determined link context (2.4.4)
← Previous message | Next message →

On 07/04/2020 01:06, Patrick H. Lauke wrote:
> But yes, this argument is likely not one that the working group will
> want to reopen once again (at least not for WCAG 2.x).

But hey, I'm a glutton for punishment...
https://github.com/w3c/wcag/issues/1097

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: Detlev Fischer
Date: Wed, Apr 08 2020 5:43AM
Subject: Re: programmatically determined link context (2.4.4)
← Previous message | No next message

If the definitive criterion for the interpretation of 2.4.4 Link Purpose
(In Context) is the normative text, I would like to brush aside the
demotion of H80 and even the reworking of failure F63 in WCAG 2.1 and
focus on the glossary definition of programmatically determined link
context. This definition does not explicitly exclude headings - it just
says it "..includes text that is in the same paragraph, list.." etc.

So I think it is permissible to read "include" to allow for other ways
of programmatic determination that are *not* enumerated, such as
preceding heading, aria-label, referencing via aria-labelledby, etc. In
reading mode screen readers commonly allow quick access to the
immediately preceding heading via SHIFT + H.

This is the full text of the glossary entry:

-- start quote --

programmatically determined link context

additional information that can be programmatically determined from
relationships with a link, combined with the link text, and presented to
users in different modalities

In HTML, information that is programmatically determinable from a link
in English includes text that is in the same paragraph, list, or table
cell as the link or in a table header cell that is associated with the
table cell that contains the link.

Note

Since screen readers interpret punctuation, they can also provide the
context from the current sentence, when the focus is on a link in that
sentence.

-- ende quote --


Am 07.04.2020 um 02:20 schrieb Patrick H. Lauke:
> On 07/04/2020 01:06, Patrick H. Lauke wrote:
>> But yes, this argument is likely not one that the working group will
>> want to reopen once again (at least not for WCAG 2.x).
>
> But hey, I'm a glutton for punishment...
> https://github.com/w3c/wcag/issues/1097
>
> P

--
Detlev Fischer
Testkreis
Werderstr. 34, 20144 Hamburg

Mobil +49 (0)157 57 57 57 45

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites