Pleidooi van een screenreadergebruiker: overdrijf niet

Bart Simons op 11/07/2018 - 3 reacties

Semantiek is belangrijk en wij hameren er nogal op dat je voor koppen, lijsten, sections enz. de HTML-elementen gebruikt die daarvoor beschikbaar zijn. Maar als je overdrijft, gaat het effect verloren. Waar semantiek een screenreadergebruiker erg kan helpen om zich te oriënteren binnen een webpagina, kan overdaad het juist onoverzichtelijk maken. Goedbedoelende ontwikkelaars kunnen het ook op andere gebieden té goed willen doen.
Wat volgt is een persoonlijke mening. Ik wil niemand aan de schandpaal nagelen, maar met de website van het Center for Education & Rehabilitation for the Blind kan ik illustreren wat ik bedoel. Deze website claimt dat ze voldoet aan WCAG2.0 niveau AAA, maar ik vraag me toch af of hun cursisten er gemakkelijk hun weg vinden.

Skip links

Een link bovenaan in de broncode die zichtbaar wordt als hij focus krijgt en toelaat om naar de inhoud te springen, heeft zeker zijn nut. De voorbeeldwebsite heeft drie van zulke skip links: de eerste brengt je naar de inhoud zoals je mag verwachten, maar daarnaast kan je ook naar de navigatie en naar de footer springen. Ik betwijfel of iemand dat laatste zou willen. De navigatie is inderdaad een beetje moeilijk te vinden, maar dat komt voornamelijk door veel andere overbodige inhoud.

Als je skip links toevoegt, geef je de mogelijkheid om sneller naar een onderdeel van de site te tabben, maar denk er aan dat elke skip link zelf ook een extra tabstop toevoegt aan het begin van elke webpagina.

Verborgen tekst

De visuele positionering van elementen op een webpagina gaat voor blinden verloren. Het kan voor screenreadergebruikers soms interessant zijn om extra informatie toe te voegen. Je kan verborgen tekst toevoegen via de clipping-techniek of je kan met aria-labels aan de slag. Kies een van beide technieken en niet allebei zoals de voorbeeldwebsite doet.

<nav role="navigation" aria-labelledby="zf--side-menu--section-heading">
<h2 id="zf--side-menu--section-heading">Side menu</h2>

Hier voegt men een verborgen kop toe boven het navigatiemenu. Die tekst herhaalt men nog eens als label bij het navigatiegebied. JAWS-gebruikers krijgen die verborgen tekst drie keer te horen:

Side menu navigatiegebied
Kop2 side menu
Lijst met zes items
Link Home
...
Link Contact
Einde lijst
Side menu einde navigatiegebied

Benoem niet elk blok

De dubbele techniek om blokken te benoemen, heeft men op de voorbeeldwebsite overal doorgetrokken. Waar je op het scherm het Facebook-logo ziet, moet een screenreadergebruiker luisteren naar zes regels informatie:

<section aria-labelledby="zf--follow-us--section-heading">
<h2 id="zf--follow-us--section-heading">Follow us</h2>
<ul>
<li><a href="">
<span class="visually-hidden">KEAT - Facebook</span>
<span aria-hidden="true" class="zf--zhong-icon zf--zhong-icon-facebook"></span>
</a>
</li>
</ul>
</section>

Vertaald door JAWS geeft dit:

Follow us gebied
Kop2 Follow us
Lijst met 1 items
Link Keat - Facebook
Einde lijst
Follow us einde gebied

Hetzelfde gebeurt voor het Accessibility panel. Ook die knop zit in een lijst van 1 item, wordt voorafgegaan door een onzichtbare kop met de tekst Toolbox en die wordt herhaald bij het aan- en afkondigen van het navigatiegebied. Ik zou zeggen dat Accessibility panel helemaal duidelijk maakt waar die knop voor dient. Het voegt echt niets toe als je die knop in een lijst en in een blok met de naam Toolbox stopt.

