2.4.4 linktekst en linkcontext

[gjccopinga]

We hebben intern wat discussie over hoe streng je moet zijn bij linkteksten en linkcontext. De titel of het onderwerp van een pagina hoort niet bij de door hulpsoftware te bepalen linkcontext. Ook een h1 koptekst bijvoorbeeld niet. Maar stel je hebt een vacature pagina en onderaan staat een link met als linktekst "Solliciteer!". Moeten we dit dan afkeuren als er geen door hulpsoftware te bepalen linkcontext is die aangeeft op welke vacature er gesolliciteerd wordt. Strikt genomen denk ik wel vanuit het SC, maar het 'voelt' streng, omdat je er toch vanuit mag gaan dat iemand weet op welke pagina die zit en dus ook over welke vacature er gelezen is. Als het goed is komt die informatie namelijk terug in de paginatitel en waarschijnlijk in de h1 koptekst.

Als er meerdere vacatures op één pagina staan en dus ook meerdere links "Solliciteer", dan moeten ze van elkaar te onderscheiden zijn. In zo'n geval zou ik het wel afkeuren.

Zo komen we meer links tegen die gevoelsmatig vanuit de context van de pagina zelf wel duidelijk zijn, maar strikt genomen binnen de scope van 1.4.3 misschien afgekeurd moeten worden.

Ik ben dus benieuwd naar hoe jullie hier mee om gaan.

[Aircl0wn]

Stiekem vast een lastige.

Ben het eens dat je dit op de letter wel zou kunnen afkeuren, gezien de vrij beperkte context die hier geldt, zelfs voor individuele links, maar ik hanteer dezelfde redenering en vindt de context hier voor iedereen even 'duidelijk'. Dit zou anders inderdaad voor enorm veel linkjes gelden en dat is niet iets wat ik in gebruikersonderzoeken terugzie.

Daarnaast wil ik niet denken aan de ervaring voor een screen readers of voice control als je voor elke link context informatie moet gaan toevoegen.

ambiguous to users in general
the purpose cannot be determined from the link and all information of the Web page presented to the user simultaneously with the link (i.e., readers without disabilities would not know what a link would do until they activated it)

Deze uitzondering spreekt niet langer over context maar over de link en alle informatie op de pagina. Met die informatie kun je alsnog het doel bepalen. en geldt dat dan alleen voor de zichtbare informatie? Wat als iemand moet terug scrollen om de naam van de vacature te zien, bijvoorbeeld? Dan heb je ook geen directe visuele context meer.

Die mogelijkheid van herkennen verlies je wel meteen als er meerdere links met dezelfde naam zijn, zoals we gebruikelijk afkeuren.

Ik denk dat we het doel voorbij schieten als we dit zouden gaan afkeuren?

[julezrulez]

Ik zou een knop met de naam "Solliciteer" op een pagina waarin slechts één vacature voorkomt niet afkeuren.
Bij meerdere vacatures zou ik het wel afkeuren als elke knop met enkel de naam "Solliciteer" afzonderlijk naar het sollicitatieformulier van de bijbehorende vacature gaat.

[gjccopinga]

Ik zou een knop met de naam "Solliciteer" op een pagina waarin slechts één vacature voorkomt niet afkeuren. Bij meerdere vacatures zou ik het wel afkeuren als elke knop met enkel de naam "Solliciteer" afzonderlijk naar het sollicitatieformulier van de bijbehorende vacature gaat.

De vraag is op basis waarvan je het niet zou afkeuren. Is er (door software te bepalen) linkcontext waardoor het duidelijk genoeg is, of is er iets anders waardoor je vindt dat het niet afgekeurd hoeft te worden? Ik zou dit ook niet willen afkeuren, maar ik zou naar iets waardoor ik dit ook kan 'verdedigen'. Vanuit het succescriterium zelf is dat namelijk nog best lastig.
Je wilt eigenlijk meer 'context' meenemen dan er nu officieel ruimte is vanuit het succescriterium.

[Aircl0wn]

De linkcontext komt alleen in het spel als er meerdere linkjes met dezelfde naam zijn en er verwarring kan ontstaan.

The purpose of each link can be determined from the link text alone.

