3 september 2024 Overleg onderzoeksbureaus

[rianrietveld]

Aanwezig

• Jeroen Hulscher - Logius (voorzitter)
• Brian Bors - Stichting Accessibility
• Jules Ernst - 200 OK
• Michiel van der Haagen - Swink
• Ronny Hendriks - Toegankelijk Online
• Rolf Meijer - WCAG.nl
• Armen Mnatsian - digitaalEHBO
• Bart Pluijmen - Cardan
• Caitlin de Rooij - Level Level
• Rian Rietveld - rianrietveld.com (notulen)
• Sander Nijsingh-Lankhorst - alverdae
• Savi Sinnema- Frameless
• Janita Top - Janita Top Webontwikkeling
• Annelies Verhelst - Digitaal Toegankelijk

Agenda / besproken

• Pagina nummering in een PDF in voorlees-software (Brian).
• Interface elementen carousel resulteren niet in statusberichten, Succescriterium 4.1.3 Statusberichten (Brian)
• Interpretatie aanpassingen bij Succescriterium 3.3.1 Foutidentificatie (Bart)
• Hoe gaan we om met tegenstrijdige normen en regels (Michiel)

Pagina nummering in een PDF in voorlees-software (Brian).

Brian: Ik stel dat pagina nummering die overgeslagen wordt door voorleessoftware en die niet overeenkomt met pagina nummering van Adobe afgekeurd dient te worden onder Succescriterium 1.1.1 Niet-tekstuele content bij PDFs. Is men het daarmee eens?

Achtergrond: Bij het beoordelen van PDF’s komt het voor dat de pagina nummering in de footer/header van elke pagina staat en deze footer/header blokken worden dan vaak als artefact aangegeven en worden dus overgeslagen door voorleesssoftware. Dat is normaal niet zo een probleem aangezien er een goed alternatief is in de vorm van de paginering van de Adobe Reader zelf.

Echter als deze twee niet overeen komen dan mist de voorleessoftware gebruiker deze informatie en kan die gebruiker niet naar specifieke pagina nummers verwijzen (in bijvoorbeeld wetenschappelijke artikelen). In dat geval zou dit afgekeurd moeten worden.