De link English en Greek staan ook in een navigatiegebied met als label "Language options" en met dezelfde tekst als verborgen kop erboven. Als je aan de ziende bezoeker niet vertelt dat Grieks en Engels taalkeuzes zijn, waarom zou je dat dan aan blinde bezoekers uitleggen?

Waar een verborgen kop of een aria-label wel nuttig is, is rond het kruimelpad. Al is het niet eenvoudig om daarvoor een term te verzinnen die bezoekers begrijpen. Deze website kiest voor "Location path". Bij wie doet dat een belletje rinkelen?

Oh ja, onderaan de pagina staat een blok met als verborgen kop "Complementary content (lower)".
Waar het helemaal hilarisch wordt, is bij het zoekveld:

<section role="search" aria-labelledby="zf--search--section-heading">
<h2 id="zf--search--section-heading">Search</h2>

Als je role="search" gebruikt, dan maak je van het blok een Zoekgebied. Dat is prima, maar het is dan echt niet nodig om er nog een label Search aan te hangen.

Koppen

Screenreaders bieden de mogelijkheid om van kop naar kop te navigeren of een dialoogvenster te openen met alle koppen binnen de pagina. Deze homepage heeft een prima kopniveau 1 met de tekst Home. Doordat elk blok een onzichtbare kop heeft gekregen, krijgen we een outline die helemaal niet meer overzichtelijk is en is deze navigatietechniek in de praktijk bijna onbruikbaar:

Kop2 Quick access menu
Kop2 Location path
Kop2 Toolbox
Kop2 Language options
kop2 Follow us
kop2 Search
Kop1 Center for Education & Rehabilitation for the Blind
Kop2 Side menu
Kop1 Main content
Kop1 Home
Kop2 Center for Education & Rehabilitation for the Blind
Kop2 Complementary content (lower)
Kop3 Administration and Content
Kop3 Design and Development
Kop2 Footer

Of, hoe je van een eenvoudige homepage een onbegrijpelijk kluwen kunt maken.

Live region

Als je het accessibility panel opent, dan klapt een blok uit met een aantal opties. De ontwikkelaar heeft dat blok als live region gemarkeerd: een screenreader krijgt de opdracht om de gewijzigde informatie voor te lezen. Dat moet je letterlijk nemen. Jaws ratelt:

Accessibility options Font Size: Bigger. Increase font size. Smaller. Decrease font size. Theme: Low brightness Dark Font: Sans serif Serif Bold Layout: Large print. This layout is suitable for people with low vision

Dit is geen goede toepassing van een live region. Dat er nieuwe info is verschenen, is voldoende duidelijk dankzij aria-expanded dat de waarde "true" krijgt als ik de knop activeer. Laat mij vervolgens maar rustig de opties verkennen met de pijltjes, de tabtoets of andere navigatiemogelijkheden.

Conclusie

  • Hou het simpel: bouw je template logisch op met een header, main en footer. Denk even na over de outline van de pagina en markeer de koppen met heading-elementen van het juiste niveau. Gebruik lijsten voor opsommingen (d.w.z. minstens 2 items).
  • Reserveer nav voor het hoofdmenu en eventueel een doormat. Als je het aantal navigatiegebieden beperkt, is het ook niet nodig om allerlei labels te verzinnen om ze van elkaar te onderscheiden.
  • Verborgen tekst of aria-labels toevoegen of tekst verbergen voor screenreaders, is enkel aan te raden in uitzonderlijke gevallen. Als je zelf test met een screenreader zorg dan dat je vertrouwd bent met het verwachtingspatroon van de dagelijkse gebruiker van dit hulpmiddel. Of check het even met enkele gebruikers of vraag het aan AnySurfer.
  • Als de basis goed is, zijn veel specifieke toegankelijkheidsopties niet nodig en zoals we hierboven zagen: overdaad schaadt. Ik kan het niet beter samenvatten dan met de eerste zin van dit artikel van het Mozilla Developer Network: A great deal of web content can be made accessible just by making sure the correct HTML elements are used for the correct purpose at all times

