labelled navigation landmarks should be added to sufficient techniques for 2.4.4

[Wildebrew]

I believe that the techniques for meeting 2.4.4 need to be updated with consideration to ARIA landmarks; iN particular, labelled navigation landmarks.
A navigation landmark is defined as a collection of links with a common purpose.
If the navigation landmark has an accessible name, that name becomes a group label for that collection of links.
You may often have situations where you have links with otherwise identical text in different groups.

A common use case for this is a site footer with a collection of links, sometimes with the same link text.
For instance:

<nav aria-labelledby="per">
<h4 id=per">Personal</h4>
<ul>
,li><a href="#">credit cards</a></li>
..
</ul>
,/nav>

<nav id="bus">
<h4 id="bus">Business</h4>
<ul>
<li><a href="#">Credit cards</a></li>
..
</ul>
</nav>

I think, given the definition of the navigation role as serving this exact purpose, that its use should be added to sufficient techniques for 2.4.4
In fact I think it is a much clearer programmatic distinction than the same sentence or paragraph.

[alastc]

(Individual comment, not from the group):

I see the point, I always recommend naming nav elements if you have more than 1.

However, 2.4.4 is scoped to links rather than groups of links. and we have ARIA13 which is a technique for 1.3.1 info & relationships.

I think that's a better place for that technique as it is for conveying the design of the group, do you agree?

[alastc]

Draft group response:

We have ARIA13 which is a technique for 1.3.1 info & relationships, which is very close to the technique

There were a couple of concerns with adding it to 2.4.4:

• Would this encourage lots of nav landmarks? That would be quite noisy.
• Is there any assistive technology that would include the nav-label to help differentiate links?

Do you have a live example that you'd think would suit this as a technique for 2.4.4?

[JAWS-test]

2.4.4 defines a programmatically determinable context:

Example: 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.

The context of most of the examples given here is difficult or impossible to determine with the screenreader. On the other hand, the support of landmark regions as context in the screenreader is relatively good and should therefore be included in the list of permitted contexts.
Furthermore, I suggest to check with different screenreaders whether the other variants can really be used as context and if not, to remove them in 2.4.4.

[mraccess77]

Regarding the test for this -- the test was to determine if the screen reader could get context without moving focus. For example, reading the current sentence, paragraph, list item, and table cell are all possible through screen reader commands without moving focus (either virtual or otherwise). There are commands for those in JAWS and NVDA among others. Landmarks would need to meet the same requirement.

[awkawk]

Agree with @mraccess77 - I would prefer that the context included headings for a set of links, but the group didn't agree and this is why H80 (https://www.w3.org/WAI/WCAG21/Techniques/html/H80) is an advisory technique.

[JAWS-test]

@mraccess77 Is there a test page for 2.4.4? I wonder if the link purpose can also be determined from the context in Talkback, Voiceover and Zoomtext? I also think that it is much easier to determine the purpose of the link with landmarks, because the landmark label is output automatically without having to use rarely used access keys.

[mraccess77]

@JAWS-test when you say "landmark label is output automatically without having to use rarely used access keys." do you mean when you arrow to the link in browse mode or tab to it or both for screen readers like NVDA and JAWS? As for other mobile screen readers those were not around when WCAG 2 was first introduced.

In my experience with JAWS it only announces the landmark name for the first link and not for subsequent links. Also there doesn't seem to be a way to announce it again. Insert+t announces that you are in a region but doesn't seem to speak the name of the region. So this seems less supported.

[JAWS-test]

@mraccess77 I mean: when navigating with the tab key. When reading with the arrow keys, the beginning and end of the landmark regions and their labels are output anyway. If 2.4.4 is revised (possibly WCAG 2.2 or 3.0), it should be noted that there are now other methods to determine the purpose of the link from the context. What speaks against the landmarks, of course, is the fact that the link purpose is not only important for screenreader users who are not explicitly named in the chapter "Benefits". For all other user groups the landmark labels are usually invisible and therefore not suitable for the link context. However, this also applies to several other techniques such as Using CSS to hide a portion of the link text.

I generally don't think it's a good idea to determine the link purpose from the context and would like to see 2.4.4 being removed and 2.4.9 becoming a Level A criterion - or both 2.4.4 and 2.4.9 being removed, because in my opinion there is no relevant difference between links and other interactive elements today, so it would be better to have a common criterion for the consistent, unambiguous and meaningful labeling of all interactive elements (links, buttons, form fields etc.). I don't understand why there is the exception for links that the purpose does not have to result from the label, but from the context.

In addition, I think that if there is such an exception, there should be a requirement elsewhere for assistive technology or user agents to be able to determine the link context. Unfortunately, I cannot find such a requirement in the UAAG or other documents. Is there such a requirement? If not, WCAG should not rely on all user agents or AT to implement it automatically.

Is there a test page for 2.4.4? Is there a documentation of the access keys that are used to determine the link contexts?

[mraccess77]

Screen readers can already programmatically determine the sentence, list item, and pargraph and could choose to display this in the list of links or announced on tab per a user a setting if they wanted to. Adding this information into every link's accessible name would then make arrowing to links more wordy as you'd hear the sentence when reading with down arrow and then hear the sentence again when arrowing to a link. This is best addressed by the screen readers. I don't know if there is a UAAG criterion for htis.

