Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SC 1.1.1: Visueel zichtbare pagina nummering loop niet gelijk met die in de reader binnen een PDF #73

Open
ShadowBB opened this issue Sep 5, 2024 · 4 comments

Comments

@ShadowBB
Copy link

ShadowBB commented Sep 5, 2024

Vanuit Joke Hoogeduin en mijzelf na overleg in ons team zijn we tot het volgende vraagstuk en de volgende conclusie gekomen:

Situatie omschrijving:

Binnen een PDF staat een visuele pagina nummering in de header of footer van elke pagina. Deze is terecht aangegeven als artefact zodat deze niet opgelezen wordt door bijvoorbeeld screenreaders. Screenreaders kunnen echter wel de nummering van de PDF reader voorlezen en dat geld normaliter als alternatief voor deze als artifact aangegeven tekst.
Nu is het zo dat deze pagina nummering niet overeenkomt met de visuele pagina nummering waardoor er dus geen alternatief is voor deze visuele pagina nummering.

Gevolgen:

  • Iemand die een onderzoek verslag schrijft (academici, studenten, journalisten, scholieren, etc) moeten in hun literatuur verwijzingen de specifieke pagina noemen waarop hun citaat staat. Blinde gebruikers zijn afhankelijk van de nummering in de reader die dus gelijk moet zijn aan de visuele nummering.
  • Iemand krijgt een verwijzing van een helpdesk of mail of een docent naar een specifieke pagina binnen een PDF waar de juiste informatie die die persoon zoekt zou moeten staan. De gebruiker kijkt echter op de verkeerde pagina omdat die alleen toegang heeft tot de nummering van de reader die niet overeenkomt met de visuele nummering.

Oordeel:

  • Onder SC 1.1.1 moet er een tekst alternatief geleverd worden voor alle niet-tekstuele content. Een pagina nummering die als artefact is aangegeven telt als niet-tekstuele content binnen de definitie van WCAG "alle content die niet een sequentie van karakters is die door software bepaald kan worden..." (Mijn nadruk).
  • Zonder tekst alternatief moet dit dus afgekeurd worden onder 1.1.1.

Mogelijke oplossingen die geprobeerd gaan worden

  • Mocht men dit willen oplossen door de header of footer (of specifiek de pagina nummering) niet langer als artifact te markeren, dan veroorzaakt dit op andere SC problemen (onder andere omdat deze pagina nummering dan soms dwars door andere content heen gaat en dus invloed heeft op de betekenisvolle volgorde SC 1.3.2) Dus dit is een verkeerde oplossing.
  • De beste oplossing is mogelijk de paginalabels van pagina's aanpassen. Dit is mogelijk in het pagina miniaturen scherm aan de zijbalk (rechterkant in de nieuwe Adobe Acrobat Pro layout). Als je op de rechtermuisknop klikt op de pagina kun je kiezen voor "paginalabels..." en dit zal een scherm openen waar de stijl en beginnende paginanummer aangepast kan worden.
  • 1 van de juiste oplossingen is door simpelweg de zichtbare pagina nummering overeen te laten komen met de nummering van de reader. Dus het voorblad als 1 te tellen etc.
  • Een andere juiste oplossing is tekstueel (dus opleesbaar door voorleessoftware) op een logische plek (die andere content dus niet onderbreekt) aan te geven wat op welke pagina welke content staat (maar dan moet dus wel elke pagina genoemd zijn). Een inhoudsopgave is dus onvoldoende.
@sander-nl
Copy link

Ik ben van mening dat het alleen een probleem is als:

  • de visuele paginanummering in het document afwijkt van de paginanummering in de PDF-lezer (bijv. Adobe Reader) én
  • in de content van het document wordt verwezen naar een specifieke paginanummer.

Iemand krijgt een verwijzing van een helpdesk of mail of een docent naar een specifieke pagina (...)

Dit vind ik wat vergezocht en buiten de invloedsfeer van de documentmaker. Ik vind het de verantwoording van die helpdesk, mail of docent om duidelijk te maken welke pagina bedoeld wordt (de visueel zichtbare in het document of die van de PDF-lezer).

Een andere oplossing is dan ook om in het document niet te verwijzen naar paginanummers, maar bijvoorbeeld naar hoofdstukken, paragrafen etc. Je kunt als documentmaker in de verwijzing ook een link maken naar de plaats waarnaar je verwijst (de pagina of het hoofdstuk in kwestie).

Afkeuren bij succescriterium 1.1.1 is misschien correct, maar ik vind het makkelijker uitleggen bij 1.3.1. In de praktijk maakt het eigenlijk ook niet veel uit waar het wordt afgekeurd. Beide succescriteria zijn van niveau A.

@JokeHoogeduin
Copy link

Ik ben van mening dat het alleen een probleem is als:

  • de visuele paginanummering in het document afwijkt van de paginanummering in de PDF-lezer (bijv. Adobe Reader) én
  • in de content van het document wordt verwezen naar een specifieke paginanummer.

Iemand krijgt een verwijzing van een helpdesk of mail of een docent naar een specifieke pagina (...)