Reacties

Roel Van Gils schreef 1 maand geleden

Ik vind het een heel terecht pleidooi. Bij je voorbeeld over de verborgen koppen heb ik wel een kleine bedenking.

Je gebruikt dt voorbeeld:

<nav role="navigation" aria-labelledby="zf--side-menu--section-heading">

<h2 id="zf--side-menu--section-heading">Side menu</h2>

In de Jaws output lees je dan inderdaad twee keer 'Side menu'. Maar in een Landmarks-lijstje staat wel enkel 'Navigatiegebied' (o.i.d.) als je het landmark niet benoemt. Hierdoor moet je als Landmarks-gebruiker toch weer overschakelen naar je Headings-lijstje.

Vooral binnen webapplicaties met verschillende containers vinden sommige mensen het handiger om op basis van landmarks te navigeren dan op basis van headings (dat is dan weer handiger in lange documenten). Dat is toch mijn ervaring.

Het is dus volgens mij een kwestie van persoonlijk voorkeur. Met de `aria-labelledby`-techniek die je beschrijft, bedien je beide groepen gebruikers.

In de context van een webapplicatie, vind ik de techniek om een landmark te benoemen op basis van de eerste (al dan niet verborgen) heading (met `aria-labelledby`) trouwens vaak net een heel effectieve ingreep. Wanneer deze heading wijzigt, wijzigt de naam van het landmark namelijk mee.

Zoals in dit voorbeeld:

<header aria-labelledby="filter-heading">

<h1 id="filter-heading>Filters (5 geselecteerd)</h1>

(…)

</header>

<section aria-labelledby="results-heading">

<h1 id="results-heading>Resultaten (45)</h1>

(…)

</section>

Bart Simons schreef 1 maand geleden

Je hebt absoluut gelijk dat het om persoonlijke voorkeuren gaat. Ik ben de blog dan ook begonnen met "wat volgt is een persoonlijke mening". Maar uiteraard bedankt voor je reactie.

Omdat landmarks voor interpretatie vatbaar zijn, is er weinig consequentie overheen websites. Daarom denk ik niet dat landmark navigation snel populair zal worden.

Je zou mijn pleidooi kunnen samenvatten als: beperk het aantal landmarks, dan hoef je ze ook geen naam te geven.

In recente versies van JAWS kan een gebruiker instellen welke landmarks hij wil horen en welke niet. De huidige standaardinstelling (die 99,9% van de gebruikers niet zal wijzigen) is: van blokken met roles aside, header, footer, document, form, section, application en search wordt het begin en einde niet aangekondigd (en dus ook hun eventuele labels niet). Enkel bij article, main en nav gebeurt dit nog wel.

Uiteraard werkt niet iedereen met (de nieuwste) JAWS en zou land mark navigation geen verhaal mogen blijven van screenreaders alleen. Maar het feit dat de makers van JAWS deze instellingen hebben toegevoegd, wijst er voor mij toch op dat hun klanten hebben geklaagd over een teveel aan informatie die afkomstig is van landmarks en hun eventuele labels.

Roel Van Gils schreef 1 maand geleden

Yep, ik snap het. Ik vind het wel een beetje jammer dat Jaws (standaard) geen labels meer opleest voor de meeste landmarks. Daarmee kan je (zeker in een webapplicatie) net veel waardevolle context toevoegen. Headers en footers zijn bv. niet alleen bedoeld om bovenaan en onderaan een pagina te zetten, maar kunnen ook elders nuttig ingezet worden. Bv. voor artciles, cards etc. Nu dwingt Jaws ontwikkelaars haast om (opnieuw) verborgen headings te gebruiken, en dat is toch weer een stapje terug, lijkt me.

Reageer

De volgende HTML tags zijn toegestaan: <a> <b> <ul> <li>