Aandachtspunt voor ontwikkelaars: Toegankelijkheid

From mediawiki.org
This page is a translated version of the page Accessibility guide for developers and the translation is 100% complete.
Languages:

Toegankelijkheid is belangrijk voor onze gebruikers. Wij kunnen het verbeteren door een paar simpele regels in acht te nemen. Het is moeilijk te beschrijven omdat er geen vaste regels of algemeen aanvaarde standaarden zijn die consistent werken en voor alle gebruikers hetzelfde uitpakken. Het is niet de bedoeling om hier een discussie te houden over een mogelijk probleem met de toegankelijkheid van de MediaWiki. We proberen het te beperken tot technische keuzes en dingen die u moet doen of juist niet moet doen om problemen met de toegankelijkheid te voorkomen.

Voor het ontwikkelen van code, zouden dit de algemene regels kunnen zijn:

  • Probeer onze gebruikers erbij te betrekken
  • Probeer de toegankelijkheid goed te houden, maar bedenk wel dat het zonder goede functionaliteit minder belangrijk is.
  • We proberen een aanpak te vinden van voortdurende verbetering boven die van elegante afbraak.
  • Implementeer zaken die technisch klinken

Hoe bereikt men een goede toegankelijkheid?

Enkele belangrijke concepten waar u aan moet denken.

Toegankelijkheid kan op meerdere manieren gemeten worden

Overweeg het volgende:

  • Zorg dat de tekst begrijpelijk en logisch is en netjes wordt weergeven, maak het ook niet te moeilijk.
  • Gebruiker kunnen een screen-reader gebruiken, of een loep, een andere contrast gebruiken, de tekst laten voorlezen of een ander apparaat gebruiken dan een gewoon toetsenbord of muis.
  • Het moet haalbaar zijn, aanspreekbaar, lokaal, taal, hardware, enz.

Toegankelijkheid is niet alleen iets beperkt tot toetsenbord of screen-reader. We kijken bij dit onderwerp meestal vooral hier naar. Verbeteringen hierin zijn de basis voor andere mogelijke verbeteringen.

Problemen hierbij zijn vaak ontstaan door het ontwerp, strategische keuzes, het verkeerd inschatten van de te bereiken doelgroep gebruikers, enz. Dit is allemaal moeilijk te vatten in vaste regels die overal in de MediaWiki zouden moeten gelden, daarom wagen wij ons daar hier op deze pagina niet aan.

Toetsenbord navigatie

We noemen het hier toetsenbord navigatie, maar wat we bedoelen is: vertrouw er niet op dat er toetsenbord gebruikt wordt, het kan ook een muis of een touchpad zijn.

  • Met de navigatie kan de gebruiker de focus veranderen en acties laten uitvoeren.
  • Een element dat een tab kan zijn kan de focus krijgen.
  • Alles wat u met een muis zou kunnen doen, moet u ook met het toetsenbord kunnen doen.
  • De informatie van de navigatie kan het werken met screen-readers ondersteunen en verbeteren.

Screen-reader

  • Een screen-reader gebruikt een andere 'cursor', die meestal de logische structuur van het DOM volgt.
  • De focus volgt over het algemeen de cursor van de screen-reader en andersom, het is niet hetzelfde
    • U kunt het betreffende element volgen door in Chrome een live (productie) expressie te maken (klik op het oog in de werkbalk) [1]
  • Een screen-reader gebruikt de 'toegankelijkheid' API's, die u kunt beschouwen als een invoer/uitvoer 'beeld' bovenop de normale DOM.
  • ARIA zijn DOM opmerkingen (annotations) die uitbreiden of manipuleren hoe de logica van de DOM wordt omgezet in API's. Het is geen alternatief voor het schrijven van goede HTML en JavaScript. Toetsenbord navigatie wordt simpel bereikt door de logische DOM volgorde. Meer informatie over ARIA: w3.org uitleg en MDN uitleg.
  • Een screen-reader wordt niet beperkt door het navigeren via de logische DOM structuur, het is gewoon de standaard.
    • Een screen-reader kan lezen wat bijvoorbeeld onder de plek van de muis staat.
    • VoiceOver voor iOS gebruikt een cursor die is beïnvloedt door de plaats van de duim en de bewegingen over het touchpad.
    • De software van de meeste screen-readers heeft een aanvullende modus waar u op meerdere manieren kunt navigeren via markeringen, een inhoudsopgave of door gebruikergedefinieerde 'bladwijzers' in een pagina.
  • Uit het bovenstaande punt van meerdere navigatiemethoden volgt: Er is een begin en een eind, maar ook links, rechts, boven en onder. Vertrouw hier niet teveel op in uw communicatie, maar we kunnen het bestaan ervan niet ontkennen. Verwar de visuele mogelijkheden van de gebruiker niet met het ruimtelijk inzicht van de screen-reader aan de gebruiker kan geven. Voorbeeld:
    1. een lange zin [afbeelding] de bovenstaande afbeelding toont... Still acceptable
    2. een lange zin [afbeelding] [afbeelding] de linker afbeelding toont, de rechter afbeelding toont... Still acceptable
    3. een lange zin [afbeelding][afbeelding] de rechter afbeelding toont, de linker afbeelding toont... Not acceptable
    4. een lange zin [afbeelding] [afbeelding] de bovenstaande afbeelding toont... Not acceptable
    5. een lange zin [afbeelding] [afbeelding] [afbeelding] de linker afbeelding toont, de rechter afbeelding toont... Not acceptable
    6. een lange zin [afbeelding] [afbeelding] iets totaal verschillend. De linker afbeelding toont, de rechter afbeelding toont... Definitely not acceptable