Is er een reden waarom je niet ingaat op de slechte toegankelijkheid voor blinde onderzoekers, studenten en journalisten (en anderen)?
Want die kunnen de verwijzingen naar hun bronnen en dan vooral naar citaten uit die bronnen niet zelfstandig verwerken in hun onderzoeksverslag als de visuele nummering niet klopt met die in de reader. Het kost zo'n student gewoon punten bij het maken van een scriptie als het niet klopt. En dat alleen maar omdat het document niet toegankelijk is.

En dat kan ook gewoon gaan om bijvoorbeeld een onderzoek naar taalgebruik of zoiets in de communicatie tussen gemeente en burgers in rapporten en brochures en zo. Wetenschap gaat niet altijd over wetenschappelijke teksten.

@sander-nl
Copy link

Hoi, bedankt voor je reactie.

Vooropgesteld: ik vind het ook niet handig als de paginanummeringen niet met elkaar overeenkomen, maar ik ben nog niet overtuigd dat dit een WCAG-afkeur is (zolang in het document zelf niet wordt verwezen naar een bepaalde pagina). Voldoen aan WCAG is natuurlijk niet hetzelfde als helemaal toegankelijk of gebruiksvriendelijk zijn.

Hoe een ander persoon omgaat met een document ligt naar mijn idee buiten de verantwoordelijkheid van de documentmaker. Je gaat een website toch ook niet afkeuren, omdat iemand misschien kan verwijzen naar "het rode kader links op pagina X" o.i.d.

Als je ervoor kiest om naar een bepaalde pagina te verwijzen, kun je ook duidelijk maken welke paginanummering je bedoelt. Je moet dan als verwijzende persoon in ieder geval duidelijk maken wat de paginanummer van het document is, eventueel aanvullend op de paginanummer in het document. Bijvoorbeeld: "Op pagina xii (de twaalfde pagina van het document)..." of "Op de twaalfde pagina van het document (pagina xii in het document)".

In het document Tagged PDF Best Practice Guide staat onder "3.7.2 Page numbers" het volgende:

It is semantically appropriate to have Page Label values match the visible page number.

Ik maak daaruit op dat dit niet verplicht is(, maar uiteraard wel het beste).

Ik kan het ook niet vinden als afkeurpunt in het Matterhorn Protocol.

Ook in Techniek PDF17 lees ik dat het goed is om de visuele paginanummering overeen te laten komen met die van de PDF-lezer, maar nog niet dat dit een must is (de nadruk op "should" heb ik zelf toegevoegd):

Authors should make sure that the page numbering of their converted documents is reflected in any page number displays in their user agent.

Misschien lees ik de bovenstaande bronnen verkeerd en ik laat me graag overtuigen. Dat is echter tot nu toe nog niet gelukt 🙂

@JokeHoogeduin
Copy link

Sander, het valt me op dat je opnieuw niet reageert op de gevolgen voor de belangrijkste doelgroep voor dit probleem: de mensen die moeten voldoen aan een verplicht format voor literatuurverwijzingen en voor wie fouten daarin serieuze gevolgen kunnen hebben voor hun studie of loopbaan. Jouw oplossing "de twaalfde pagina van het document" voldoet niet aan dat verplichte format binnen de wetenschappelijke wereld. En bovendien zal ook niet iedereen de digitale versie van dat document gebruiken om de informatie uit die literatuurverwijzing na te kijken. Het gebruik van zowel digitale als papieren versies is inherent aan documenten in tegenstelling tot websites.

De vergelijking met een verwijzing naar een rood kader op een website gaat daarom ook mank. Dat is niet te vergelijken met het niet kunnen voldoen aan de eisen van een beroep of studie alleen maar omdat je toevallig blind bent en je brondocumenten niet toegankelijk zijn als het gaat om de paginanummers, zelfs als ze verder wel toegankelijk zijn. Of misschien juist als ze verder wel toegankelijk zijn, want dan verwacht je dat het minst.

Wat betreft jouw bronnen: zowel de Tagged best practice guide als de Matterhorn maken deel uit van PDF/UA, wat geen verplichte standaard is voor toegankelijke PDF. Er zit natuurlijk wel overlap tussen WCAG of liever hoofdstuk 10 van de EN 301549 en PDF/UA, maar de EN is daarin leidend en PDF/UA slechts aanvullend voor zover van toepassing. Als iets niet in PDF/UA voorkomt zegt dat niets. Contrast komt er bijvoorbeeld ook niet in voor. En er staan eisen in die niet in de EN of WCAG staan. Ik ga in mijn oordeel volledig uit van hoofdstuk 10 van de EN 301549 die weer gebaseerd is op WCAG.

De PDF technieken zoals die nu online staan zijn verouderd en hier en daar ook gewoon niet in orde. Bij deze specifieke techniek zie je dat bijvoorbeeld aan de verwijzing naar succescriterium 3.2.3 Consistente Navigatie, die volgens de EN 301 549 niet van toepassing is op digitale documenten omdat dat succescriterium verwijst naar een set met webpagina's. Een digitaal document is gelijkwaardig aan één webpagina en is vrijwel nooit deel van een set. De uitzonderingen daarop zijn zo gering dat SC 3.2.3 nietig oftewel "Void" verklaard is in de EN 301549.
En het zijn slechts technieken en geen succescriteria.

Al met al sta ik nog steeds achter het voorstel van Brian en mij om de afwijkingen in de geprogrammeerde paginanummering vergeleken met de visuele paginanummering in de PDF af te keuren. En ook om dat te doen onder SC 1.1.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants