1.1.1 Een <link> tag zonder ingevulde tekst "Alternate text"

[ShadowBB]

Een PDF document heeft een link tag. Binnen deze link tag staat tekst dat duidelijk maakt waar die link heen gaat maar binnen de eigenschappen van deze link tag staat geen content binnen de "Alternate text".

Dit voldoet niet aan de Matterhorn protocol (28-012): https://www.pdfa.org/resource/the-matterhorn-protocol/

Maar voldoet het wel aan WCAG 1.1.1?

[ShadowBB]

Aangezien een link met tekst er in geen niet-tekstuele-content is, is SC 1.1.1 helemaal niet van toepassing lijkt me en moet dit dus passed worden.

De reden waarom ik hier überhaupt een issue van maak is omdat de PAC software checker dit afkeurt op WCAG 1.1.1. PAC software keurt veel meer Matterhorn protocol checkpoints af onder WCAG SC waar ik van mening ben dat dat niet gepast is, en dit is de eerste in een serie van dit soort issues die ik van plan ben om aan te maken om te kijken of mijn gedachten overeen komen met hoe de rest van de inspectie instellingen hier over denken.

[MarjonBakker]

PDF is geen HTML. Als ik de specificatie lees is de techniek om een link te voorzien van een linktekst voor PDF anders dan in HTML. Alleen maar tekst plaatsen binnen een link-tag is in PDF niet voldoende om toegankelijkheid te waarborgen.

Het Matterhorn-protocol verwijst naar de de PDF/UA-standaard (ISO 14289-1:2014), die weer verwijst naar de PDF 1.7-standaard (ISO 32000-1:2008).

Een link in een pdf is een 'Annotation' (32000-01, 12.5.6.5, “Link Annotations”).

In 32000-01 staat bovenaan paragraaf '14.8.4.4.2 Link Elements' de volgende noot:

"Link annotations (like all PDF annotations) are associated with a geometric region of the page rather than with a particular object in its content stream. Any connection between the link and the content is based solely on visual appearance rather than on an explicitly specified association. For this reason, link annotations alone are not useful to users with visual impairments or to applications needing to determine which content can be activated to invoke a hypertext link."

Ik lees in 32000-01 ook dit: "Alternate descriptions are human-readable text that could, for example, be vocalized by a text-to-speech engine for the benefit of users with visual impairments."

De manier om een link een alternate description te geven is door de linktekst in de Contents te zetten.

Daarom meen ik dat je een link-tag in PDF dus moet opvatten als niet-tekstueel element en dat je met enkel een tekst binnen de link-tag niet voldoet aan 1.1.1.

[gjccopinga]

Dank Marjon voor de duidelijke uitleg en de verwijzingen.

Als ik het goed begrijp kun je het vergelijken met een stukje tekst in een HTML element, waarbij met CSS een soort transparante gif boven de tekst is gepositioneerd die interactief is gemaakt met bijvoorbeeld JS. Doordat de transparante gif positioneel op dezelfde plek staat als de tekst lijkt de tekst hier een link te zijn. Maar in praktijk is het dat dus niet. Het is gewoon tekst. Daarom moet de transparante gif ook een eigen alternatieve tekst hebben (waarschijnlijk met dezelfde tekst als de zichtbare tekst). Ook al staat dus in PDF de tekst binnen de tag is er blijkbaar toch geen relatie tussen deze tekst en de interactieve link (de annotatie). De annotatie heeft dan dus nog een eigen alternatieve tekst nodig die als echte 'linktekst' kan fungeren.

Klopt mijn interpretatie zo?

Ik kom dit probleem ook nog wel eens tegen bij bijvoorbeeld inhoudsopgaves die gegenereerd zijn. Daar lijken alle links te werken en zie je visueel teksten staan, maar wordt deze toch vaak afgekeurd op het ontbreken van een alternatieve tekst bij de annotaties van deze inhoudsopgave. Dan snap ik nu ook waar deze foutmeldingen vandaan komen en waarom dit bij SC 1.1.1 hoort.

[MarjonBakker]

@gjccopinga Ja, ik denk dat dat wel een juiste interpretatie is.

[Aircl0wn]

Heldere uitleg @MarjonBakker en mooie vertaalslag van @gjccopinga , dank beide.

[ShadowBB]

Hey Marjon,

Hartelijk dank voor je uitgebreide en snelle reactie!