Dat is in dit soort situaties prima mogelijk omdat de wijdere context op de pagina heel duidelijk is dat dit deze vacature betreft.

[gjccopinga]

Dus, als er op een pagina maar één link staat met de tekst "lees meer" en deze staat in een zin waaruit het doel wel duidelijk blijkt, dan mag de linkcontext niet meegenomen worden, want die komt pas als er meerdere links zijn met "lees meer"? Dus dan keur je hem alsnog af? Dat klinkt niet heel logisch.

Het succescriterium geeft aan dat een linktekst op zichzelf duidelijk genoeg moet zijn. Als dat niet het geval is dan mag de linkcontext meegenomen worden. Dit heeft vooral te maken met het feit dat als je een linklijst opvraagt, of je navigeert van link naar link dat je, zonder de focus van de link af te halen toch het doel van de link wilt kunnen bepalen. Als ik op een link met alleen de tekst "Solliciteer" komt, dan is die linktekst op zichzelf niet duidelijk genoeg. Ook niet als er maar één link van is. Om het toch duidelijker te maken kan ik eventueel door hulpsoftware te bepalen linkcontext gebruiken. Als die er niets is, omdat het een losstaande link is, dan is het linkdoel dus niet duidelijk.

@AirClown: je geeft in je uitleg aan dat 'de wijde context op de pagina heel duidelijk is'. Daar ben ik het op zich mee eens, maar vanuit het succescriterium zie ik niet dat je 'die wijde context' mee mag nemen. Of zie ik iets over het hoofd? De wijde context is niet iets wat je vanuit een linklijst of vanuit het met toetsenbord navigeren 'meekrijgt' . Dan moet je wel de pagina zelf lezen of laten voorlezen voordat je bij zo'n link komt.

Nogmaals, ik ben het er mee eens dat ik het niet zou willen afkeuren, maar ik zie nog geen 'bewijs' dat dat vanuit het succescriterium (normatieve tekst) zo maar kan.

Als een enkele "lees meer" link onder een koptekst staat met en korte alinea met tekst er tussen, dan kan ik ook zeggen dat van de content op de pagina zelf (niet eens wijd, maar in de buurt) het doel van de link wel duidelijk maakt. Maar dan mag ik dat niet gebruiken. Waarom dan wel bij een link als "solliciteer" met een veel wijdere (en dus vagere?) context.

[gjccopinga]

Om het nog wat ingewikkelder te maken (sorry ;) ):

Waarom zou een linktekst "Solliciteer" die meer keer op een pagina met meerdere vacatures voorkomt wel een probleem zijn en een enkele linktekst "Solliciteer" bij een enkele vacature geen probleem zijn. Je zou eerder kunnen zeggen dat de linkteksten in beide gevallen onduidelijk zijn.
De enige reden waarom het bij meerdere links "Solliciteer" onduidelijker zou zijn is vanwege het ontbreken van door hulpsoftware te bepalen linkcontext. Want als die er wel zou zijn, zou het geen probleem zijn.
Maar is het probleem dan niet precies hetzelfde bij een enkele link waarbij diezelfde door hulpsoftware te bepalen linkcontext ontbreekt? Of mogen we dan de linkcontext ineens anders interpreteren? En zo ja, hoe dan en waarom?

Als je bij een enkele link "Solliciteer" de 'wijde context van de pagina' mee mag nemen (volgens @Aircl0wn ) om de betekenis 'duidelijk' te maken, waarom zou je dan bij meerdere links "Solliciteer" niet de 'beknoptere context' van waar de link op de pagina staat' (Onderaan een stuk content met een koptekst met de naam van de vacature en een aantal alinea's met uitleg) mee mogen nemen? Dat is krom en meten met twee maten.

Kijk vooral ook naar deze Failure techniek: https://www.w3.org/WAI/WCAG22/Techniques/failures/F63
Hier staat een voorbeeld van een "download now" link. Dit is een enkele link (er zijn er dus niet meer van). Maar deze link moet wel afgekeurd worden, omdat de informatie die nodig is om het doel van de link te begrijpen niet op een plek staat die door hulpsoftware bepaald kan worden (zonder de focus op de link te verliezen).
Waarom zou dat anders zijn voor een enkele link "Solliciteer" als er niet direct in de linkcontext bij staat waarop gesolliciteerd wordt?

[Aircl0wn]

je geeft in je uitleg aan dat 'de wijde context op de pagina heel duidelijk is'. Daar ben ik het op zich mee eens, maar vanuit het succescriterium zie ik niet dat je 'die wijde context' mee mag nemen.

Ik ga er bij een enkel link vanuit dat, als er 1 link is binnen de pagina, de overige informatie die beschikbaar is voor een gebruiker (ook een screen reader gebruiker) voldoende is om te kunnen bepalen wat de bedoeling is van deze (toegegeven) abstracte tekst.

De juistheid van die informatie is daarmee wel belangrijk. Die gebruiker komt niet op die knop zonder langs de paginatitel te gaan bijvoorbeeld, anders heb je sowieso andere problemen. Die speelt hier dus onder andere ook een rol in het scheppen van wijdere context. Dit is dezelfde informatie waarmee elke andere gebruiker het moet stellen, alleen is de manier van opname van die kennis anders. Er wordt hier dus niemand benadeelt.

Door dit soort algemene informatie zouden we stellen dat de tekst op zichzelf (even) duidelijk is voor iedereen dat je hiermee solliciteert of meer wilt lezen over het betreffende onderwerp.

Waarom zou een linktekst "Solliciteer" die meer keer op een pagina met meerdere vacatures voorkomt wel een probleem zijn en een enkele linktekst "Solliciteer" bij een enkele vacature geen probleem zijn. Je zou eerder kunnen zeggen dat de linkteksten in beide gevallen onduidelijk zijn.

In en situatie met meerdere links kun je visueel onderscheid maken en daarmee een vaak stellige aanname doen dat knop A bij onderdeel A hoort. Maar programmatisch kun je dit onderscheid niet bepalen, in ieder geval niet zonder dat men extra moet gaan zoeken. Dat is de extra barrière die je met een linkcontext wilt voorkomen. Bij een enkele link is die linkcontext niet noodzakelijk om de betekenis te duiden, want er is geen verwarring met andere knoppen.

Het opvragen van lijsten met links is een mooie bijkomstigheid. Fijn dat dit in de understand docs wordt aangehaald, maar dit ondersteunen is niet het hoofddoel van de SC. Doel is is het voorkomen van extra werk voor screen reader gebruikers. Als het om 1 link in die lijst gaat zit daar mijns inziens dus geen verschil. Dit opvragen is eigenlijk al een actie die out of context plaatsvindt, want in die lijst heb je ook niet de verdere context zoals beschreven in de UD beschikbaar. Dan zou je daar dus nooit op mogen leunen en mogen we alleen links maken met omschrijvende teksten?
wat ik overigens verder niet verkeerd zou vinden, maar ik kijk hier naar wat is baseline nodig.

Overigens moet je het gebruik van deze lijstfunctie ook niet overschatten, denk ik. Ik heb tijdens user research sessies het afgelopen half jaar met 24 mensen met verschillende screen readers iemand dit welgeteld 1x zien gebruiken. Navigeren op headings doet men aanzienlijk meer.

Kijk vooral ook naar deze Failure techniek: https://www.w3.org/WAI/WCAG22/Techniques/failures/F63

Ik zou deze best eens willen aankaarten.

Bij het eerst voorbeeld vind ik het erg kleinerend voor de gebruiker om te stellen dat, als dit om een enkele link gaat, ze niet in staat zouden zijn om de verdere inhoud van de pagina te begrijpen. We gaan dan programmatisch een probleem oplossen onder een cognitief niveau aanname, wat dan net zo goed voor ieder ander persoon met visie ook zou kunnen gelden.

Voorbeeld twee valt sowieso af wat mij betreft, want hier hebben ze het over een layout table (overigens niet zo aangemerkt in de code sample) dus de structurele informatie is hoe dan ook al niet aanwezig. Een screen reader gebruiker merkt hier niet eens dat ze in een tabel zitten. Als het een normale table was geweest mist de tabel structurele informatie in headers. Die zouden die contextuele informatie alsnog kunnen doorgeven. Het is dan mogelijk nog een probleemsituatie omdat de info en de knop op twee verschillende rijen staan, maar hangt dus van de header info af.

[gjccopinga]