Veel organisaties doen dit in Succescriterium 1.3.1 Info en relaties omdat ze dat zien als een soort verzamelbak voor dergelijke issues van “structuur en informatie die met vormgeving duidelijk gemaakt wordt”. Maar strikt genomen klopt dat niet. Het gaat hier niet om structuur of informatie die met vormgeving van content is duidelijk gemaakt. Het gaat hier gewoon om content. Alleen gaat het hier om niet-tekstuele-content volgens WCAG, aangezien deze pagina nummering niet “door software bepaald kan worden”:
[non-text content][https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html#dfn-non-text-content].
Dus ik wil een lans breken voor het feit dat dit onder Succescriterium 1.1.1 afgekeurd zou moeten worden.

Discussie:

• Alleen benoemen als pagina nummers anders zijn in het document en in Adobe. Bijvoorbeeld als de voorpagina geen paginanummer heeft.
• Als er twee zijn, moeten ze alle twee bereikbaar zijn en de handmatige is niet decoratief
• Wat is de oplossing? Een inhoudsopgave toevoegen?
• Als ik het document zelf wordt verwezen moet deze pagina in het document zelf aanwezig zijn.
• Is het risico groot genoeg om het af te keuren als de nummering niet overeen komt.
• Als ik een pagina open, hoe kan ik een paginanummer vinden? Oplossing: pagina's overeen laten komen met de velletjes of een inhoudsopgave toevoegen.
• Op mijn Remarkable gebeurt dat met een document dat ik heb wel, de paginanummering komt daar niet overeen met de inhoudsopgave in ieder geval vanwege weirde schaling of zoiets. Ik vind het wel passen onder 1.3.1 maar denk voor 1.1.1 teveel.
• Als we dit hier gaan afkeuren, ben ik bang dat hele footers voorgelezen gaan worden om te voldoen.

Consensus:
In eerste instantie vinden we afkeuren op Succescriterium 1.1.1 te zwaar, het hangt af van de inhoud.
We moeten er verder over nadenken: Brian heeft een issue geopend op de WCAG-Audit-Discussions NL-BE GitHub repo, zodat we het hier verder over kunnen praten.

Interface elementen carousel resulteren niet in statusberichten, SC 4.1.3

Bij een carrousel staan een heen en trug knop en staan er bolletjes die de voortgang van de silides aangeven.
Als je op volgende klikt, en je naar de volgende slide gaat, verandert ook de aanduideling van huidige bolletje.
Dit is een verandering die je ziet, maar niet hoort. Is het nodig om de verandering van het huidige bolletje aan te geven met eenstausbericht.
Note: dit geldt niet voor een automatisch lopende coarossel, maar alleen anls je actief op de volgende of vorige knop klikt/drukt.

Discussie:

• is de actie zelf niet voldoende, zit de gebruiker hierop de wachten?
• Caitlin heeft gebruikersonderzoek gedaan naar zo'n carrousel en de blinde gebruiker had er geen problemen mee.
• Als je op een knop drukt ga je ervanuit dat er gebeurd wat je verwacht.
• Is er visueel een statusbericht (met tekst), dan wel altijd uitspreken.

Consensus:
Een statusbericht is te zwaar voor als de bolletjes v(of anders soort aanduiding) veranderen.
Dat je op een knop klikt en naar een andere slide gaat is verwacht gedrag, je hoeft niet aan te geven dat de weergave van de bolletjes veranderen.

Interpretatie aanpassingen bij Succescriterium 3.3.1 Foutidentificatie (Bart Pluijms, Cardan)

Zie ook de discussie op: SC 3.3.1 foutmeldingen vs instructies

Voor foutmeldingen bij formuliervelden moet worden aangegeven dat een fout is gemaakt en een instructie hoe het te goed te doen. Sommige opdrachtgevers vinden het woord "Fout" te confronterend en hebben liever, in plaats van het woord "Fout" liever een icoontje.

Vraag: is het icoontje (bijvoorbeeld een rood waarschuwingsbord) voldoende om aan te geven dat er een fout is, of moet dat er ook in tekst bijstaan? Naast de instructie, die moet er altijd bij staan in tekst.

Wat zegt WCAG:
Succescriterium 3.3.1 Foutidentificatie zegt:
Als een invoerfout automatisch ontdekt wordt, dan wordt het onderdeel waar de fout zit geïdentificeerd en wordt de fout tekstueel aan de gebruiker meegedeeld.

Succescriterium Succescriterium 3.3.3 Foutsuggestie zegt:
Als een invoerfout automatisch ontdekt wordt en suggesties voor verbetering bekend zijn, dan worden de suggesties aan de gebruiker geleverd

In de Understanding van 3.3.1 staat: users know an error exists and what is wrong.

This success criterion may help people with cognitive, language, and learning disabilities who have difficulty understanding the specific reason why a form submission failed (in cases where this is not already made obvious by the nature of the form)."

Discussie:

• Angst is dat opdrachtgevers het te confronterend vinden als je zegt "Fout" en dat liever willen vervangen door een icoontje.
• Icoon in combinatie met instructie maakt foutmelding of moet de tekst "foutmelding" zichtbare tekst aanwezig zijn.
  text alt : "foutmelding".
• Het is niet per see nodig om het woord foutmelding weer te geven.
• Bij het toevoegen van alleen een icoontje, en niet de tekst fout, ga je uit van voorkennis van de gebruiker, dat die het icoontje snapt. Een icoontje alleen (ook met alt tekst) is onvoldoende.

Vervolgactie
Bart gaat het uitwerken bij het GitHub issue SC 3.3.1 foutmeldingen vs instructies

Hoe gaan we om met tegenstrijdige normen en regels

Michiel geeft twee voorbeelden.

De eerste: Een organisatie is wettelijk verplicht om bonnetjes te publiceren.
De bonnetjes worden nu met OCR omgezet naar PDF's maar het is niet ideaal. Reflow werkt niet goed.

Discussie:

• Deze bonnetjes kunen uitgezonderd worden voor Succescriterium 1.4.5 Afbeeldingen van tekst en Succescriterium 1.4.10 Reflow.
• Reflow hoeft hier niet, net zoals tabellen en zeker niet met bonnetjes, die wil je niet in een andere vorm.
• Ik zou dit zien als inhoud van derden, en ander is het hier niet mee eens.

Consensus:
Deze PDF-bonnetjes, mits goed getagd, zijn uitgezonderd voor de Succescriteria 1.4.10 Reflow.

De tweede: Kleuren en icoontjes van kaarten zijn ontoegankelijk maar wel zo via internationale normering vastgelegd.

Kaarten zijn uitgezonderd voor WCAG-compiance.
De vraag: Wie kan spelen bij het vastleggen en toegankelijk maken van wettelijke standaarden?

Discussie

• Internationale afspraken kun je niet zomaar wijzigen.
• Eventueel alternatief bieden.
• Onderliggende vraag: welke standaarden is belangrijker.
• Kaarten zijn uitgesloten van WCAG en dat kun je in het rapport vermelden.
• Maak een tweede, wel toegankelijke, kaart.
• Zou wel pleiten voor een zo goed mogelijk alternatief, ook al is het uitgezonderd. Je kunt heus wel even iemand laten nadenken over hoe je in tekst of anderszins uitlegt welke informatie zo'n kaart geeft?
• Kaart het aan in de politiek.

De volgende vergadering is op 15 oktober 2024.

Let op: Wil je inhoudelijk op een van de onderwerpen reageren, doe dat dan via de NL-BE GitHub issues en niet bij deze notulen.