Opvallend (on)toegankelijk: tekst herschalen of vergroot weergeven

In mijn vorige artikel nam ik je mee in succescriterium 1.4.12, over tekstafstand. Dit keer praat ik je helemaal bij over succescriteria 1.4.4 en 1.4.10, die gaan over het vergroten van tekst!

WCAG 1.4.4 – Herschalen van tekst

Het herschalen van tekst helpt mensen met visuele beperkingen om de content beter te kunnen lezen. Dit criterium stelt dat tekst tot 2 keer vergroot moet kunnen worden zonder hulptechnologieën en zonder verlies van content of functionaliteit.

Denk bij verlies van content aan tekst die buiten beeld valt of overlapt. Decoratieve afbeeldingen mogen verdwijnen, zolang informatieve content zichtbaar blijft.

Waar het voor dit succescriterium nog geen probleem is als er bij de vergrote weergave horizontaal gescrold moet worden om alle content te kunnen zien, is dat voor succescriterium 1.4.10 niet meer toegestaan.

WCAG 1.4.10 – Reflow

Dit succescriterium gaat erom dat gebruikers content kunnen vergroten zonder dat ze dan van links naar rechts moeten scrollen om alle content te kunnen bekijken. Dat zou namelijk veel fysieke en cognitieve inspanning kosten: je raakt makkelijk de draad kwijt en het lezen wordt vermoeiend.

→ Heel eerlijk, als “Links Rechts” van Snollebollekes op komt, denk ik ook ‘haal me hier weg!!’.

Bij het uitvergroten van de tekst moet alle content zo worden ingedeeld dat het in één kolom past, zodat scrollen in meer dan één richting* niet nodig is. Dat noemen we ook wel “reflow”. Hierbij mag dan ook weer geen verlies van content of functionaliteit optreden.

* Met meer dan één richting wordt bedoeld dat je wel in één richting moet kunnen scrollen om verder te lezen. In onze taal is dat van boven naar beneden. Wat niet mag, is dat je daarnaast ook nog in een tweede richting moet scrollen. Eerder had ik het over scrollen van links naar rechts, maar dat voorbeeld geldt dus alleen voor talen met een horizontale leesrichting. In die gevallen is horizontaal scrollen bij een vergrote weergave niet toegestaan. In talen die verticaal worden gelezen, geldt dit juist voor verticaal scrollen. Daarom dat de officiële WCAG Understanding de specifieke scrollrichtingen in het midden laat en alleen spreekt over het aantal dimensies.

Dit succescriterium gaat erom dat gebruikers content kunnen vergroten zonder dat ze dan van links naar rechts moeten scrollen om alle content te kunnen bekijken. Dat zou namelijk veel fysieke en cognitieve inspanning kosten: je raakt makkelijk de draad kwijt en het lezen wordt vermoeiend.

→ Heel eerlijk, als “Links Rechts” van Snollebollekes op komt, denk ik ook ‘haal me hier weg!!’.

Bij het uitvergroten van de tekst moet alle content zo worden ingedeeld dat het in één kolom past, zodat scrollen in meer dan één richting* niet nodig is. Dat noemen we ook wel “reflow”. Hierbij mag dan ook weer geen verlies van content of functionaliteit optreden.

* Met meer dan één richting wordt bedoeld dat je wel in één richting moet kunnen scrollen om verder te lezen. In onze taal is dat van boven naar beneden. Wat niet mag, is dat je daarnaast ook nog in een tweede richting moet scrollen. Eerder had ik het over scrollen van links naar rechts, maar dat voorbeeld geldt dus alleen voor talen met een horizontale leesrichting. In die gevallen is horizontaal scrollen bij een vergrote weergave niet toegestaan. In talen die verticaal worden gelezen, geldt dit juist voor verticaal scrollen. Daarom dat de officiële WCAG Understanding de specifieke scrollrichtingen in het midden laat en alleen spreekt over het aantal dimensies.

**Bron afbeelding

Hoe onderzoek ik deze succescriteria?

Als ik een website onderzoek op deze succescriteria, stel ik de schermresolutie in op 1280 bij 1024 pixels.

• Voor 1.4.4 zoom ik in naar 200%;

• Voor 1.4.10 zoom ik in naar 400%.