Richtlijnen ontwikkelen

Er zijn meerdere standaarden met betrekking tot de benaderbaarheid. Eerlijk gezegd hebben de meeste daarvan, hoewel het gaat zaken identificeren, nog altijd significante problemen als het gaat om technische oplossingen (Het zijn meer lelijke noodoplossingen). Dit leidde tot veel opwinding en onenigheid in de gemeenschap. Ook kunnen we kijken welke zaken niet controversieel zijn en waarom dat dan zo is. Het is gemakkelijker om doelen te halen als we de zaken niet zinloos scherp zetten.

Gebruik en biedt altijd aan

Net semantisch HTML-element
Gebruik HTML-elementen voor het bedoelde doel. Bijvoorbeeld:
  • Gebruik ‎<button> en niet ‎<div>, ‎<span> of ‎<a> met een "click handler"
  • Als u iets met vet wilt maken, moet u bedenken of het niet beter is om een header of een element strong te gebruiken
Logische structuur kop
Alle pagina's moeten altijd een logische en consistente structuur van de kop hebben. Kopregel (headings) zijn een van de primaire hulpmiddelen voor navigatie die door screen-reader gebruikers worden gebruikt.
  1. Er moeten geen gaten zijn in de nesting van de niveaus van de koppen. (Dus geen H2->H4.)
  2. De kopregels moeten beschrijvend zijn
  3. De kopregels moeten uniek zijn binnen hun eigen niveau. (Er mogen geen twee H3 met dezelfde inhoud in dezelfde zectie H2 zijn)
  4. Er moet een scheiding zijn tussen navigatie en inhoud
alt attribuut voor afbeeldingen met betekenisvolle waarden
Als een afbeelding alleen voor de versiering is, gebruik dan een lege waarde voor het attribuut alt. Of gebruik daarvoor een CSS background afbeelding.
De alt waarde van een afbeelding heeft meestal voorrang boven het attribuut title van afbeeldingen en zelfs boven het attribuut title van links die om een afbeelding staan.
title attribuut voor links
Deze worden meestal als tooltip getoond.
Gebruik alleen titles als ze verschillen van de tekst van de link.
De meeste titles van een link worden niet door screen-readers uitgesproken, tenzij de screen-reader expliciet op deze manier is geconfigureerd.
lang, dir en hreflang attributen
lang en hreflang maken het mogelijk om een juiste stem te selecteren in screen-readers, de juiste spellingcorrectie in browsers etc. te kiezen.
Voldoende contrast
Controleer uw kleuren of er wel genoeg contrast is. Voor tekst is een hoger contrast nodig bij kleinere tekst (anders valt het minder op).
Aandacht voor het gebruik van het toetsenbord
Haal niet de omtrek weg van elementen die de focus kunnen krijgen, tenzij u uw eigen omtrek voor de staat :focus hebt gedefinieerd.
  • Gebruik anders geen outline: 0.
  • Als u een pseudo-klasse definieert, zoals :hover of :active, definieer dan een stijl :focus.
Navigatie met het toetsenbord
Interactieve elementen van een pagina moeten ook via het toetsenbord uit te voeren zijn. Zorg ervoor dat de navigatie met de tabbladtoets in uw browser is ingeschakeld en u elk interactief element kunt controleren zonder gebruik te maken van bijvoorbeeld een muis.
  1. Gebruik tabIndex: 0 om elementen op het toetsenbord toegankelijk te maken, die niet impliciet toegankelijk zijn op het toetsenbord (alles behalve ‎<a>, ‎<area>, ‎<button>, ‎<input>, ‎<object>, ‎<select>, ‎<textarea>).
    1. Voeg hierbij ook een keydown-handler toe die reageert op Enter (keyCode 13) en spatie (keyCode 32).
  2. Gebruik tabindex: -1 om elementen niet toegankelijkheid te maken. (Gebruik dit op links die labels zijn voor de actie binnen een ‎<li>...‎</li>, bijvoorbeeld)
  3. Elementen die impliciet toegankelijk zijn op het toetsenbord worden doorgestuurd naar de enter/spatie-gebruik handler
Dialogen enz.

Wanneer de toegankelijkheid niet goed wordt opgezet, zijn dialoogelementen een van de meest ontoegankelijke elementen voor een screen-reader en een toetsenbordgebruiker. Besteed hier tijd en aandacht aan.

  • Het element dat de dialoog opent moet aria-haspopup hebben
  • De dialoog zelf moet role=[dialog | alertdialog | tooltip] hebben
  • De dialoog moet worden ingevoegd in DOM-volgorde, [1] of ARIA eigenaar/controle moet deze relatie tussen het openingselement en de dialoog specificeren
  • Bij het openen van de dialoog, onthoud het laatste gefocuste element en verschuift de focus naar het eerste gefocuste tabbare element binnen de dialoog
  • Wanneer de dialoog 'modal' is, maak het onmogelijk om met de rest van de pagina te communiceren
    • Klikken buiten de dialoog afvangen en negeren of laat ze de dialoog afbreken
    • Zorg ervoor dat u niet met de tab naar links of input-elementen buiten de dialoog kunt gaan
    • Maak elementen buiten de dialoog ontoegankelijk voor de screen-reaader, met behulp van aria-hidden
  • Zorg ervoor dat er een close mode is (Esc-toets en een focusbare sluitknop met een beschrijvende titel)
  • Door het sluiten moet de focus terugkeren naar het oorspronkelijke focuspunt dat u hebt opgeslagen toen u de dialoog opende. Als u de dialoog niet in DOM-orde hebt ingevoegd, moet u de juiste eigenaar van de dialoog vermelden om de screen-reader weer naar hetzelfde punt te terug te zetten.
  • Meer informatie: Aria modals, Aria modal dialoog, ARIA nonmodal dialoog en ARIA tooltips.
WCAG 2.1 richtlijnen
Volg waar mogelijk
En de bijbehorende documenten:

Doe niet

  • Er is een advies om left: -1000px te gebruiken om iets (vaak de labels van pictogramknoppen) uit de viewport te duwen voor visuele gebruikers en het nog steeds in de DOM toegankelijk te hebben. text-indent: -9999px is hiervan een variant. Dit is een slecht advies.
    • Dit breekt onze RTL opbouw in verschillende browsers. Speciaal in de RTL-modus creëert het een groot gebied links van de viewport en scrollbars, net zoals +1000px in de LTR-modus zou creëren. (Als dat nodig is, wordt de voorkeur gegeven aan top: -1000px boven left: -1000px om dit te voorkomen.).
    • VoiceOver op mobiel kan deze tekst niet gebruiken als een uitwijk, omdat het een 'positionele' screen-reader is. U kunt niet met uw vinger over deze tekst schuiven en de tekst zal dus ook niet worden gelezen. (het label aria is vaak de beste keuze).
    • Ten slotte vergroot dit het scherm dat nodig is om de uiteindelijke webpagina te berekenen en kan dit de prestaties [2] op mobiele apparaten beïnvloeden.
    • Een inzichtelijk overzicht van de trucs met het 'verbergen van tekst op het scherm' wordt gegeven door Jonathan Snook.
  • Dingen moeten niet vaak herhaald worden. Als u 100 links op een pagina hebt die een dialoog kunnen openen, voeg dan niet 100 labels toe aan die 100 links die de gebruiker vertellen dat het kan worden gebruikt om een dialoog te openen. Het is goed om een gebruiker te vertellen hoe hij/zij de interface moet gebruiken, maar het is gewoon irritant om het consequent te doen. Zoek een andere manier om het een keer uit te leggen (in dit geval is aria-live=polite een idee).
  • <a href="#">Hide</a> met een onclick handler. VO leest zo'n JavaScript als "interne link verstoppen". Gebruik een juiste knop, of <a role="button" tabindex="0">Hide</a>, met 'Space' en 'Enter' key handlers. Maar geen attribuut href.
  • Plaats geen interactieve functionaliteit in een ander interactief element (links of knoppen in links). Dit verwart de screen-readers.