Ik speel hier even de 'advocaat van de duivel' om je redenatie te kunnen volgen. Ik lees namelijk best nog wel wat aannames die buiten de uitleg van het succescriterium (zowel normatief als bij understanding) staan. En dat kan, als we daar met elkaar afspraken over maken.

Ik begrijp dus dat er twee soorten context zijn.

1. De linkcontext zoals beschreven in het succescriterium. Deze is alleen van toepassing als er meerdere links met dezelfde tekst op de pagina staat waardoor er onduidelijkheid kan ontstaan.
2. Voor 'enkele' links (een linktekst die maar één keer voorkomt op de pagina) mag je ook een wijdere context gebruiken. Binnen de wijdere context valt onder andere de pagina titel en zoals ik het begrijp ook eigenlijk de hele content van de pagina, omdat er vanuit gegaan wordt dat voordat iemand bij een link komt alle content die ervoor staat al gelezen is. In ieder geval de paginatitel, maar eigenlijk ook de rest van de pagina.

Op basis hiervan zou je dus een link "lees verder" moeten goedkeuren als er maar één zo'n link op de pagina staat? Als de content erboven bijvoorbeeld meer context geeft waar verder over gelezen kan worden.

Op basis van bovenstaande hoe zouden jullie de volgende links beoordelen:

1. De link "Clear all" op pagina https://www.w3.org/events/. De titel van de pagina is "Events", net als de h1 op deze pagina. Dit is een enkele link. Op basis van de linkcontext van het succescriterium zou je deze moeten afkeuren? Want het is niet duidelijk wat je "cleared"? Wis je de events? Of wis je wat anders? Je weet alleen dat je ze allemaal wist, maar nog niet wat.
   Maar dat zou dus uit de context van de hele pagina moeten vallen. De context die niet beschreven staat in het succescriterium.

2. De links met de jaartallen "2023", "2022" op pagina https://www.w3.org/about/diversity/. Op basis van het succescriterium zelf zou ik deze afkeuren, want er is geen door hulpsoftware te bepalen linkcontext aanwezig. Maar, omdat deze links maar één keer voorkomen mag je de 'wijdere' context meenemen. De pagina titel helpt alleen niet veel in dit geval. Alleen de koptekst die er direct boven staat wel ("Annual reports"). Ik zou deze links afkeuren, maar dat hoeft dan dus niet?

In de eerste alinea van het Understanding document staan twee 'use cases' waar het succescriterium voor bedoeld is:

1. Assistive technology has the ability to provide users with a list of links that are on the Web page. Link text that is as meaningful as possible will aid users who want to choose from this list of links.
2. Meaningful link text also helps those who wish to tab from link to link.

Hoe gaan we dan om met beide bovenstaande 'use cases' als we ook een wijdere context mee mogen nemen. Daar is geen sprake van in beide use cases. Hier is ook geen sprake van enkele links of links die dezelfde linktekst hebben.

Oftewel, ik begrijp heel goed wat @Aircl0wn bedoelt en dat is ook iets wat ik graag zou willen toepassen. Maar ik merk dat dat vooral een gevoel is wat ik deel, maar niet iets wat ik uit het succescriterium en de Understanding 'hard' kan maken. Zeker niet met de failure techniek die ik eerder heb aangehaald. Of zie ik toch echt iets over het hoofd?

[rvantonisse]

Het gaat om het kunnen onderscheiden van links en wat het vervolg is, zoals @Aircl0wn aangaf. Het doel van een vacature pagina is om hierop te kunnen solliciteren. Als er dan 1 link is met de tekst "solliciteren". Lijkt me voldoende met of zonder directe linkcontext.

Daarnaast zie ik ook nieuwe / meer situaties waarbij de linkcontext is uit te breiden: binnen een article, binnen een lijst of groep met een naam, in een koptekst. Screenreaders pakken nieuwe tech reactief op. In de wcag staat die linkcontext ook in een "example" genoemd, wat het informatief maakt. Er is dus meer mogelijk en staat niet vast met genoemde voorbeelden.

Een Lees verder link kan dan ook prima toegankelijk wezen.

Ik zeg ook voldoende.

[Aircl0wn]

