Re: toegankelijkheidsmonitor 2009
AnySurfer publiceerde vandaag voor de derde keer de Toegankelijkheidsmonitor. Het doel van die toegankelijkheidsmonitor?
Met dit project willen we studenten informatica, webdesign en multimedia — de webwerkers van de toekomst — doen nadenken over het belang van een toegankelijk internet en hen de principes van universeel ontwerp bijbrengen. Zo hopen we dat zij op hun beurt een steentje zullen bijdragen aan een toegankelijker internet. Met de resultaten van dit onderzoek zetten we voorts de problematiek in de kijker bij eigenaars van websites, webdesigners en ontwikkelaars, beleidsmakers en politici.
De resultaten zijn bijzonder slecht: Slechts 7% van de onderzochte websites haalde een gewogen eindcijfer (*) van minstens 75%, de drempelwaarde om te kunnen spreken van een behoorlijk toegankelijke website.
Nobel doel
Allereerst wil ik de mensen van AnySurfer krediet geven voor het uitvoeren van dit onderzoek. Een website waar aandacht is gegeven aan toegankelijkheid helpt niet alleen de bezoeker met een functiebeperking maar iedereen.
Een website kunnen volledig kunnen bedienen met het keyboard helpt zowel iemand die geen muis kan bedienen als een power user die zijn muis niet wíl bedienen. Zoals Piet ooit eens wijs zei: every time you touch the mouse, god kills a kitten
.
Een ander voorbeeld is nummer 14 (Zijn er alternatieven voor belangrijke paginaonderdelen in Flash?), een regel die maar al te duidelijk wordt als je het web rondsurft op een mobiele telefoon.
Kritiek en bedenkingen
Dit zou geen re: zijn moest er ook geen kritiek aan te merken zijn op het rapport.
Mensen die websites beheren zijn niet diegene die ze maken
Webbouwers maken websites en laten ze dan meestal achter in handen van de klant, die de inhoud beheert. Diegenen die dit doen zijn zelden onderlegd in accessibility. Eikpunt 8 (8. Hebben alle afbeeldingen een alternatieve beschrijving?) kan in dit geval nooit gehaald worden.
Mensen met een functiebeperking en de juiste software
Regel 5 en 6:
- Is de tekst eenvoudig te vergroten?
- Treden bij vergroting geen overlappingen op?
Als je een recente browser gebruikt (e.g. Firefox 3, Internet Explorer 8 of Safari 4) kan je zonder problemen de hele pagina “inzoomen”. Bij oudere browsers vergroot enkel de tekst, wat zorgt voor de overlappingen uit (6).
Voor nog oudere browsers (IE6) moet je je font sizes definiëren in ems of percentages. Font sizes in px vergroot IE6 niet. In het rapport wordt letterlijk deze optie genoemd:
In Internet Explorer is dat bijvoorbeeld via het menu beeld, optie tekengrootte.
Nu kan je je afvragen: als je een functiebeperking hebt, is het dan niet zinnig om nieuwere software te installeren die je een betere gebruikservaring biedt?
Zo heeft de browser Opera bvb. een high contrast modus (regel 7: Contrasteert de tekstkleur voldoende met de achtergrond?) en een speciale “accessibility layout” modus die beiden helpen als je een zichtbeperking hebt.
Het tragische is dan natuurlijk dat vaakgebruikte accessibility software (JAWS) enkel samenwerkt met Internet Explorer.
Ikzelf heb geen ervaring met JAWS. Ik stel me ernstige vragen bij een pakket dat $895 kost (bron). Hoeveel wordt dit eigenlijk in de praktijk gebruikt?
Striktheid
Met welke striktheid moeten de AnySurfer regels toegepast worden? Neem nu deze:
Is gesproken tekst in audio- en videofragmenten ook tekstueel beschikbaar?
Stel nu dat je de trailer van de film Public Enemies op je website zet. Als we de regel strikt volgen moet je de gesproken tekst in dit videofragment ook op je website zetten. Voor een trailer gaat dat natuurlijk extreem belachelijk overkomen.
Ik vermoed dat deze regel dan ook enkel geldt voor content waar het zinnig is een tekstueel alternatief aan te bieden bvb. een speech. Een goed voorbeeld zou dan de speech van Obama zijn toen hij als president ingezworen werd. Deze speech is als video beschikbaar is op de website van NYTimes maar ook als tekst.
Validatie
Voldoet de homepage strikt aan de HTML-versie die aangegeven staat in de broncode
Deze regel is in de praktijk niet haalbaar. Een ampersand die niet geëncodeerd is, een YouTube embed of een kleine typfout is genoeg om een pagina niet te laten valideren, terwijl deze nog altijd correct werkt. Facebook Connect geïntegreerd? Je pagina zal nooit meer valideren.
HTML puristen zullen nu claimen dat het niet moeilijk is om een pagina te laten valideren (waar); de zin van het valideren, buiten fouten tegen de HTML syntax om, ontsnapt me volledig (zie ook wat ik hier eerder over schreef).
Mijn visie
Als webbouwer schrijf ik dagelijks code die elk aspect omvat van de vuistregels die voorop gesteld worden in dit onderzoek. In de praktijk is het mogelijk om bijna alle van deze vuistregels te volgen zonder (al te veel) af te doen aan het ontwerp van een website.
Echter, wanneer je een stapje verder wilt gaan dan een informatieve, hoofdzakelijk tekstuele site wordt het bijzonder moeilijk (en tijdsrovend) om nog toegankelijk te blijven. Een site met veel interactieve stukken (ik denk aan modal windows, uitklappende forms, e.a.) toegankelijk houden is een uitdaging op zich, en een uitdaging die in een bedrijfscontext zelden uitgevoerd wordt.
Is het zinnig om veel aandacht aan accessibility te besteden als je website meer op een desktop softwareprogramma lijkt dan een brochure?
Voorbeeld: een blinde Bloc Party fan gaat naar de website van een concerthuis om daar naar een video te luisteren van een live concert. De video is een flash object dus de fan komt van een koude douche thuis.
Wat kan ik daar aan doen? Ik zou de site in HTML5 kunnen bouwen zodat de screenreader de “play video” link kan lezen en de blinde fan de video kan beginnen activeren. Ik denk “OK, ik heb mijn best gedaan, nu naar huis.” (ik voldoe dan wel niet aan regel 15 van de AnySurfer toegankelijkheidsmonitor, en ik vergeet ook even dat het <video> element enkel ondersteund wordt door Firefox 3.5 en nieuwer en Safari 4 en nieuwer).
Dan begint het: de video speler geeft een error want de video kan niet gevonden. Deze error wordt door javascript in de pagina gegooid op een zichtbare plaats. Er is geen enkele manier dat de voorlees-software van deze gebruiker kan weten dat hij de error moet voorlezen. Tenzij we de error in een alert() (dat irritante OK venstertje) weergeven; maar dan doen we weer af aan de gebruikservaring van “al de rest”.
Basistoegankelijkheid voorzien zou een verplichting moeten zijn voor elke webbouwer: maar vanaf je geavanceerde dingen gaat doen is het gewoonweg niet haalbaar om een goede gebruikservaring te bieden voor iedereen. Dan is het kiezen of delen, en in een bedrijfscontext betekent dat dus kiezen voor de gebruikers zonder functiebeperking.
Wat is AnySurfer?
Het Belgische AnySurfer is een organisatie met als hoofddoel een toegankelijker internet voor iedereen te verwezenlijken, met een bijzondere aandacht voor diegenen met een functiebeperking (e.g. blindheid, geen muis kunnen gebruiken).
Bedrijven kunnen Anysurfer contacteren om een audit uit te voeren op hun website: zij ontvangen dan een rapport met aanbevelingen over het verbeteren van hun website.
Bedrijven die aan de toegankelijkheidsvoorwaarden van AnySurfer (gebaseerd op o.a. de WCAG en het Kwaliteitsmodel Webrichtlijnen van de Nederlandse overheid) mogen het AnySurfer label dragen. Concreet komt dit neer dat zij het logo van AnySurfer op hun website mogen zetten om aan te duiden dat ze aan de toegankelijkheid hebben gedacht bij het ontwikkelen van de website.
Bedrijven in de gezondheidssector en vooral overheidsinstanties hebben er belang bij om dit label te halen omdat het hun plicht is om toegankelijk te zijn (wettelijk in het geval van de overheid). Vaker is de hoofdreden om een audit uit de voeren eerder het imago van het bedrijf.
4 reacties op “Re: toegankelijkheidsmonitor 2009”
Reacties gesloten
Het is niet meer mogelijk om reacties te geven op dit bericht. Na plaatsing is het gedurende 2 weken mogelijk om te reageren. Dit om de kwaliteit van de uiteindelijke post hoog te houden en spam tegen te gaan. Mocht je toch nog (persoonlijk) willen reageren, zie de contactpagina.
JAWS wordt heel veel gebruikt. Er zijn ook alternatieven: het open source project NVDA (http://www.nvda-project.org/) en de Firefox extension (ook open source) Fire Vox (http://firevox.clcworld.net/)
Wat het eikpunt 8 betreft zie ik zelf in de praktijk eigenlijk geen enkel probleem. Als je een website oplevert die door andere mensen wordt beheerd (de eigenaar van de site of een ander bedrijf) is dit een kwestie van die mensen op te leiden, en regelmatig na te gaan of ze de richtlijnen volgen. Zeggen dat dit dus nooit gehaald kan worden is fout. Ik kan je meer dan 1 voorbeeld bezorgen.
Wat betreft het zorgen voor het uitschrijven van een video zie ik ook geen probleem. Voor jou zou dat in sommige gevallen belachelijk overkomen (je geeft als terecht voorbeeld die trailer), maar niet voor de mensen waarvoor deze tekst dient. Zelfs voor een trailer. Zo hebben we zelf al veel video’s uitgeschreven, met bij elke overgang naar een andere scene of situatie een korte zin die uitlegt wat je ziet, wie de persoon die spreekt is (naam, en eventueel details over wie de persoon is in het geheel van de video), en zelfs met de herhaling van de “euh’s”
Bedankt voor je kritische bedenkingen! Een geavanceerde webapplicatie toegankelijk maken volgens alle ‘regeltjes’ is inderdaad niet eenvoudig en compromissen sluiten is dan bijna onvermijdelijk. Voor typische content sites (en blogs) is het echter zeer haalbaar en ik ben blij dat je de meeste zaken zelf al als best practices meeneemt bij het bouwen van zo’n website :)
Wat je schrijft over de zin/onzin van het valideren: gedeeltelijk akkoord. Het klopt dat een site niet meer of minder ‘toegankelijker’ wordt wanneer je ampersands wel of niet als html entities zijn gecodeerd of wanneer je een tag vergeet te sluiten.
Het valideren van een webpagina is daarom ook geen AnySurferrichtlijn. In de Toegankelijkheidsmonitor is het criterium wél gemeten (omdat het een interessant cijfer oplevert en het snel te checken is), maar het is niet meegenomen in de eindberekening (en ik bemerk nu dat we dat nergens vermelden in het rapport: dat moet ik rechtzetten).
Anderzijds leert de ervaring wel dat valide code (HTML/CSS) het debuggen van JavaScript en het oplossen van nasty CSS bugs in de praktijk wel versoepelt: onvoorspelbare en soms schijnbaar willekeurige ‘nukken’ (of crashes) van sommige browsers/browserversies kan je hiermee in sommige gevallen al uitsluiten.
Mensen met een functiebeperking die met IE6 surfen moeten dringend hun browser updaten, helaas zwijgt Anysurfer het punt van de browserkeuze meestal dood, terwijl dat toch uiteindelijk het programma is dat je gebruikt om sites te bekijken.
Wat Vincent zegt, klopt. Je kan de beheerders van een website perfect opleiden om hun teksten en beelden toegankelijk te maken. Maar ze blijven dat zelden doen, tenzij daar echt een dwingende reden toe is. Ik kom courant tegen dat beeld en tekst rechtstreeks vanuit Word geplakt worden in de backoffice, met alle problemen van dien. Hetzelfde geldt voor heelder catalogi en brochures die gewoon als (ontoegankelijke) pdf online gegooid worden, omdat het snelsnel moet.
Ik sta volledig achter de doelstellingen van Anysurfer en probeer die als webdesigner ook te halen, maar ik vind het jammer dat wij (developers/designers) altijd geviseerd worden bij dit soort dingen. We moeten niet alleen zorgen dat onze sites werken in drie browsers in verschillende versies op verschillende problemen, dat ‘alles’ kan via de backoffice, dat er hoge bezoekersaantallen gehaald worden, dat de site snel inlaadt, dat hij gebruiksvriendelijk is, dat de navigatie reflecteert wat de bezoeker verwacht, én dat hij toegankelijk is. Ook opdrachtgevers en beheerders hebben hun verantwoordelijkheid, er wordt te vaak te veel verwacht van ‘de nieuwe site’.
Ik ken een aantal mensen van Anysurfer en ze zijn zeer pragmatisch ingesteld, ze beseffen ook dat je soms niet álle video van ondertitels kan voorzien, dat niet élke pdf een HTML alternatief kan hebben. Als je hun rapport leest, komt dat helaas niet zo over. Het lijkt alsof ‘toegankelijkheid’ een onvoorstelbaar moeilijk te bereiken doel is, terwijl het gewoon wat meer professionaliteit en kwaliteitszorg vergt, maar dan wel van *iedereen* die bij een site betrokken is.
Even credit geven aan waar ik de (fantastische) oneliner vandaan heb.
Brent “NetNewsWire” Simmons heeft hem verzonnen (denk ik) en wel hier http://inessential.com/2007/04/25/thoughts_about_large_cocoa_projects