Toegankelijkheid voor ontwikkelaars

BouwhelmOntwikkelaars brengen een ontwerp tot leven. Hun verantwoordelijkheid is dat de website gaat werken zoals bedacht en ook daadwerkelijk bedienbaar is door iedereen. Verder moeten zij ervoor zorgen dat het content management systeem (CMS) goed ingericht wordt zodat redacteuren hun content toegankelijk kunnen publiceren.

Onderstaande richtlijnen zorgen niet alleen voor betere toegankelijkheid, maar ook voor betere performance, vindbaarheid in zoekmachines en browser-compatibiliteit.

Algemeen

Gelaagd bouwen (illustratie: Michelle Thonen)

  • Scheid content, opmaak en interactie. Dit principe heet gelaagd bouwen (progressive enhancement) en zorgt ervoor dat de website goed functioneert wanneer bijvoorbeeld stylesheets of JavaScript niet wordt ondersteund.
    • Zorg dat alle content in het HTML-document beschikbaar is en niet afhankelijk is van scripts en plugins. Gebruik JavaScript alleen om interactie of dynamische weergave te realiseren. Plaats geen content door middel van JavaScript.
    • Regel alle opmaak in een goed georganiseerde stylesheet. Gebruik dus geen inline style-attributen.
    • Plaats JavaScript in aparte JavaScript-bestanden, niet in het HTML-document.
    • Vermijd het gebruik van verouderde HTML-elementen, zoals <center>, <font>, <b>, <i> en <u>. Deze elementen zorgen voor opmaak in plaats van semantiek en gaat tegen het principe van gelaagd bouwen in.
    • Misbruik HTML-elementen niet voor opmaakdoeleinden. <blockquote> is niet bedoeld voor het inspringen van tekst, maar voor de opmaak van citaten.
  • Lever HTML, CSS en scripts op conform W3C-specificaties.

    In Internet Explorer 8 kun je eenvoudig programmacode valideren op HTML en CSS. Via functietoets F12 kom je terecht bij de Ontwikkelhulpprogramma’s (Engels: Developer Tools). In het menu ‘Valideren’ vind je W3C-validators voor HTML en CSS.

  • Zorg dat alle content bereikbaar en bedienbaar is met alleen het toetsenbord. Vermijd dus apparaatspecifieke event handlers als “onmouseover”.

Pagina-opbouw

Begin met het opzetten van een skelet. Hiermee creëer je een consistente pagina-opbouw, die blinden helpt sneller te navigeren en ook beter onderhoudbaar is. Vervolgens kun je per template specifieke elementen toevoegen.

  • Definieer het “XHTML 1.0”-doctype bovenaan het HTML-document voor een correcte representatie van de website. HTML5 is nog geen formele W3C-standaard.

    <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

  • Vermeld de basistaal van de pagina in het ‘HTML’-attribuut.

    <html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”nl” lang=”nl”>

  • Gebruik de UTF-8 karakterset. Dit is de officiële, internationale standaard en zorgt voor de beste ondersteuning voor alle talen.
  • Plaats de belangrijkste contentblokken vooraan in de broncode. Navigatie, zoekfunctie, meta-menu en dergelijke komen daarna pas aan bod.
    • Positioneer de onderdelen op de pagina met behulp van de stylesheet.
    • Plaats boven de content hyperlinks waarmee de gebruiker direct naar de navigatie en de zoekfunctie kan gaan. Deze links hoeven niet zichtbaar te zijn als de stylesheet is ingeschakeld.
  • Zorg voor een correcte kopregel (heading) structuur.
    • Reserveer <h1> voor de paginatitel. Iedere pagina heeft dus één <h1>.
    • Gebruik <h2> voor paragraaftitels en kopregels voor de belangrijkste paginaonderdelen, zowel zichtbaar (bv. “Gerelateerde pagina’s”) als onzichtbaar (bv. “Hoofdmenu”).
    • Gebruik <h3> voor subparagrafen.
    • Gebruik geen <strong> of iets dergelijks voor het aangeven van kopregels.
    • Sla geen stappen over. Gebruik dus geen <h3> zonder een <h2> begin altijd met de <h1>.
  • Gebruik tabellen alleen voor tabulaire data. Tabellen voor de opmaak van content is niet toegestaan.
  • Gebruik geen iframes en frames.