Het komt neer uit de interpretatie van "uit de linktekst alleen". Nemen we de heel letterlijk en kijken we echt alleen naar die "accessible name" als het ware? Of is de betekenis ervan duidelijk, omdat er geen verwarring kan ontstaan?

We hanteren (onbewust?) dezelfde gedachtegang toch als we een "nieuws" of "blog" of "contact" link tegenkomen? Volgens mij keurt niemand die af? Binnen de context van de site is duidelijk dat deze (hopelijk) naar de betreffende pagina binnen de site gaan.

De voorbeelden die je aanhaalt

De link "Clear all" op pagina https://www.w3.org/events/.

Ik zou zeggen dat het doel hier voor iedereen onduidelijk is? Uit ervaring kan ik een inschatting maken over wat de link doet, maar de visuele context draagt daar mijns inziens weinig aan bij. Ik zie dit zo als een opmerking voor me in onderzoek: "ik ga hier niet op klikken, geen idee wat het precies zal doen". Het een slechte tekst, maar voor iedereen. Wellicht dus uitgesloten?

De links met de jaartallen "2023", "2022" op pagina https://www.w3.org/about/diversity/.
Of voorgaande headings binnen de link context vallen lopen al jaren discussies. Er is technisch geen reden waarom dit niet zou kunnen. Een screen reader kan naar de vorige heading navigeren en zou deze dus ook kunnen voorlezen zonder die navigatie stap. De officiele verwijzing in het SC geeft geen uitsplitsing hiervoor, alleen de UD, maar technisch is het prima mogelijk een programmatisch te bepalen relatie te hebben.

Patrick haalt hier de vergelijking al aan met landmarks onder 2.4.1, welke in theorie ook voor keyboard users heel nuttig zouden zijn om te navigeren, maar nu alleen voor screen readers eigenlijk werken. En er zijn extensions voor browsers die deze functionaliteit toevoegen.

w3c/wcag#1097

In de eerste alinea van het Understanding document staan twee 'use cases' waar het succescriterium voor bedoeld is:
Assistive technology has the ability to provide users with a list of links that are on the Web page. Link text that is as meaningful as possible will aid users who want to choose from this list of links.
Meaningful link text also helps those who wish to tab from link to link.

Ik vind het eerste voorbeeld zoals eerder gezegd persoonlijk helemaal niet zo sterk. Die lijst is al een stap extra uit de originele context. De doelgroep is hier vele malen breder dan dit. De volgende use case zinspeelt daar al op, al heb ik hier nog steeds de indruk dat hij geschreven is vanuit de gedachte van een screen reader gebruiker. Andere hebben namelijk wel een visuele context, al dus die hebben meer info.

Mijn grootste probleem met deze voorbeelden en de linktext discussie is dat het oplossingen in de hand werkt die afbreuk doen aan de ervaring van anderen, met name mensen die voice control gebruiken (zoals ondergetekende, is dat belangenverstrengeling? 🙃 ).

Door verborgen teksten, aria-labels of aria-describedby constructies worden nieuwe namen opgebouwd, die er vervolgens voor zorgen dat deze doelgroep weer door andere hoepels moet springen om ze te activeren. Dus, of een screen reader springt naar een voorgaand stukje info of een voice user is twee commando's verder om een link te activeren. Linksom of rechtsom is iemand de dupe. De enige echte oplossing daar is dan dus eigenlijk eenduidige zichtbare link tekst.

Oftewel, ik begrijp heel goed wat @Aircl0wn bedoelt en dat is ook iets wat ik graag zou willen toepassen. Maar ik merk dat dat vooral een gevoel is wat ik deel, maar niet iets wat ik uit het succescriterium en de Understanding 'hard' kan maken. Zeker niet met de failure techniek die ik eerder heb aangehaald. Of zie ik toch echt iets over het hoofd?

Zoals je zegt, het is niet direct hard te maken. En ook met het ondersteunen van wijdere context hangt het nog steeds heel erg van die inhoud af. De discussies hierover lopen zoals gezegd al jaren. In het allereerst voorbeeld is hij vin mijn interpretatie duidelijk, maar bij dat hoeft niet altijd zo te zijn. Ik probeer er in mijn beoordelingen een overwogen keuze in te maken, en die te onderbouwen in mijn omschrijvingen.