Content wordt in WCAG gedefinieerd als informatie en zintuiglijke ervaring maar ze melden ook expliciet dat code die definieert hoe die content interactief is meetelt. Het is een beetje een circulaire definitie die deze discussie ingewikkeld maakt. Is een link content op zichzelf (los van de tekst) of is de tekst de content en is de code die die interactiviteit van de tekst regelt onderdeel van dat stukje content? Ik zou de tweede interpretatie handhaven maar jij handhaaft de eerste interpretatie. Naast het feit dat onder SC 1.1.1 de voor links relevante PDF technieken (PDF11 en PDF13) niet genoemd worden heb ik geen argument dat mijn interpretatie beter is dan die van jou. Aangezien deze PDF technieken nogal oud zijn en we hier mogelijk niet op willen bouwen lijkt me beide mogelijkheden verkennen het beste voor nu.

Laten we verder gaan met jou definitie dan stel je dus dat een link-annotatie content is. En daarom ook telt als "niet tekstuele content" (je typte niet tekstueel element, maar ik neem even aan dat je niet tekstuele content bedoelt, verbeter met vooral als die aanname incorrect is).

Als we er vanuit gaan dat een link-annotatie niet tekstuele content is dan heb je gelijk dat 1.1.1 van toepassing is.

Een link zou ik binnen 1.1.1 zien als een "bedieningselement" (gebaseerd op de definitie van "componenten van de gebruikersinterace" binnen 4.1.2 waar naar gerefereerd wordt). Dit zou 1.1.1 alsnog "passed" maken ondanks de aanname dat links tellen als "niet tekstuele content" aangezien er een expliciete uitzondering is voor

Echter of een link telt als een "bedieningselement" is discutabel. De definitie van componenten van de gebruikersinterace noemt wel expliciet links, maar dit is een andere term dan "bedieningselement". Misschien is het de bedoeling dat links zowel onder 1.1.1 als 4.1.2 behandeld worden (als het al de bedoeling is dat links los tellen als content)?

Als we aannemen dat links niet tellen als "bedieningselement" (en wel los tellen als "content") dan heeft het dus een tekstalternatief nodig. Een tekstalternatief wordt gedefinieerd als tekst die door software geassocieerd is met de niet tekstuele content (in onze aanname: de link-annotatie). "door software geassocieerd" wordt op diens beurt weer gedefinieerd als "tekst waarvan de locatie door software bepaald kan worden uit de niet-tekstuele content" wat ons uiteindelijk leid tot de vraag "Kunnen user-agents, met inbegrip van hulptechnologieën gebaseerd op door de auteur op zodanig wijze aangeboden gegevens bepalen (deze informatie kunnen oproepen) dat de tekst bij deze link-annotatie hoort en deze informatie tonen aan gebruikers?"

Ik zou zeggen van wel. Als ik met meerdere voorleessoftware de focus op de link plaats noemen deze allemaal de tekst van deze links, dus ik zou stellen dat ze allemaal correct deze tekst tonen aan de gebruikers gebaseerd op door de auteur aangeboden gegevens. Als er een hulptechnologie is die dit niet kan moet ik het nog tegenkomen. Heb je hier een voorbeeld van? En is dat niet uiteindelijk het doel wat we willen bereiken? Dat als een blinde gebruiker deze link op laat lezen dat de tekst die bij die link hoort ook opgelezen wordt?

Om volledig te zijn, binnen de definitie van "door software bepaald" staat ook een notitie waar staat "Bepaald uit technologiegebonden gegevensstructuren".

De PDF 1.7 specificaties zijn een "technologiegebonden gegevensstructuren" zou ik zeggen en dat brengt ons bij de kern van je argument dat de 1.7 specificaties de gegevensstructuren beschrijven en dus bepalen welke tekst bij een link hoort.

De 1.7 specificaties zien link annotations (niet link-tags, wat een specifieke structure(!) type is en geen annotatie) inderdaad volledig los van de content en dus zijn link annotations alleen onvoldoende om te bepalen welke content er mee geassocieerd is. Hier ben ik het volledig mee eens en WCAG ook (volgens onze aannames hierboven).

