Ik zal beginnen met eens even flink generaliseren en vaststellen dat er twee hoofdredenen zijn waarom mensen zich in het produceren van website storten: ze houden van programmeren (ze zijn technisch) of ze houden van grafisch ontwerp op het web (ze zijn artistiek).

Interessant genoeg is het tegenwordig goed mogelijk om tegelijkertijd technisch én artistiek te zijn. Je kunt je oude trauma’s van de middelbare school gedag zeggen, toen de artistiekelingen verlangend keken naar de mensen met de wiskundeknobbels en andersom.

Iedereen die goede ontwerpvaardigheden heeft kan de webstandaarden gebruiken om aantrekkelijke websites te maken die voldoende functioneren voor bijna alle bezoekers en uitstekend functioneren voor de meeste bezoekers, inclusief de bezoekers met een handicap.

Dit artikel zal een aantal details onderzoeken van het samenspel tussen toegankelijkheid en webontwerp. We zullen er achter komen dat er nieuwe methodes zijn om te verzekeren dat zelfs websites die grafisch ontwerp zeer serieus nemen adequaat functioneren voor mensen met een aantal relevante handicaps. En onderweg zullen we ontdekken waarom het noodzakelijk is dat sommige bezoekers het grafisch ontwerp dat je hebt gekozen volledig achter zich kunnen laten – hoewel dat nog niet betekent dat je het grafisch ontwerp voor alle andere bezoekers kwijt bent.

De goeie ouwe tijd

Misschien herinner je je het duistere verleden van het websitebouwen. Lang geleden was het prima om welk soepzooitje van HTML dan ook te gebruiken, zo lang het in onze favoriete browser maar getoond werd zoals we het bedoelden. (We hebben trouwens nogsteeds onze favoriete browsers, maar we hebben daar nu wel betere redenen voor.) Om het er allemaal goed uit te laten zien strooiden we kwistig met wat we nu presentatie-elementen noemen, waaronder font en de favoriet: blink. Als het maar werkt, nietwaar?

In deze tijd van webstandaarden weten we hoe onwenselijk onze oude manier van coderen was. Pagina’s waren te zwaar, structuur en uiterlijk waren niet gescheiden, HTML die het prima deed in de ene browser zorgde er voor dat een andere browser zo waar crashte. We weten dat nu allemaal en we hebben zelfs een lekker gemene term voor dat soort code: tag soup. Maar een aantal andere feiten zijn nog niet zo doorgedrongen:

1. De toegankelijkheid voor mensen met een handicap was veel slechter in die tijd. Als de browsers al door die code-rommel moesten waden om er achter te komen hoe het vertoond moest worden, kun je je voorstellen hoe veel moeite het kostte om diezelfde code om te zetten in gesproken woord of Braille. (We wisten toen overigens amper wat screen readers waren, ondanks dat ze in ieder geval al sinds 1989, (toen OutSpoken voor de Macintosh uitgevonden werd) op de markt waren.)
2. Maar zodra het hele concept van toegankelijk internet breder bekend werd – dat moment was waarschijnlijk in 1999, toen de Web Content Accessibility Guidelines 1.0 (WCAG) gepubliceerd werden – schoten we door naar de andere kant. Sommige ontwikkelaars en een groot aantal voorstanders van toegankelijkheid besloten dat zeer grafische sites ontoegankelijk waren puur door de plaatjes. Het was gemakkelijk om artikelen te vinden die aanbevolen om alternatieve pagina’s te maken met alleen tekst, die zogenaamd beter toegankelijk waren of in ieder geval gemakkelijker te gebruiken voor blinde mensen. (Ik schreef zelf een artikel met ongeveer die boodschap voor een krant in 1995.)
3. Terwijl wij druk aan het doorschieten waren uit naam van blinde mensen, vergaten we dat er ook mensen met andere handicaps zijn die het web gebruiken, en dat veel van die mensen uitstekend kunnen zien, dank u beleefd. Ze waarderen, verwelkomen en verwachten goed grafisch ontwerp net zo zeer als andere ziende mensen doen. Bovendien gooiden we slechtzienden in soorten en maten op één hoop met de blinden.

En zo gingen we in een periode van slechts twee jaar rond de eeuwwisseling van een situatie geheel zonder regels via de realisatie dat er toch wel wat nuttige regels waren (zoals WCAG) naar de vergissing om uit te maken dat die regels coûte que coûte moesten worden toegepast op visueel rijke websites.

Vandaag