Voorkom

Unicode-symbolen
De meeste hulptechnologieën zijn niet goed met symbolen. Probeer daarom tekens als ↑, → of complexere tekens te vermijden, omdat veel screen-readers ze niet begrijpen. Als ze nodig zijn, probeer dan ze in een element span te zetten met het attribuut title, zodat dat attribuut de impliciete betekenis binnen de context is voor de lezer.
Kleine lettertypen
Leesbaarheid is de voorkeur. Als u iets zo klein maakt dat het moeilijk is om te lezen, heeft u het dan wel nodig? Vermijd ook kleine lettertypen met lage of middelmatige contrastwaarden (zelfs als ze binnen de WCAG-richtlijnen vallen, kleine afmetingen vereisen meer expliciet contrast dan grote afmetingen, vooral met anti-aliasing ingeschakeld).
Ongebruikelijk grote lettertypen
Als u de tekst veel groter maakt dan normaal, kan het ook moeilijk te lezen worden (tenzij het erg kort is). Dit geldt voornamelijk voor tekst in een alinea, of iets wat meer dan een paar regels bevat. Hoe groter de tekst is, hoe meer regels het zal gebruiken.
tabIndex > 0
DOM-volgorde is de voorkeur waar mogelijk. De DOM-volgorde geeft de context voor de acties.
Tijdelijke oplossing
Traditioneel heeft het bereiken van 'volledige' toegankelijkheid veel oplossingen vereist voor html zelf, de browsers en zelfs specifieke screen-reader-software. Deze oplossingen hebben echter vaak bijwerkingen, maken gebruik van bugs of ongespecificeerd gedrag en creëren onvermijdelijk technische problemen.
MediaWiki, vanwege de gebruikers die het wil bedienen, de hoeveelheid code, het (ontbrekende) geld, etc. heeft de neiging om toekomstbestendige code te verkiezen boven foutgevoelige code. Als zodanig vermijdt het over het algemeen tijdelijke oplossingen, ook al kan dat soms de toegankelijkheid die wij kunnen bieden beperken. Beslissingen hierover worden vaak beïnvloed door het relatieve publiek van de functie in MediaWiki. Als iets alomtegenwoordig is voor alle gebruikers, is een tijdelijke oplossing meer gewaarborgd dan als de aangetaste functie alleen wordt gebruikt door een klein deel van het publiek (bijvoorbeeld het lezen van een pagina versus het wijzigen van de configuratie van de installatie).

Overweeg

  • ARIA Rollen
    • Als een div of span zich gedraagt als een echte knop, gebruik role="button". Ook role="dialog" en role="alert"
    • Wees voorzichtig met de rollen. Voeg bijvoorbeeld niet role="button" aan een element van ‎<th> toe omdat het element van ‎<th> een impliciete role="columnheader" heeft, die zal worden overschreven. Gebruik in plaats daarvan geneste elementen. Net als bij ‎<li> die een impliciete role="listitem" heeft.
    • Als een knop een popup dialoog maakt, gebruik dan aria-haspopup.
    • Gebruik aria-labelled-by voor contexten waar dit niet volledig logisch is (dus overal behalve voor labels in formulieren en koppen in tabellen).
  • Vermijd tabellen voor het geven van uitleg en test ook op kleinere schermbreedtes.
  • zaken verbergen: https://www.tpgi.com/html5-accessibility-chops-hidden-and-aria-hidden/
  • skip/spring naar links

Zie ook

Referenties

  1. ↑ Zie DOM volgorde op w3.org en Stijl volgorde eigenschap op w3schools.org
Retrieved from "https://www.mediawiki.org/w/index.php?title=Accessibility_guide_for_developers/nl&oldid=6335297"