Opmaak

Content moet betekenisvol en correct opgemaakt worden, zodat er geen informatie verloren gaat voor gebruikers.

  • Maak lijsten op met <ul> of <ol> elementen. Tip: Een navigatiemenu is ook een lijst.
  • Voorzie iedere afbeelding van een alt-attribuut.
    • Brengt de afbeelding informatie over, communiceer deze informatie dan in de alt-tekst.
    • Is de afbeelding puur decoratief of illustratief, laat de alt-tekst dan leeg (alt=””).
    • Maakt de afbeelding onderdeel uit van een hyperlink die al een tekstlabel heeft, laat de alt-tekst dan leeg. Twee keer het zelfde label is te veel van het goede.
  • Plaats decoratieve afbeeldingen zoveel mogelijk met CSS.
  • Vermijd afbeeldingen voor tekst.
  • Zorg dat alle content tot minimaal 200% kan schalen als gebruikers inzoomen.
  • Ontneem links niet het outline attribuut met CSS, omdat het voor mensen die met het toetsenbord werken duidelijk moet zijn welk element de focus heeft.

Multimedia en dynamische content

  • Zet een toegankelijke mediaspeler in voor het afspelen van video’s. De mediaspeler moet gebruikers in staat stellen:
    • Ondertiteling in/uit te schakelen;
    • Ondersteunend geluidsspoor in/uit te schakelen;
    • Video-bestand te downloaden als JavaScript of plugin uitgeschakeld is.
  • Zorg dat bewegende, knipperende, scrollende of automatisch actualiserende content gepauzeerd, verborgen, vertraagd en/of gestopt kan worden.

Formulieren

  • Breng in grote formulieren structuur aan door het groeperen van aan elkaar gerelateerde invoervelden. Gebruik bijvoorbeeld fieldsets voor ‘Persoonsgegevens’ en ‘Bedrijfsgegevens’.
  • Voorzie ieder invoerveld van een label.
  • Geef aan welke invoervelden verplicht ingevuld moeten worden.
  • Geef concrete feedback bij het foutief invullen van het formulier. “U heeft niet alles ingevuld” is onvoldoende. Maak zowel in tekst als visueel duidelijk wat de gebruiker precies is vergeten of welke invoer foutief is.
  • Wees terughoudend met het gebruik van CAPTCHA’s om spambots te weren. Omdat de meeste CAPTCHA’s veel eisen van zicht- of gehoorcapaciteiten, moet je meerdere output alternatieven geven. Denk ook eens na over alternatieve oplossingen. Een simpele vraag als “Hoeveel is 1+1?” met invoerveld is ook effectief en toegankelijk.

CMS inrichten

  • Zorg dat redacteuren voor iedere pagina de titel, pagina-beschrijving en trefwoorden kunnen opgeven.
  • Zorg dat de editor alle functies ondersteunt die nodig zijn om toegankelijke content te kunnen produceren:
    • Minimaal: kopregels voor (sub)paragrafen (H2+H3), opsommingen (genummerd en ongenummerd), hyperlinks, afbeeldingen, taalaanduiding (per alinea en geselecteerde tekst), belangrijke woorden (vet), nadruk (cursief).
    • Bij voorkeur: afkortingen, tabellen (met ondersteuning voor titel, labels en scope) , blokcitaat, tekst uitlijnen (voor in tabellen), aangepaste stijlen (indien van toepassing, bijvoorbeeld voor een intro-alinea, tip of citaat).
  • Schakel functies in de editor uit die content alleen maar ontoegankelijker kunnen maken:
    • Minimaal: lettertype, tekstkleur, achtergrondkleur, tekstmarkeringskleur
    • Bij voorkeur: onderstrepen, kopregel voor paginatitel (H1), broncode bewerken (maar alleen als tabellen via de editor volledig conform richtlijnen kunnen worden opgemaakt)
  • Zorg dat de editor alleen valide code produceert, dus bijvoorbeeld geen <b> maar <strong>.

Heb je aanvullingen of opmerkingen? Laat het weten!