We kunnen naar onszelf rond 1999 terugkijken zoals provinciaaltjes die het helemaal zijn gaan maken in de stad terugkijken op de tijd dat ze nog boertjes van buut’n waren. We denken niet graag meer terug aan hoe suf en ordinair we toen waren. Een beetje te veel te strakke lichtblauwe spijkerbroeken op onze oude feestfoto’s. Wat te veel font tags die rondspoken in ons verleden. We aten te veel kliekjes terwijl we naast het aanrecht stonden en gebruikten te veel “Best viewed in Netscape Navigator” banners op onze sites.

Zullen we daar dan nu maar niet meer over beginnen? Nu zijn we toch volwassen en verstandig. Wij begrijpen het concept van webstandaarden.

1. We weten nu dat we niet zomaar wat HTML in een tekstbestand moeten gooien (zo lang het er maar redelijk uitziet in de browser die toevallig onze favoriet is), maar dat er nu eenmaal verschillende smaken van valide HTML zijn die we kunnen gebruiken. We knobbelden uit wat “valide HTML” was, hoewel er nauwelijks tutorials over het onderwerp waren (1, 2, 3, 4, 5, 6) en het bijna onmogelijk uit te leggen is aan mensen die niet met HTML werken. (De beste manier om het uit te leggen is nog wel om te zeggen dat “ ‘Valide HTML’ zoiets is als ‘grammaticaal correcte HTML.’ ”)
2. En we gebruiken niet alleen valide HTML, maar ook valide semantische HTML, waarin we HTML-elementen – alleen sufferds gebruiken nog de term “tags” tegenwoordig – uitkiezen gebaseerd op wat ze werkelijk betekenen in plaats van hoe ze er uit zien in een browser. We leerden hoe we headings, paragrafen, plaatjes (nou ja, die kenden we al), lists en andere componenten van onze pagina’s konden onderscheiden en gaven ze een correcte “markup”. We leerden niet alleen het verschil tussen kasjmier en nylon, we leerden hoe we onze kasjmier sjaals moesten combineren met onze handschoenen en tasjes.
3. Maar diep van binnen schamen we ons voor het feit dat er een aantal dingen uit ons ordinaire verleden zijn die we toch nog wel leuk vinden –singletjes van Dead or Alive of Wham! bijvoorbeeld, of waanzinnig cool uitziende websites. En we maken ons zorgen dat anderen in onze club van frisse semantische & valide HTML-makers één blik werpen op de aantrekkelijk uitziende website die we zo bloedig in elkaar gezet hebben en meteen maar aannemen dat er wel tag soup onder de motorkap zal zitten. En niemand wil dat zijn nieuwe beste vrienden op hem neerkijken.

Onze nieuwe vriend CSS

We hebben onderweg nog een paar andere dingen geleerd. We zijn er achter gekomen waarom de andere mensen aan tafel eerder eten kregen in het restaurant dan wij (zij waren niet te krenterig om een voorafje te bestellen, lieverd). We zijn er achter gekomen hoe ontzettend belangrijk katoenkwaliteit is wanneer je beddegoed uitkiest. We weten nu ook dat de ingenieur genaamd HTML getrouwd is met een zeer gerespecteerde en hippe interieurontwerpster: CSS.

’Tuurlijk, hij kan die vloerbalken zo aan elkaar timmeren dat oma niet op gruwelijke wijze omkomt in een instortend gebouw, maar als je het wilt hebben over gordijnen, nou, stuur hem dan maar naar de kelder waar hij lekker met zijn modeltreinen kan gaan spelen terwijl zij zich bezighoudt met wat echt belangrijk is.

Het cascading stylesheet – zelfs de naam klinkt al elegant, als één van die neologismen de beroemde moderedactrice Mrs. Diana Vreeland bedacht tijdens vergaderingen over nieuwe ideeën voor reportages – is een apart bestand dat die brute browser echt zijn plek laat weten. Het CSS-bestand draagt de browser op om de HTML-elementen te laten zien (of te “presenteren”) op precies die manier die de ontwerper bedoelde.

Nu hebben we het over echte macht! Je hebt de botten en de lichaamsstructuur van het filmsterretje (de HTML) en nu kun je haar aankleden in welke glamoureuze, glimmende, laag-uitgesneden avondjurk je maar wilt (de CSS). Je kunt de structuur (of de content) van de presentatie scheiden, zoals ze dat noemen.

Maar laten we gehandicapte mensen hiermee in de kou staan? In sommige gevallen wel, ja.

