Success Criterion 2.4.4 - Link Purpose (In Context) - Level A

[JJdeGroot]

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#link-purpose-in-context

Share your thoughts for applying to mobile apps as a comment below.

[Keanem6]

Might need to define programmatically determined link context in terms of native iOS and Android but apart from that i believe the requirements as written work for native.

[jamieherrera]

One thing I've always wondered with this SC in native apps is whether this should be limited to the term "link" as in hyperlink to a web page, or if it applies more broadly as any interaction that goes to another place. In other words, a button trait for navigating to another screen in an app - or a link to a web view in the app - could be interchangeably used in much of the 2.4.4 Understanding document.

The other question I've come across in practice is whether a button that looks like a hyperlink or vice versa would fail this SC.

[JJdeGroot]

Discussed in today's meeting.

Minutes for 28 August 2024

Source

Jamie Look at the SC in normative text: Are we as a group deciding to just consider this as referencing only a link? Would the button scenarios be covered elsewhere?

Links can also navigate around a page (skip links)

It seems specific to links themselves, not their function

Jamie There are times where things look like a link to do other things. There is some variation in how companies have interpreted this SC

illai maybe we should consider removing it from small changes, because if we aren't sure about how it's conveyed to users could present confusion. We need to define what link means in mobile app context

+1 Illai

Change 2.4.4 label from small to medium or large? Comment below.

+1 medium

+1 medium

+1 medium

+1medium

+1 medium

JJ we need to make sure folks know that we can change the labels if we feel we need to

ACTION: Change 2.4.4 label to medium

ACTION: Create issue for Link definition in context of apps?

julianmka Can we start hashing out a definition of links?

illai: Related is headings and labels: How do we test this? It seems very opinionated? Can we define it in an atomic way? There seems to be space for interpretation

julianmka The key definition is going to lie in the behaviour. Testability is going to be manual

illai: Even manually, auditors may disagree

Apple Developer on a link "'A control for navigating to a URL" https://developer.apple.com/documentation/swiftui/link

On a button "A control that initiates an action." https://developer.apple.com/documentation/swiftui/button

the links in the SC are modeling what is meant, see "ambiguous to users in general"

do we need to define link now?

[AlainVagner]

A link will be announced by screen readers as a link, and not a button. A link is for me what is characterized as a link in the accessibility tree (i.e. like an ARIA role "link").
In an app, I usually see links be used to navigate to an URL, be it with a full fledged browser or an in-app browser.

If we do a parallel with rich web applications, you can navigate with some buttons inside the same page (open a modal, display different content with tabs, ...) but we are not using links for these in-page navigation elements.
If we consider a broader definition of what constitutes a link, we may have lots of links without context, thus rendering this SC stricter for mobile apps. Or should we also update the definition of a link context?

• paragraph: most of these navigation "links" won't be inside paragraphs
• list: we may have some list of links, but I don't see them too often.
• table: there are very few tables in mobile apps.

[JJdeGroot]

TalkBack's link activation behavior will change in the 15.1 update: https://support.google.com/accessibility/android/answer/15621045?hl=en

With TalkBack 15.1, you can open links by double-tapping them, both inside and outside of web view content. You no longer need to use the TalkBack menu to open links.

[JJdeGroot]

Discussed in today’s meeting.

20 November 2024

Source

2.4.4 Link Purpose (In Context)

Detlev In my exp links are expected to leave an app and open a browser. Is this the general expectation, and it's not made clear by WCAG2ICT

<dotjay> We are perhaps delving into a general accessibility consideration here. Links versus buttons is an issue for all platforms.

<dotjay> For mobile, perhaps it’s more about clarifying hybrid situations?

If a business wants to throw away money developing links where buttons should be, that's really their perogative

<Tim> Does it help to make notion of 'internal link' vs 'external links'?

Joe_Humbert I agree with Detlev - Google and Apple have muddied the water by allowing developers to make anything a link, and doing it themselves

I think we can - Google and Apple need to be accessible too - just because they allow devs to be bad doesn't mean they have the right to

Detlev Determinable context can be made more clear and while controls can be made better. Are there established ways of getting to the context in mobile apps?

dotjay Differences between desktop/mobile - navigating by link is possible on mobile, so getting context is possible. We don't see the "f7" display all links on mobile. What does context mean in the sens of mobile and is it different from desktop?

I think in TalkBack you can show all links

<Detlev> I don't think "Link context" means being able to bring up a list of links an the view.

<dotjay> Devlev: I meant to highlight situations where out of context versus in-context for mobile environments.

<dotjay> “Show all links” is simply an example of that. So much of the time on mobile, we are navigating into context and can discover context as the virtual cursor is moving.

<Detlev> So would that mean checking for link context would only apply to like that 1. stand lone 2. are no clear in itself?

Joe_Humbert Google can allow to show all links. iOS does tell users there is a link. That's because that's how links are created. Because we can assign the role ad hoc, it's hard. A link in an attributed string can't take you somewhere in the app because it doesn't know the context of the app

Jamie If it's about navigation, then in an app setting, buttons do this job. So perhaps the context is a little different

<Joe_Humbert> +1 to Jamie about "Button" Purpose as a consideration

<julianmka> +1 to Jamie

Detlev in most audits cases, the links are looked at as part of the context

Joe_Humbert there are limitations - in desktop the SR has a lot of flexibility. in iOS there is no in app link navigation rotor option

<dotjay> Interesting – I’d not noticed before that Link roles aren’t reachable outside of web content. How weird.

I'd need to find an app with links to check

I managed to convince my former company that links in apps where bad for business... perhaps too well

<dotjay> I believe that button purpose perhaps falls under 2.4.6 Headings and Labels as a button’s text label, and 1.1.1 for text alternative to an image button

ACTION: Research link behavior on Android and iOS -> 1. Native link in text, 2. Native link on its own, 3. Web link in WebView

ACTION: Research impact of broadening "link" to "links and buttons" or "interactive components"

<Jamie> keep in mind this is about clarity of text, for navigation purposes. If we feel that 2.4.6 covers buttons then we can leave this as links only

<Joe_Humbert> that was my problem QuintinB I would need to spin up my test app on my test Android device

ACTION: Consider linking to 2.4.6 as best-practice

<JJ> s/ 2.4.6 2.4.9

<dotjay> Re 2.4.6 – For example, https://www.w3.org/WAI/WCAG22/Techniques/general/G131

<dotjay> “The objective of this technique is to ensure that the label for any interactive component within Web content makes the component's purpose clear.“

Jamie we need to be clear that we means specifcally links or buttons

<dotjay> But I agree that it’s somewhat ambiguous and 2.4.6 does not specifically call out buttons

<Detlev> +1 to Jamie

<Joe_Humbert> on Android, you can use navigation link mod in a native app on Android, I just tested

<Joe_Humbert> link mode*

ACTION: Research link behavior on Android and iOS -> 1. Native link in text, 2. Native link on its own, 3. Web link in WebView

ACTION: Research impact of broadening "link" to "links and buttons" or "interactive components"

ACTION: Consider linking to 2.4.6 as best-practice