Voor apps test ik succescriterium 1.4.4 bij een maximale lettergrootte/tekstgrootte.

Daarna check ik alle informatieve content in beeld blijft en of alles blijft werken.

De weergave hoeft overigens niet precies hetzelfde te blijven. Het is bijvoorbeeld helemaal prima als het navigatiemenu verandert in een “hamburgermenu” (te herkennen aan het icoon van drie horizontale strepen), zolang deze goed werkt. Het gebeurt wel eens dat niet alle menu-items in beeld gebracht kunnen worden, of dat er problemen optreden met de focusvolgorde bij toetsenbordnavigatie. Dit wordt dan bij de betreffende succescriteria afgekeurd.

Uitzonderingen en aandachtspunten

• Succescriterium 1.4.4 geldt niet voor ondertiteling in video’s en afbeeldingen van tekst.

• Voor succescriterium 1.4.10 geldt een uitzondering voor content waarbij een tweedimensionale weergave vereist is voor het gebruik of de betekenis. Als dat soort informatie in een smallere kolom geplaatst zou worden, zou de betekenis verloren gaan. Voorbeelden zijn grafieken, tabellen en carrousels. Hierbij is het wel zo dat de inhoud van één onderdeel, dus bijvoorbeeld één tabelkolom, in één schermbreedte te zien moet zijn. Je mag dus wel tussen de tabelkolommen horizontaal moeten scrollen, maar als je vervolgens binnen een tabelkolom alsnog horizontaal moet scrollen om de inhoud te kunnen lezen, is dat niet goed. Tweede aandachtspunt is dat deze uitzondering alleen voor deze onderdelen op de pagina geldt en dat de rest van de pagina dus wel gewoon in één kolom gepresenteerd moet worden. Bij een tabel kan dit bijvoorbeeld door een aparte scrollbalk voor de tabel te maken.

• Soms kan je op een website zelf de tekst groter of kleiner maken, dan zie je bijvoorbeeld bovenaan één of meerdere letters “A” waarmee je de tekstgrootte kan aanpassen. In theorie mag dit ook gebruikt worden om aan succescriterium 1.4.4 te voldoen. Alleen zien we vaak dat het hiermee niet mogelijk is om de tekst echt tot 200% te schalen. Dan is dan niet genoeg.

• Ik zie bij het uitvergroten van de weergave vaak dat er zogenoemde “sticky” elementen zijn die een groot deel van de weergave bedekken. Denk aan knoppen voor chats, een menubalk, et cetera. Zolang alle content goed in beeld gebracht kan worden, levert dat nog niet meteen een probleem op. Maar dit is wel iets om op te letten.

Veelvoorkomend probleem: lange woorden

Bij beide succescriteria wordt het afgekeurd als er verlies van content is, doordat een woord te lang is om op het scherm te passen. En dat zie ik stiekem nog regelmatig fout gaan. Het woord valt dan deels buiten beeld (1.4.4/1.4.10), óf er ontstaat een horizontale scroll wat dus niet is toegestaan (1.4.10).

Onlangs onderzocht ik nog een website waarbij alles voor deze succescriteria perfect verliep. Totdat ik, heel ironisch, op de toegankelijkheidspagina kwam. Hier was het woord “Toegankelijkheidsverklaring” te lang, waardoor er op de hele pagina een horizontale scroll kwam bij de vergrote weergave en dit dus het enige puntje was wat ik moest afkeuren voor succescriterium 1.4.10.

Tip: lange woorden afbreken

Met CSS kun je woorden laten afbreken. Met &shy bepaal je zelf waar dat gebeurt. Dit vraagt een kleine CSS-aanpassing. Meer over het gebruik van &shy en correcte woordafbreking met HTML en CSS is te lezen in dit code-voorbeeld op CodePen.io.

... En nog véél meer

Ik zou je nog veel meer kunnen vertellen over deze succescriteria, maar hopelijk geeft dit artikel je een goede introductie om je websites en apps toegankelijker te maken voor iedereen.

Vragen?

Heb je inhoudelijke vragen over dit onderwerp of andere zaken omtrent WCAG? Mail dan naar support@cardan.com. Heb je een specifiek onderwerp dat je graag wilt zien terugkomen? Stuur ons dan een e-mail naar contact@cardan.com.