CSS voor toegankelijkheid

Het World Wide Web Consortium – onze neefjes van het platteland – hebben een fijn document over CSS en toegankelijkheid geproduceerd, maar eigenlijk vertelt het je weinig nuttigs. Het lijkt weinig van doen te hebben met grafisch ontwerp, zoals we ook wel zouden verwachten van onze neefjes, die ons steeds weer laten krimpen van gène met hun getoupeerde haar en hooggehakte laarzen met franjes als ze ook familiegelegenheden bezoeken.

Het lijkt er niet op dat CSS zo veel van doen heeft met toegankelijkheid, aangezien we allemaal steeds te horen krijgen dat valide HTML belangrijker is. Maar als je een grafisch ontwerper bent die webstandaarden toepast is het toch mogelijk om uiteindelijk een pagina te produceren die voor sommige mensen met een handicap moeilijk of zelfs onmogelijk te gebruiken is.

Blindheid

Voor iemand die geheel blind is of zodanig slechtziend dat hij eigenlijk bijna niets ziet is jouw werk als webdesigner bijna irrelevant. Je website wordt bezocht door middel van een screen reader (voorleessoftware), wat wil zeggen dat de bezoeker de tekst voorgelezen krijgt en/of meeleest in Braille. Daar zijn geen zichtbare zaken bij betrokken.

Je hoeft je er niets van aan te trekken dat de blinde bezoeker je prachtige grafisch ontwerp niet kan zien. Ze kunnen namelijk helemaal niets zien. Je denkt misschien dat ze een heleboel missen, en sommige blinde mensen denken dat misschien ook, maar er is niet veel dat jij daar als webdesigner aan kunt doen.

Maar je kunt hier alleen zo blasé over doen als je wél valide semantische HTML gebruikt. Als je ouderwetse tag soup markup gebruikt, zal een blind persoon die gebruik maakt van een screen reader zeer veel moeite moeten doen om zich een weg door je pagina’s te worstelen. Headings, links, lists en dergelijke structuren (ja, zelfs tabellen) kunnen intelligent verwerkt en gelezen worden in hedendaagse screen readers. Als je ze op de juiste manier gebruikt, maakt het nog maar weinig verschil dat de bezoeker je grafisch ontwerp niet kan zien.

Er zijn echter een aantal uitzonderingen, waarvan sommigen nogal onverwacht zijn.

Navigatie

Je weg vinden door de pagina wordt behoorlijk belangrijk op het moment dat je de pagina serieel (één item tegelijk) in plaats van de alles-tegelijk-zichtbaar methode die ziende mensen gewend zijn. Zeer complexe pagina-layouts, met meedere navigatiebalken en tientallen links zijn in veel gevallen niet nodig en zijn vervelend voor gebruikers van screen readers. Dit is zo’n geval waarin betere gebruiksvriendelijkheid ook een betere toegankelijkheid oplevert.

Volgorde van de code

Screen readers doen hun werk bovenop een browser (bijna zonder uitzondering Internet Explorer for Windows). De belangrijkste screen readers zijn afhankelijk van de manier waarop de browser CSS interpreteert, maar ze hebben ook nog hun eigen interpretatie van CSS. Onder sommige omstandigheden – nogal hypothetisch, en niemand kan een duidelijk geval aangeven waarin het ook daadwerkelijk gebeurt – zouden floating CSS elementen op een vreemde manier gelezen kunnen worden door screen readers, omdat de volgorde in HTML-code belangrijk is in zulke layouts. Eigenlijk is dit een reden waarom er betere screen readers zouden moeten komen, maar totdat die verkrijgbaar zijn is dit ook jouw probleem – ten minste in theorie.

Alternatief voor plaatje

Als je CSS gebruikt om een plaatje te vervangen door tekst (in plaats van de gouwe-ouwe methode van de <img alt="">) is er geen uitgewerkte methode die garandeert dat de tekst die als alternatief voor het plaatje wordt gebruikt altijd wordt voorgelezen door de screen reader. (Dat heeft iets te maken met de manier waarop screen readers omgaan met visibility: hidden of zelfs display: none in CSS. Het voorstel voor een reader media type kan daar misschien in de toekomst verandering in brengen.) Voor sommige plaatjes zal het niet uitmaken dat ze onzichtbaar zijn voor screen readers, en voor sommige anderen zal het juist wel cruciaal zijn; aan jou de taak om uit te maken waar dat het geval is.

Verborgen tekst