In my opinion landmarks are not enough because the name is only announced when tabbing to the first link and the landmark name is likely not enough to understand a link in a sentence within the landmark.

[JAWS-test]

@mraccess77

Screen readers can already programmatically determine the sentence, list item, and pargraph and could choose to display this in the list of links or announced on tab per a user a setting if they wanted to.

I didn't know that and unfortunately I didn't find any explanation about it at the screenreader manufacturers or on other websites. Can you please tell me how this works? I only know the accesskeys to output the context after tabbing to the link.

Adding this information into every link's accessible name would then make arrowing to links more wordy as you'd hear the sentence when reading with down arrow and then hear the sentence again when arrowing to a link.

I would not like to make badly labeled links with aria-label etc. more meaningful, but to link the visible text meaningfully, so that for sighted and not sighted users the purpose is recognizable without context.

[mraccess77]

@JAWS-test what I was saying about screen readers is that they "could" have these features because this information can be problematically exposed. For a long time screen readers didn't even show aria-labelledby or aria-label in the list of links (now they do) -- this was a choice they made even though the information was available when present. From my experience they still do not show/announce aria-describedby in the list of links.

[Wildebrew]

Exactly, just like screen readers could programmatically determine links with identical text that are located in separate labeled groups (fieldset/legend) or ARIA landmarks. We use groups and group labels to distinguish otherwise identical form field labels, why shouldn't the same technique apply to links? I've been thinking about the bigger picture, why treat links differently from buttons, text inputs or other form controls (in other words, why have 2.4.4 at all?). Part of it is probably that 2.4.4 was a product of its time, we didn't have so many or such complex form controls 10, 12, 15 years ago when the SC was created. But the oter thing, what makes links different from most other interactive controls, is that they are independent of the page content. It wouldn't make sense to bring up an alphabetical list of form controls, you should navigate a form in logical order to understand the context of the information you are supplying. But you can bring up an alphabetical list of links and activate the one you want, the context of the link is not as important, I am not a fan of this strategy myself, but I know people use it. But I do think 2.4.4 should be updated and things such as grouping elements or landmark regions with an accessible name should be considered. programmatic context

…

On 9/24/19, Jonathan Avila ***@***.***> wrote: @JAWS-test what I was saying about screen readers is that they "could" have these features because this information can be problematically exposed. For a long time screen readers didn't even show aria-labelledby or aria-label in the list of links (now they do) -- this was a choice they made even though the information was available when present. From my experience they still do not show/announce aria-describedby in the list of links. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #619 (comment)

-- Work hard. Have fun. Make history.

[alastc]

We use groups and group labels to distinguish otherwise identical form
field labels, why shouldn't the same technique apply to links?

It isn't supported in the same way by user-agents.

why treat links differently from buttons, text inputs or other form controls

Typically there are many more links than form controls. They are also dealt with differently by user agents.

If user agents (primarily screenreaders) add features that do something with landmarks for links, then it would make sense to add a technique. However, just because they could do something doesn't make it a sufficient technique, yet.

[JAWS-test]

It isn't supported in the same way by user-agents

I still consider the support of the landmarks by AT to be better than the support of the other technologies, because the labeling of the landmarks is automatically output with tab navigation to the links, whereas the other technologies partly require additional navigation steps with little known access keys.

[alastc]

Support of landmarks, as landmarks is ok, but AFAIK there is no mechanism to understand the context of a link based on landmarks.

[mraccess77]

@JAWS-test the landmark is only announced on the first link in the region and not for subsequent in my experience -- so this is not optimal.

[JAWS-test]

The landmark is only announced on the first link in the region and not for subsequent in my experience -- so this is not optimal.

This is true, but this is also the case with the output of legend within fieldset

[alastc]

The group discussed this today and agreed this response:

---

2.4.4 is scoped to links rather than groups of links, and we have ARIA13 which is a technique for 1.3.1 info & relationships.

Unless AT support demonstrably improves to allow access to link context contained in a landmark label from a link that already has focus, we consider a landmark label insufficient to convey link context.

[emleml]

Sorry for bringing up an old thread however this is the only instance of this question I can find.
I am still confused whether the answer above is inferring the following is a failure of 2.4.4.

<nav aria-labelledby="image-card-heading">
   <h3 id="heading-1">Simple Card code</h3>
   <ul>
    <li><a>HTML</a></li>
    <li><a>CSS</a></li>
    <li><a>JS</a></li>
   </ul>
</nav>
<nav aria-labelledby="image-card-heading">
   <h3 id="image-card-heading">Image Card code</h3>
   <ul>
     <li><a>HTML</a></li>
     <li><a>CSS</a></li>
     <li><a>JS</a></li>
   </ul>
</nav>

I'm sure we have all seen similar implementation of the above... (think: design systems, showing code snippets for multiple different but similar component examples)

Whilst I understand this is in scope of 1.3.1 and ARIA13 as a sufficient technique, I am not clear whether the response above implies as these are groups of links, this is not in scope of 2.4.4, and therefore the implementation above is a failure of this criteria.

Ideally I do not want to overcomplicate this with adding visually hidden text "HTML {for Image Card}" and do not feel this is prudent to show visually either. In fact, technique C7 even states this is not ideal especially when the hidden content is repeated.

Thank you.