Link purpose (2.4.4 and 2.4.9) "ambiguous to users in general" is self-defeating

[patrickhlauke]

On their face, 2.4.4 Link Purpose (in Context) and 2.4.9 Link Purpose (Link Only) want to ensure that links are sufficiently descriptive of their purpose/the content that they link to (with 2.4.4 allowing for context, and 2.4.9 making the requirement of the link itself in isolation). From the understanding documents, this is about aiding users in being able to decide whether or not they want to follow those links. It mentions users with motion limitations, cognitive disabilities, and visual impairments. All good so far.

However, the "except where the purpose of the link would be ambiguous to users in general" exception for both SCs actually completely guts most of the intent here. if the page itself doesn't provide any more clues/explanations about what a link does, it arguably is "ambiguous to users in general". There's a certain circular logic at work here that if a link's text does not describe its purpose accurately/sufficiently, and there is no other context provided anywhere else on the page, then you can't really say "this link should be more descriptive", because by the very fact that it isn't, it's "ambiguous to users in general".

In practice then, what this SC really boils down to, is: if there's other content in the page (be it other text, or layout that suggest some kind of relationship, or use of color, or anything else - which may also fail other SCs, like 1.3.1 or 1.4.1) that does provide more information about the purpose of a link, it needs to either be associated with / programmatically determinable (such as being part of the same paragraph) for the link (for 2.4.4) or even be included/associated as part of the link itself (for 2.4.9). And for 2.4.9, it's even acceptable to use visually hidden/AT only solutions. So really, the only users who really benefit from these SCs, when there is additional information/description in the page, are AT users. The SCs, in these cases, can be satisfied while still not helping users with limited motion or cognitive disabilities at all.

And of course, if there isn't anything else in the page, then the link doesn't need to be descriptive (of its purpose, or what it links to) because it's then by definition "ambiguous to users in general". So the whole rationale of the SCs (to make sure it's easy for users to work out what a link does/where it points to) gets defeated outright.

Or am I missing something?

Long story short: these SCs only have any real bite when there is unarguably further context provided in the page already. And they only really help AT users.

[patrickhlauke]

extreme example: a page with just a giant "click here" link? passes 2.4.4 and 2.4.9, as it's ambiguous to all users.

less extreme example: a page about topic X, which then has a random non-sequitur link that says "click here" and links to...whatever, even stuff not related to X...passes 2.4.4 and 2.4.9, as it's ambiguous to all users.

so the purported "this aims to help users with limited mobility, cognitive disabilities, etc" also falls by the wayside...

[patrickhlauke]

also, related topic just for 2.4.4 https://github.com/w3c/wcag/issues/1097

[Jookia]

I've always read this as 'intentionally ambiguous' in cases where you want to confuse users. But confusing users seems kind of anti-accessibility in general, and you could always do something like 'surprise page' as the link

[bruce-usab]

The most obvious example of intentional ambiguity is a game, i.e., one is following links just to be amused, and maybe the link clue/hint makes sense after the fact.

@patrickhlauke, I do not agree that the exception for both SCs actually completely guts most of the intent here since that sort of gamification design choice should be readily apparent.

SC 2.4.4 and 2.4.9 are aimed at read more and click here links where the visual correlation is obvious, but there is no programmatic association. I still encounter those all the time, so it seems to me the SC continue to have utility.

[bruce-usab]

extreme example: a page with just a giant "click here" link? passes 2.4.4 and 2.4.9, as it's ambiguous to all users.

Yes, agreed.

less extreme example: a page about topic X, which then has a random non-sequitur link that says "click here" and links to...whatever, even stuff not related to X...passes 2.4.4 and 2.4.9, as it's ambiguous to all users.

Do you have live example of this one? I am not quite imagining the real world implementation.

so the purported "this aims to help users with limited mobility, cognitive disabilities, etc" also falls by the wayside...

I agree that this SC mostly is for people using AT. But that does include people with limited mobility who use voice recognition. The help for people with cognitive disabilities is reasonable since more explicit link text would be better than not.

[patrickhlauke]

Do you have live example of this one? I am not quite imagining the real world implementation.

One thing I came across while reviewing an audit today, which sparked this whole train of thought to begin with: a page for a particular university has a link "University X finance", but the link itself went to a very generic page, not on the university site itself, which encompassed various bits of financial information, including some generic information for students. The auditor flagged this as a failure of 2.4.4 since the link text itself, and the surrounding context, weren't clear enough about what the link was pointing to. But I changed this to a pass, as it's equally ambiguous to all users.

Similar cases in the past: links that, as link text, had just the full URL as text. Auditors would flag those as inappropriate link text, but they're equally awkward/ambiguous to all users.

SC 2.4.4 and 2.4.9 are aimed at read more and click here links where the visual correlation is obvious, but there is no programmatic association. I still encounter those all the time, so it seems to me the SC continue to have utility.

Yes, the "read more" and "click here" links are problematic, and these SCs do tackle those. I'm not disputing that particular scenario. But beyond that, this SC - in my mind anyway - doesn't actually tackle many other cases where it's not clear from links alone what exactly the user is going to go to when they follow the link.

I agree that this SC mostly is for people using AT. But that does include people with limited mobility who use voice recognition.

Look at the "benefits" from the understanding documents however. This is not conveyed. It gives a different impression to me

https://www.w3.org/WAI/WCAG21/Understanding/link-purpose-in-context.html#benefits

This Success Criterion helps people with motion impairment by letting them skip Web pages that they are not interested in, avoiding the keystrokes needed to visit the referenced content and then return to the current content.

And, in the case of 2.4.4, how would having a link as part of a context (like a paragraph) (the commonly accepted solution here) help voice recognition users? And if visually hidden text for added context in the link itself is permitted for, say, 2.4.9, how does that help these users?