Om redenen die lijken op die in het geval van de tekst-alternatieven voor plaatjes is er ook nog een ander probleem. Als je visibility: hidden of zelfs display: none gebruikt om sommige stukken tekst onzichtbaar te maken, zullen sommige screen readers de tekst wel voorlezen of in Braille weergeven. Onzichtbare tekst wordt vaak gebruikt om pagina’s vol te proppen met commerciële keywords, maar er zijn ook een aantal respectabele toepassingen van deze techniek, zoals browser-upgrade verzoeken en het laten zien van veranderingen in specificatie-documenten van het W3C.

Visuele handicaps

Helaas is het zo dat sommige dingen die heel aantrekkelijk zijn voor grafisch ontwerpers het online leven van mensen met een visuele handicap moeilijk maken.

Kleurencombinaties

Er zijn hierbij twee groepen waarover we ons zorgen moeten maken: mensen met aangeboren kleurenblindheid en mensen met bepaalde vormen van slechtziendheid, die op een andere manier moeilijk kleuren kunnen zien dan de groep van kleurenblinden.

Mensen die kleurenblind zijn zien altijd kleur. (De enige belangrijke uitzondering is een aandoening genaamd achromatopsie, die naar schatting 0.03% van de mensen treft. Deze mensen zien – voor zo ver we dat kunnen bepalen – alles in grijstinten.) Het probleem is meer dat er een aantal kleuren is die kleurenblinden door elkaar halen. Rood en groen zijn het standaard paar dat voor onduidelijkheid zorgt, maar er zijn veel rood-achtige en groen-achtige tinten die verwarring opleveren. De aandoeningen die de moeite met het onderscheid rood/groen veroorzaken zijn protanopie en deuteranopie, die beiden ook minder ernstige vormen hebben: protanomalie en deuteranomalie.

Er is een veel kleiner aantal mensen dat een aandoening heeft waardoor ze het onderscheid blauw/groen moeilijk kunnen maken: tritanopie. Sommigen van hen ontwikkelen de aandoening tijdens hun leven, terwijl protanopie en deuteranopie meestal erfelijk zijn. Ongeveer 4 tot 8% van de bevolking in Westerse landen (de meesten van hen mannen) hebben één of andere vorm van afwijkend kleurenzien.

Kleurenblindheid leidt tot symptomen die binnen een beperkt aantal patronen vallen. Het is niet zo moeilijk om regels te bedenken om tegemoet te komen aan deze patronen. (Ik heb zelf een heel hoofdstuk in mijn boek over dit onderwerp geschreven.) Een webdesigner hoeft niet zo veel te doen om deze problemen te ondervangen. Je moet er gewoon voor zorgen dat kleuren die door elkaar gehaald kunnen worden niet op een mogelijk verwarrende manier gebruikt worden. Je kunt prima rood en groen of blauw en groen op dezelfde pagina gebruiken, je moet ze alleen niet naast elkaar zetten als je van de bezoeker verwacht dat hij ze uit elkaar kan houden. (En zelfs dat kun je nog doen als er andere zaken zijn waardoor het onderscheid duidelijk is – rode en groene knoppen of tabs naast elkaar zou best kunnen als de letters die je gebruikt maar voldoende uitsluitsel geven.)

Slechtziendheid

Alles wordt een stuk ingewikkelder wanneer we te maken hebben met slechtzienden – mensen die nog beschikken over een gedeelte van hun gezichtsvermogen. Wat deze mensen nodig hebben verschilt enorm, iedere persoon is weer anders. Sommige aandoeningen, zoals de vergeling van de iris door ouderdom, zorgen voor een verandering in het waarnemen van kleuren.

In zekere zin is dit een nachtmerrie-scenario voor webontwerpers. Ja, je bent zo’n slimmerik die de marketing slogans van HTML en CSS wel kan dromen (inhoud en presentatie scheiden enzo), en je kunt best leven met het idee dat blinden je opmaak helemaal niet zullen zien, maar nu hebben we die slechtzienden die je ontwerp tot zich zullen nemen op een manier die er een vreselijke parodie van wat jij had bedoeld van zal maken.

Slechtzienden moeten de volgende dingen zelf kunnen instellen:

1. Font, grootte, en spatiëring
2. Voorgrond- en achtergrondkleuren
3. Volgorde van de items (layouts met meerdere kolommen zijn niet handig)
4. Navigatie (wanneer alle letters enorm groot zijn is het moeilijk om door te hebben waar je je bevindt op een pagina of op het web)