Vlak onder de notitie die je quote staat dan ook dat getaggde PDF's de link structuur elementen gebruiken om een associatie te maken tussen de link-annotatie en de content items wat vergelijkbare functionaliteit bied als HTML links. De voorbeeld code die daar staat heeft dan ook geen alt entry in de property list (maar het zou in theorie kunnen dat dat overgeslagen is in deze excert).

De link structure type wordt dan ook in tabel 338 van de specificaties expliciet gedefinieerd alszijnde de associatie tussen link-annotaties en de content van de inline structure element.

Ook de "Tagged PDF Best Practice Guide" van de PDF association onderschrijft dit:

"The structure element typically associates content and actionable link annotation(s)."

Ook meld dit document dat de reden waarom sommige tools de Content Entry vullen met bijvoorbeeld de Alt key is om formele PDF/UA conformatie te behalen en dat versoepeling van deze Contents key eisen verwacht wordt in UA-2.

PDF/UA eist wel dat de Contents key gevuld is, maar zegt niks over de Alt key. De Alt key vullen vult dan ook niet(!) standaard de Contents key.

Verdere (toegeven niet-normatieve en flink verouderde) hints dat het niet de bedoeling is dat PDF links structuren een alt key nodig hebben voor 1.1.1:

• 1.1.1 noemt niet de PDF technieken geassocieerd met links niet als associated techniques.
• sufficient technique PDF11 geeft 4 voorbeelden van links binnen PDF's die alle 4 niet leiden tot een link met een gevulde alt key.
• sufficient technique PDF13 leid wel to links met een gevulde alt key, maar deze wordt in de voorbeelden alleen toegepast op links die een niet identificerende linktekst hebben (namelijk de rauwe URL) en er wordt bij genoemd "The objective of this technique is to provide replacement link text via the /Alt entry in the property list for a tag. This is usually not necessary, but in some situations, additional information beyond the visible link text is needed, particularly for screen reader users." Vooral het "This is usually not necessary" lijkt me een expliciete melding dat een /Alt entry meestal niet nodig is.
• sufficient technique PDF13 staat in alle SC (2.4.4 en 2.4.9) dat deze genoemd wordt in een lijst met sufficient techniques naast PDF11.

Mijn conclusie is dus dat een alt entry key niet nodig is voor WCAG compliance in het geheel en specifiek niet nodig is voor 1.1.1. Is men het hiermee eens of ziet iemand een probleem in mijn interpretatie?

[gjccopinga]

@ShadowBB : Dank voor je lange toelichting. Af en toe lastig te volgen, maar het komt er wat mij betreft op neer dat om te voldoen aan de PDF-UA standaard er strengere eisen zijn dan het voldoen aan WCAG. Dit zie ik in meerdere tools overigens wel terugkomen, waaronder ook PAC. Daar wordt een PDF document op een aantal punten afgekeurd die niet onder WCAG vallen.

Ik kan je verhaal verder goed volgen en ben het ook wel eens met de conclusie dat we dit onder WCAG dan niet zouden moeten afkeuren. Als een PDF aan de PDF-UA standaard zou moeten voldoen dan zou het waarschijnlijk wel afgekeurd moeten worden, maar daar toetsen wij in ieder geval niet op.

[ShadowBB]

Absoluut mee eens. Voor PDF/UA zou dit wel afgekeurd worden, maar zou het vullen van de alt key dit probleem niet eens oplossen. Om dat op te lossen zou je de alt key moeten vullen en vervolgens met preflight de alt key moeten plaatsen in de content key (of volgens mij zijn er ook preflight handelingen die gewoon werkelijk de tekst die geassocieerd is met behulp van de link tag in de content key plaatsen... waardoor je de alt key helemaal over kunt slaan als je echt aan dit gedeelte van PDF/UA wilt voldoen en toch al preflight gebruikt).

[rianrietveld]

Is hier consensus over?

[ShadowBB]

Nog niet ben ik bang. Gerard en ik zijn het hier over eens, maar dat zijn slechts 2 auditors en we worden tegen gesproken door minstens 1 auditor. Ik weet dat alle auditors bij onze stichting er hier zo over denken. Gerard, is dat ook het geval bij jullie? Verder hoor ik graag nog van andere auditors van andere inspectie instellingen of meningen van niet-auditors uiteraard.

@MarjonBakker ben je het eens met bovenstaande uitleg? en @Aircl0wn wat is jou mening?

[Aircl0wn]

Eens

[ShadowBB]

Eens