The help for people with cognitive disabilities is reasonable since more explicit link text would be better than not.

And yes, the benefits say:

People with cognitive limitations will not become disoriented by extra navigation to and from content they are not interested in.

But that's my point, these SCs do not mandate more explicit link text, in their current wording. They require that if there is information available in the page that gives more clues/hints about what a link is, then they need to be associated/readily available from the link. If the page does not have anything that would provide, say, a sighted mouse user with more information, then the links also won't be required to provide any more specific information about their purpose, since they'll be...ambiguous for all users.

So, as I say in the thread opener: these SCs only have any real bite when there is unarguably further context provided in the page already. And they only really help AT users.

And that seems to be at odds with the (original) intention (still expressed in the understanding documents) that hints at many other benefits that are, I'd argue, simply not there when following the normative requirements of this SC.

[mraccess77]

It might be worth discussing that we also have SC 2.4.6 Headings and Labels that might cover labels for things like buttons or perhaps links. This is always something I struggle with quantifying when a label describes the purpose or not. I started to make a decision tree. Again for SC 2.4.6 I believe you could also take context into account such as grouping, heading, etc. But for better consistency in flagging issues we need more agreement on what can be taken into account. As I write this in github I see the submit button is titled "comment" -- is that even clear as the purpose of the button is not to create a new comment but submit my comment?

[alastc]

I'm picking this up as the crux:

Yes, the "read more" and "click here" links are problematic, and these SCs do tackle those. But beyond that, this SC - in my mind anyway - doesn't actually tackle many other cases where it's not clear from links alone what exactly the user is going to go to when they follow the link.

So presumably there are bad links that could be caught by removing that exception, but would it also then catch links which are not problematic?

[bruce-usab]

One thing I came across while reviewing an audit today, which sparked this whole train of thought to begin with: a page for a particular university has a link "University X finance", but the link itself went to a very generic page, not on the university site itself, which encompassed various bits of financial information, including some generic information for students.

Okay, thanks. That is a clarifying example for me.

The auditor flagged this as a failure of 2.4.4 since the link text itself, and the surrounding context, weren't clear enough about what the link was pointing to. But I changed this to a pass, as it's equally ambiguous to all users.

I agree with passing this. If you can mention it in your audit report, that is always useful.

Similar cases in the past: links that, as link text, had just the full URL as text. Auditors would flag those as inappropriate link text, but they're equally awkward/ambiguous to all users.

I think that is a reasonable thing to flag as an internal practice/process. I do not think it fails against any particular SC.

[patrickhlauke]

the crux of what i'm saying is: those "benefits" should be rewritten, as they do not reflect the actual reality of what the SC demands/achieves.

these SCs really only help AT users first and foremost. they does not necessarily help keyboard users/limited mobility users, and they does not necessarily help users with cognitive disabilities - as they do not, in themselves, ensure that links are any less ambiguous/cryptic than what they would normally be.

to a limited mobility/COGA users (without additional AT) it makes no difference if a link has a programmatically determinable context (per 2.4.4) that provides further information or not. in fact to these users, it likely makes little difference. and if 2.4.9 can be passed even with hidden/invisible content, that SC also doesn't guarantee any more benefit to these users.

so i'd propose to take a good hard look at the understanding docs for 2.4.4 and 2.4.9, and rewrite the intent/benefits to reflect what the SCs actually mandate. and sure, add extra notes saying that of course if link text is made to be more explicit for all users in general (and visible, not just programmatically associated/hidden), it can benefit all users. but that goes beyond what the SCs normatively demand/achieve.

the normative requirement of the SCs is fine, and does help an important user group, so i'm not advocating that the SCs themselves (or the exceptions) should be changed. just that it then doesn't claim in the understanding docs to do more than it actually does - as THAT part is confusing to auditors who then mistake these SCs as requiring more than they actually do.

[mraccess77]

I agree at urls would not fail and that ambiguous links such as "finance page" would pass 2.4.4.

[detlevhfischer]

Proposed WG response: Thank you for your comment. We have updated the 2.4.4 Understanding text to focus on the benefits for users of assistive technologies. Here is a pull request: https://github.com/w3c/wcag/pull/1164

[patrickhlauke]

Lovely stuff. #1164 looks good, thanks @detlevhfischer and rest of WG

[patrickhlauke]

Can I also suggest though that https://www.w3.org/WAI/WCAG21/Understanding/link-purpose-link-only.html may need a bit of clarification - as, if it's ok to use something like aria-label (as per the first sufficient technique), it also primarily benefits AT users. so perhaps the benefits need qualifying/prefixing somehow, and a new one specifically for AT users added)

[detlevhfischer]

@patrickhlauke in a branch (see PR https://github.com/w3c/wcag/pull/1166 ) I have added a note to the Understanding text of 2.4.9 that flags techniques that offer value only to non-visual users.

[patrickhlauke]

stumbling across this again ... any movement on it?

[alanfluff]

TL;DR I'm stunned SC 2.4.4 does not let me fail terribly written links.

Was really quite surprised upon re-reading 2.4.4 to find that apparently I cannot fail a link whose purpose cannot be determined from the link text alone… due to the surprising and disappointingly worded ambiguous to users in general text. So surprised I just Googled ambiguous to users in general and ended up here.

I am glad to find I am in esteemed company in finding this really odd, but sad that it seems the SC is still "wrong".

Full disclosure: I lazily only read the opening item by @patrickhlauke and one or two other small points, so apologies if I missed something. But if I didn't then "hear hear!" - I hope this SC changes.

[stes-acc]

This seems to me being a usability discussion in disguise. All users should benefit, so reccommending patterns beneficial for all users should be prime.