Dit is een heel nieuwe uitdaging voor webdesigners, maar het goede nieuws is dat slechtzienden wel degelijk geholpen kunnen worden – en dat je in een groot aantal gevallen nogsteeds behoorlijk veel invloed kunt uitoefenen op hoe het ontwerp er uitziet.

Stylesheet-switchers

Bij het bouwen van websites kun je zo veel verschillende CSS-bestanden gebruiken als je maar wilt om alternatieve stylesheets aan te bieden, speciaal voor slechtzienden. Je kunt één of meer alternatieve stylesheets neerzetten die bijvoorbeeld zeer basale navigatie plaatsen bovenaan de pagina (“U bent hier” broodkruimels of dergelijke oplossingen), en ook veel grotere fonts gebruiken in lichte kleuren op zeer donkere achtergronden (gebroken wit of geel op een zwarte achtergrond werkt goed). Iemand die een dergelijke presentatie prefereert of nodig heeft kan eenvoudig de bijbehorende stijl selecteren.

Je hebt een aantal opties om een interface te geven aan je stylesheet-switcher:

Keuzeknoppen op de pagina

Aangezien de meeste slechtzienden geen gebruik zullen maken van een browser die ze de optie geeft om stylesheets te wisselen (zoals Mozilla), moet je er voor zorgen dat je je bezoekers iets in handen geeft op je pagina (knoppen, links) waarmee ze automatisch stylesheets kunnen wisselen. Hier zitten echter nog wel wat haken en ogen aan:

• De meeste ontwerpers gebruiken dit soort knoppen alleen om de fontgrootte een klein beetje te veranderen; het is zeldzaam om er één te vinden die het hele uiterlijk van de pagina verandert.
• De knoppen zijn vaak klein en onopvallend, omdat ontwerpers dat soort dingen niet al te veel in het oog wil laten springen.
• De gebruikte terminologie varieert enorm, net zoals de plaats binnen de pagina waar de knoppen neergezet worden. Denk er aan dat we te maken hebben met bezoekers die slecht zien; op dit moment moeten ze goed zoeken naar deze knoppen, áls de knoppen überhaupt al in de pagina staan.

Voorkeursinstellingen

Misschien wel de allerbeste methode is om een aparte pagina te maken waar bezoekers hun voorkeuren voor de presentatie kunnen instellen, die dan vervolgens in een cookie opgeslagen worden voor latere bezoeken. Een echt geavanceerde site zal de bezoeker de optie bieden om te kiezen uit een groot aantal verschillende fontgroottes (of de optie om direct een puntgrootte in te geven) en diverse kleurencombinaties. Dan is er nog het probleem dat deze instellingspagina toegankelijk gemaakt moet worden voor de slechtziende persoon. Dit zou je waarschijnlijk het beste kunnen doen door een pagina te maken met grote, lichtgekleurde tekst op een donkere achtergrond in één enkele kolom. (In de verre toekomst zal misschien de nieuwe CC/PP aanbeveling van het W3C algemeen ingevoerd worden zodat deze voorkeuren voor iedere bezoeker opgeslagen kunnen worden.)

Ik heb een lange (maar lang niet complete) lijst van sites die stylesheetswitchers gebruiken opgesteld. Je zou kunnen proberen om sommige van deze oplossingen na te volgen.

Voor-en-na vergelijking

Maar nu de echte situatie: als je de toegankelijkheid van je site wilt verbeteren voor slechtzienden terwijl je wel het grafisch ontwerp in tact wilt houden voor mensen met normaal gezichtsvermogen, hoe ziet je site er dan uit voor en na het updaten?

Voor

1. Valide HTML en CSS
2. Maakt niet uit welk grafisch ontwerp
3. Gebruik geen kleuren die bezoekers gemakkelijk kunnen verwarren (zoals rood en groen en blauw en groen) op potentieel verwarrende manieren
4. Een layout met meerdere kolommen, als je dat wilt
5. Liefst een zeer duidelijke manier om van stylesheet te wisselen of voorkeuren in te stellen

Na