@Aircl0wn Thanks! Voor de 3 dubbele zekerheid: Ben je het eens met mij of met Marjon?

[Aircl0wn]

Oh ja, dank dat is inderdaad niet helemaal duidelijk nu! Ik bedoelde jouw stuk @ShadowBB, maar het deed me gelijk nog een keer alles doorlezen.

Uitgaande van jouw response over pdf11 en pdf13 zou dan de conclusie niet moeten zijn dat het voor links met een niet-URL tekst wel nodig is om de alt key te hebben? De vraag is dan wanneer trekt je de grens tussen een leesbare URL als www.nu.nl en eentje met meer informatie/parameters.

[ShadowBB]

Oh ja, dank dat is inderdaad niet helemaal duidelijk nu! Ik bedoelde jouw stuk @ShadowBB, maar het deed me gelijk nog een keer alles doorlezen.

Uitgaande van jouw response over pdf11 en pdf13 zou dan de conclusie niet moeten zijn dat het voor links met een niet-URL tekst wel nodig is om de alt key te hebben? De vraag is dan wanneer trekt je de grens tussen een leesbare URL als www.nu.nl en eentje met meer informatie/parameters.

Juist niet. Een niet-URL tekst is al even duidelijk voor beide gebruikers. PDF13 suggereert juist dat een URL tekst onduidelijk is als deze opgelezen wordt (vooral als deze heel lang is, bijvoorbeeld "https://www.nu.nl/economie/6189371/korting-voor-reizigers-die-rustige-trein-tussen-den-haag-en-eindhoven-nemen.html" zou je dan kunnen vervangen met een alt tekst zoals "Nieuwsartikel: Korting voor reizigers die rustige trein tussen Den Haag en Eindhoven nemen.")

Ze geven geen harde grens aan aangezien dit nooit nodig is (ze definiëren geen verschillende situaties, deze sufficient technique is altijd van toepassing) maar het blijft wel een goede manier om de linktekst toegankelijk te maken als die onduidelijk zou zijn. Vandaar dat we die techniek hebben.

[ShadowBB]

Aangezien we nu 3 organisaties hebben denk ik dat we een voorlopige consensus bereikt hebben.

Mijn conclusie zou zijn:

Een PDF document met een link tag heeft geen Alt Entry nodig in de Content om te voldoen aan WCAG. Hoewel het wel aangeraden wordt om te voldoen aan PDF/UA en zeker kan helpen om onduidelijke visuele linkteksten zoals lange URL's te verduidelijken wordt deze situatie dus goedgekeurd.

[julezrulez]

Ik sta achter deze conclusie.

Aangezien we nu 3 organisaties hebben denk ik dat we een voorlopige consensus bereikt hebben.

Mijn conclusie zou zijn:

Een PDF document met een link tag heeft geen Alt Entry nodig in de Content om te voldoen aan WCAG. Hoewel het wel aangeraden wordt om te voldoen aan PDF/UA en zeker kan helpen om onduidelijke visuele linkteksten zoals lange URL's te verduidelijken wordt deze situatie dus goedgekeurd.

[rianrietveld]

Ok, ik wacht tien dagen voeg deze discussie dan toe aan de github pages

[bramd]

@ShadowBB Ik kijk nu naar een soortgelijk issue. Kun je wellicht nog vastleggen met welke hulpsoftware/pdf-readers(user agents) je getest hebt?

Verder nog een paar toevoegingen:

1. Let op bij het gebruik van content of alt (waar we volgens mij hier concluderen dat alt weinig zin heeft als je ook content kunt gebruiken) dat je geen failure veroorzaakt op Label in name door de URL te herschrijven naar andere tekst voor hulpsoftware
2. Deze repo gaat over WCAG-auditdiscussies, maar wellicht altijd goed te vermelden dat iets voor bijvoorbeeld pdf/ua wel verplicht is als er een andere conclusie voor WCAG uit een discussie komt. Sowieso is het vaak bij nieuwe projecten/implementaties aan te raden om maar voor ua te gaan, daarmee voorkom je deze discussies. Echter, zo lang pdf/ua geen wettelijk verplichte standaard is, blijft het relevant de afweging te maken of iets dat niet ua-compliant is ook op WCAG afgekeurd moet worden.

Voor de volledigheid, ik zit nog in de onderzoeksfase en sluit me (nog) niet aan bij een conclusie op dit issue :).