Zie ook

Jeroen Hulscher is collega bij Tam Tam en frontend code-purist. Houd zijn nieuwe blog goed in de gaten voor meer artikelen over toegankelijk en kwalitatief bouwen!

12 gedachten over “Toegankelijkheid voor ontwikkelaars”

  1. Volgens mij bedoel je bij de laatste zin trouwens geen {b} maar {strong}. Die vergissing geeft wel aan hoe lang het geleden is dat je zelf een b-element hebt gebruikt ;-)

  2. Een groot gedeelte van je artikel gaat over algemeenheden die technologie-overschrijdend zijn, zowel voor de toegankelijkheid als gebruiksvriendelijkheid goed om nog eens op een rij gezet te hebben. Bedankt!

    Ik begrijp echter niet dat je de technische richtlijnen op deze manier neerzet. Je baseren op de verouderde versie van “de webrichtlijnen”, levert dat een enigszins verouderd en mijns inziens onjuist beeld op. Sterker nog: de webrichtlijnen hobbelen per definitie achter de nieuwste technologiën aan. Een paar voorbeelden:

    “Definieer het “XHTML 1.0”-doctype”: Vermeld er dan ook bij dat in de nieuwe versie van de webrichtlijnen HTML5 unobtrusive gebruikt “mag” worden. Sterker nog: HTML5 levert een toegankelijker document op door het toestaan van verscheidene attributen die in XHTML 1.x niet toegestaan zijn.

    “Zorg dat de editor alleen valide code produceert, dus bijvoorbeeld geen <b> maar <strong>”: Wederom vermeldt de HTML5 specificatie dat <b> een valide element is om te gebruiken. Het gebruik van <strong> voor alles wat een gebruiker als bold wilt tonen, is sowieso een slechte richtlijn. Nuances in semantiek spelen hier ook.

    “Vermijd het gebruik van verouderde HTML-elementen, zoals , , <b>, <i> en .”: Een gedeelte van deze elementen zijn niet verouderd, maar geherdefinieerd.

    “Gebruik geen iframes en frames.”: Wat mij betreft ongefundeerd, een is perfect valide en heeft uitstekende use-cases.

    Zo is er ongetwijfeld meer. Ik ga er vanuit dat je van bovenstaande zelf wel op de hoogte bent. Met name daarom vind ik het een gemiste kans om mensen te wijzen op de kracht van nieuwe technologiën en (opkomende) richtlijnen.

    Conformeren aan een verouderde richtlijn omdat het de huidige aanbeveling is, betekent alleen dat je document voldoet aan de richtlijn. Niet dat de gebruiker er beter van wordt.

    Naast dit alles ben ik blij dat je over toegankelijkheid schrijft en hopelijk blijft schrijven! :)

  3. Hallo Peter, bedankt voor je reactie. De reden dat we juiste her en der de keuze hebben gemaakt om ons te houden aan de huidige richtlijnen, is omdat het daarmee toetsbaar is. Ik ben absoluut voorstander van het HTML5 doctype, en we zijn inderdaad op de hoogte van de nuances zoals bijvoorbeeld de herdefinieringen van <b> en <i> -elementen. Het lastige is dat je bij een lijst als deze toch op zoek moet naar de gulden middenweg.

    Ferry en ik werken veel voor instanties die zich moeten conformeren aan de webrichtlijnen, en dat hebben we ons – soms helaas, en soms gelukkig – te houden aan strakke regelgeving bij het bouwen met websites en -apps.

    Overigens; zoals je wellicht weet wordt het gebruik van <b> en <i> in de – voorlopige – HTML5 specificatie ter zeerste afgeraden ;-) Het zelfde geldt voor (i)frames en target-attributen op links, en daar is een reden voor. Bij het gebruik van bijvoorbeeld screenreaders kan dit voor veel verwarring zorgen. Het artikel van Ferry over het bezoek van een blinde man bij ons op Tam Tam illustreert dat des te meer.

    Wat ik maar wil zeggen; het is goed om kritisch te zijn naar de harde regels, maar er is een reden dat zulke regels de gulden middenweg bepalen. Ik ben – net als jij volgens mij – groot fan van HTML5 en CSS3, maar zoals je zelf al zegt; de beleving voor de gebruiker moet uiteindelijk centraal zijn. Ik denk dat een groot deel van de WCAG- en/of webrichtlijnen daar erg goed bij kunnen helpen! :)

  4. Hoi Peter, dank voor je uitvoerige feedback! Kijken of ik alles goed kan beantwoorden…

    Net als bij de andere 2 artikelen (voor ontwerpers en redacteuren) ben ik juist zoveel mogelijk uitgegaan van de nieuwste richtlijnen voor toegankelijkheid: WCAG 2 (dec. 2008). Ik heb volgens mij slechts een paar Webrichtlijnen v1 overgenomen.

    Waarom XHTML 1.0 en geen HTML5? Niet vanwege de Webrichtlijnen, maar omdat HTML5 nog niet de W3C status “Recommendation” heeft, maar “Working Draft”. In het kader van toegankelijkheid leek HTML5 me daarom nog steeds de beste optie, ook omdat niet alleen richtlijnen achter innovatie aanlopen, maar aangepaste software nog veel meer. Maar inderdaad: zodra HTML5 officieel W3C-standaard wordt, kunnen we daarmee aan de slag.

    Het probleem met <b> is dit: als je een tekst vet wilt tonen, heb je daar 9 van de 10 keer een bedoeling mee: nadruk geven. Semantisch geef je dit aan met strong. Bold zegt niets over betekenis, maar puur over weergave. Dus ook al is bold net zo valide, dan heeft strong semantisch gezien nog steeds de voorkeur. Hetzelfde geldt voor italic vs emphasis.

    Ten slotte iframes en frames. Frames zijn gelukkig al 8 jaar uit de mode. Onhandig voor deeplinken, maar ook voor blinden om tussen frames te navigeren. Iframes kun je tegenwoordig dacht ik wel toegankelijker inzetten, maar helemaal zeker ben ik daar niet over. In het kader van widgets e.d. is het niet kunnen gebruiken van iframes wel een beetje onhandig.

    Kortom, ik wil zeker uitgaan van de nieuwste richtlijnen, maar wel van officiële richtlijnen (dus geen concepten). En in het kader van toegankelijkheid is valide niet altijd voldoende.

    Ten slotte: ik ben blij dat je de verhalen over toegankelijkheid zo waardeert! En ik ben erg blij met je reactie! Keep it coming…

  5. Laat ik voorop stellen dat ik me in de meest genoemde punten gewoon kan vinden.

    Daarnaast:
    In de HTML5 specificatie wordt het gebruik van <b> en <i> zeker niet afgeraden. Er worden connotaties bij geplaatst die aangeven dat de ontwikkelaar goed moet opletten op de semantische waarde van het element. Er wordt vanuit de specificatie gestimuleerd om na te denken over het gebruik van het juiste element. Wat betreft semantiek van deze elementen: zie de specificatie en bijvoorbeeld HTML5 doctor.

    Dat geldt overigens ook voor het iframe. Bovendien is een iframe met fallback content redelijk toegankelijk te maken.

    Zonder verder op de technische details in te gaan, denk ik dat mijn kritiek vanuit een ander paradigma komt. Mijns inziens is niet de papieren werkelijkheid die een (verouderd) systeem van regels schept de gulden middenweg, maar de expertise van een vakman (in dit geval dus van diverse specialismen).

    De vakman zal de huidige versie van de webrichtlijnen niet als gulden middenweg of optimum zien — een bewijs daarvan is natuurlijk dat er nu een tweede versie gereviewed wordt. De vakman zal een combinatie van oude principes en nieuwe technieken aanraden.

    Zeker als je vervolgens de gebruiker erbij haalt die centraal moet staan: de gebruiker krijgt een veel betere ervaring door het combineren van oude “universele” principes en de kracht gebruiken van nieuwe technieken.

    Dat bovenstaande niet te toetsen is op basis van een verouderde set regels is dan irrelevant. De webrichtlijnen zouden geen uitgangspunt moeten zijn voor het schrijven van een artikel over ‘toegankelijkheid voor ontwikkelaars’ (er vanuitgaande dat de doelgroep vakmensen zijn). Als een instantie (ofwel vanuit wettelijke verplichting, ofwel vraaggestuurd) waarde hecht aan een sticker van de webrichtlijnen, zal de vakman consessies moeten doen om aan de regels te moeten voldoen.

    Sterker nog: de werkelijkheid die ontstaat door een richtlijn als optimum te beschouwen, is per definitie een bedachte werkelijkheid die niet in sync is met de echte werkelijkheid. De vakman die elke dag bezig is met aan de front-end gerelateerde technieken kan beter inschatten of het document toegankelijk is dan een set van regels die op een bepaald moment bevroren wordt en als leidend wordt beschouwd.

    Interessant is overigens dat de nieuwe versie van de webrichtlijnen HTML5 toestaat. HTML5 staat ARIA toe, en ARIA verslechtert met de huidige screenreaders juist de toegankelijkheid en dus ervaring. De man op de werkvloer, de vakman die weet wat de problemen zijn, moet zijn document niet spiegelen aan een richtlijn, maar aan zijn eigen kennis en kunde. Ik ga er vanuit dat jullie ook binnen deze categorie vakmensen vallen. In die zin zou juist een artikel over toegankelijkheid voor ontwikkelaars een hele goede plek zijn om elkaar aan te scherpen :)

    Je hebt me in ieder geval geïnspireerd om hier eens verder na te denken over het paradigmaverschil tussen de papieren werkelijkheid van een richtlijn en de echte werkelijkheid. Ik hoop dat je begrijpt wat ik bedoel! :)

  6. Ha Ferry!

    Ik denk dat mijn reactie op Jeroens bericht ook onder dit bericht zou passen.

    Nog even kort hierop:
    Met het wachten op het feit dat het W3C een recommendation afgeeft op de HTML5 specificatie kan ik niet zoveel. We weten beide dat deze status best eens pas in 2015 of 2022 afgegeven kan worden. Jij zal dus zeker ook eerder serieus aan de slag gaan met HTML5 dan dat het een officiele aanbeveling wordt van het W3C.

    Bovendien weten we als professional dat de HTML5 specificatie de vakman meer ruimte biedt om het document voor de gebruiker te optimaliseren.

  7. Ok, misschien duurt het inderdaad nog een tijd voordat HTML5 een recommendation wordt.

    Wat voor toegankelijkheid wel belangrijk blijft, is hoe snel assistive technology zoals screenreaders nieuwe specificaties ondersteunen. Geen idee hoe dat momenteel is m.b.t. HTML5.

  8. Hi Peter, volgens mij zitten we behoorlijk op één lijn, maar ik ben ik de conservatieve tak bij wijze van. De nuance tussen richtlijnen en de praktische uitvoering is iets waar wij ook iedere dag mee stoeien. De truc is denk ik dat voor “de gemiddelde developer” richtlijnen goed kunnen werken als startpunt van correcte bouw, valide code en een logische opbouw van code. In dat opzicht betreur ik ook dat voor de webrichtlijnen een “alles of niets”-waarmerk geldt. Het zou beter zijn als er meerdere gradaties van toegankelijkheid zijn, zoals bij het Waarmerk Drempelvrij het geval is. Tevens vind ik het jammer dat de Webrichtlijnen versie 2 een wat verzwakte versie zal zijn van de “oude” webrichtlijnen, en er minder wordt gestuurd op kwaliteit van code, logica en structuur en wat meer “op de regel” wordt gekeken. Ik denk dat het goed is om iets te hebben dat als leidraad geldt, waar dan in meer of mindere mate aan kan worden gecommiteerd.

    Ik vind je opmerking over HTML5 en ARIA wel een mooie overigens; zo had ik het nog niet bekeken, maar dat zal wel wat lastige discussies opleveren.

    Overigens; absoluut, dit is de plek om de discussie te voeren, dus keep ‘m coming, hoor ;-)

  9. Ik moet je helaas teleurstellen, na de Microsoft Mix in Vegas en An Event Apart in Boston is het budget op voor dit jaar, dus no more conferences. Volgend jaar zijn we er weer bij ;-)

Geef een reactie