1. Extra stylesheets (met betekenisvolle titles bij de link: die worden namelijk getoond in de Use Style menu-optie van Mozilla.
2. Eén of meer opties om met veel contrast te werken (lichte letters op donkere achtergrond)
3. Grotere fonts (maar zorg er wel voor dat de line-height proportioneel blijft – em, ex, of % zijn bruikbare eenheden)
4. De optie om alles in één kolom te laten zien, met de belangrijke navigatie bovenaan en de “content” direct daarna

Al deze dingen zouden samengevoegd kunnen worden in een pagina met voorkeuren die opgeslagen worden in een cookie. Die pagina zou dezelfde richtlijnen moeten volgen.

Wie voert dit goed uit?

Eigenlijk zijn er niet zo veel mensen die zelfs maar proberen om dit goed te doen, maar ik ben er in geslaagd om een bescheiden lijst samen te stellen:

1. Sjoerd Visscher
2. Handicapzero.org
3. glish.com
4. OpenWeb
5. Alp Uçkan
6. Frost Digital
7. Adactio
8. KSPope

Moet de browser dit eigenlijk niet oplossen?

Als we het hebben over bezoekers die er behoefte aan hebben om je website te bekijken en desnoods te veranderen, zouden die bezoekers dan niet zelf de verantwoordelijkheid moeten nemen om de opties van hun eigen browsers beter te leren kennen?

De meeste moderne browers geven je de mogelijkheid om lettertype, grootte en (ten minste voor links) kleur te wijzigen. Sommige browsers laten toe dat je een voorkeur voor een fontgrootte instelt, of zelfs een minimum fontgrootte. Het probleem is hier dat, ondanks wat de Web Content Accessibility Guidelines misschien suggereren, je niet redelijkerwijs kunt verwachten dat een website bruikbaar blijft bij elke willekeurige vergroting. Je kunt een pagina die je aan het lezen bent niet op blijven blazen en denken dat hij een bruikbaar geheel blijft. (Niemand die professioneel betrokken is bij toegankelijkheid lijkt dit toe te willen geven, maar wanneer je luistert naar onderzoekers die zich bezighouden met het gezichtsvermogen hoor je heel wat meer.) Vanaf een bepaald punt zul je de layout van de site aan moeten passen om er voor te zorgen dat hij nog correct werkt bij vergroting.

Dit betekent ook dat hulptechnologieën zoals schermvergroters niet alle problemen kunnen oplossen. Een website met meerdere kolommen en een ingewikkeld grafisch ontwerp bezoeken met vergrotingssoftware is als het scrollen door microfilms of het lezen van een landkaart van de veldtochten van Napoleon door een loep: als je het geheel wilt overzien dan kan dat, maar dan zul je de tekst niet kunnen lezen. Je zit vast aan de enorme vergotingen van kleine stukjes van de pagina.

Desalniettemin is het gebruik van software die de browserinstelling verandert en/of de scherminhoud vergroot de norm geweest voor slechtzienden. Het probleem zou al veel kleiner zijn als sites de mogelijkheid zouden bieden om de content in één enkele kolom te presenteren. En nu hebben ontwerpers die optie.

Het probleem is dat echte voorbeelden met een lantaarntje gezocht moeten worden. Een voorbeeld: de standaard stijl van OpenWeb heeft meerdere kolommen, maar om de kolommen uit te zetten moet je ook andere uiterlijke kenmerken uitzetten, zoals grote lichtgekleurde letters op een donkere achtergrond.

En er zijn ook al geen écht goede voorbeelden voor navigatie ten behoeve van slechtzienden. Dit is het soort gebruiksvriendelijkheid dat echt getest moet worden en waar we niet maar wat naar moeten raden. Misschien moeten we wachten totdat Jakob Nielsen een rapport over dit onderwerp schrijft.

De nieuwe avant-garde

Deze discussie geeft jou, de webdesigner die al standards compliant is, een nieuwe serie problemen om over na te denken. Je wist waarschijnlijk al iets over toegankelijkheid, maar nu heb je een nieuw soort variatie van je site die je kunt produceren met stylesheets – een versie toegesneden op slechtzienden, met en zonder kleurenblindheid.

Dit zijn nieuwe en experimentele technieken. Ze zijn nog niet getest met echte slechtziende mensen en een aantal van de details zal waarschijnlijk veranderen wanneer we meer gegevens uit de praktijk binnenkrijgen. Maar om die gegevens bij elkaar te krijgen hebben we wél echte websites nodig in de praktijk van alledag waarvan de ontwerpers bovenstaande technieken gebruiken. Dit is een geweldige kans voor jouw websites om deel uit te maken van de nieuwe avant-garde!

Verantwoording

Veel van de methoden die in dit artikel beschreven worden zijn overgenomen uit een presentatie door Aries Arditi op de conventie van de American Academy of Optometry in Dallas, op 6 december 2003.

• Home
• Artikelen
• Colofon