Arteveldehogeschool. Eindwerk. Web Accessibility. Rich Internet Applications toegankelijk maken voor gebruikers met een functiebeperking

Arteveldehogeschool Eindwerk

Web Accessibility Rich Internet Applications toegankelijk maken voor gebruikers met een functiebeperking

Auteur: Sven Peremans

Externe promotor: Roel Van Gils (AnySurfer) Interne promotor: Olivier Parent (Arteveldehogeschool)

24 augustus 2009 Eindwerk voorgedragen door Sven Peremans tot het behalen van het diploma Bachelor in Grafische en Digitale Media afstudeerrichting Multimedia.

Arteveldehogeschool Eindwerk

Web Accessibility Rich Internet Applications toegankelijk maken voor gebruikers met een functiebeperking

Auteur: Sven Peremans

Externe promotor: Roel Van Gils (AnySurfer) Interne promotor: Olivier Parent (Arteveldehogeschool)

24 augustus 2009 Eindwerk voorgedragen door Sven Peremans tot het behalen van het diploma Bachelor in Grafische en Digitale Media afstudeerrichting Multimedia.

i

Woord vooraf Dit eindwerk is een hedendaags overzicht van de technische mogelijkheden om tot een toegankelijk internet te komen, met een specifieke focus op HTML 5 en WAI-ARIA. Omdat beide specificaties nog niet gefinaliseerd zijn door het W3C en nog maar matig worden aanvaard door browsers, kan de informatie in dit eindwerk vlug verouderd zijn. De bijlagen bevatten een lijst met betrouwbare websites waarop de laatste evolutie rondom de standaarden en mogelijkheden te volgen zijn. Omdat ik uitzie naar een professionele loopbaan als webontwikkelaar, leek het mij belangrijk de problematiek van webtoegankelijkheid te onderzoeken. De oplossingen voor deze materie lopen meestal parallel met de nieuwste technieken om websites te maken, wat het onderzoek extra boeiend maakte. Bovendien is door de toenemende vergrijzing de problematiek een booming business geworden die zeker niet over het hoofd mag worden gezien. Graag wil ik mijn externe promotor Roel Van Gils, toegankelijkheidsdeskundige en webdeveloper bij AnySurfer, bedanken voor zijn steun, advies en beschikbare tijd. Verder richt ik mijn dank ook aan mijn interne promotor Olivier Parent, mijn ouders en mijn vriend voor hun kritisch oog en raadgevingen omtrent vorm en schrijfstijl. — Sven Peremans

ii

Inleiding De wereld digitaliseert. Men verkiest steeds meer om informatie digitaal op te slaan en deze via verschillende kanalen aan te bieden. Een van deze kanalen is het internet. Dit medium is bij oorsprong zeer democratisch: de informatie dient voor elke persoon op aarde op elk moment van de dag beschikbaar te zijn. Tegenwoordig verschaffen websites meer en vaak betere informatie dan de klassieke media, officiële instanties, boeken en encyclopedieën. Kranten en televisiekanalen verspreiden tegelijkertijd meer oppervlakkig nieuws. Voor het uitdiepen van een onderwerp is minder ruimte voorzien. Men dient zich te richten tot de website van de redactie. Ook voor belangrijke administratieve procedures is het internet vaak nog de enige uitweg. Om naar de Verenigde Staten te reizen is men sinds januari 2009 verplicht vooraf een formulier in te vullen op een speciale website om goed gedrag en zeden aan te tonen. Zoniet komt men het land niet binnen. Elk individu zonder een bezwaarlijk verleden of slechte bijbedoelingen moet onmiddellijk via het formulier toestemming krijgen. Dergelijke sites tonen aan dat het internet niet meer enkel een speeltuin is voor wetenschappers of jongeren, maar een essentieel en nuttig onderdeel van het leven. Datzelfde internet evolueert en vernieuwt bovendien aan een hoog tempo. De websites worden gebruiksvriendelijker door nieuwe technologieën en ook andere apparaten, zoals de smartphone, zijn erop gefocust. Voor personen met een handicap is het internet een geschenk uit de hemel. Een rolstoelpatiënt hoeft niet meer naar de winkel te gaan en zich er laten begeleiden om producten uit de rekken te nemen. Hij stelt simpelweg zijn winkelkarretje samen via de website van het warenhuis en laat de artikelen aan huis leveren. Via sociale netwerken blijft hij in contact met familieleden en vrienden, net zoals jongeren dit doen. Hij of zij hoeft zich geen zorgen meer te maken over privacy bij het bankieren, dit kan nu indivueel op een website zonder dat iemand moet helpen. Slechtzienden kunnen elk boek of stuk krant dat digitaal wordt aangeboden laten voorlezen door speciale software. Ze hoeven meestal geen dure braille-lezer of braille-boek meer aan te kopen. Ook oudere mensen profiteren mee. Hoewel de huidige senioren meestal niet met computers overweg kunnen, zullen de ’nieuwe ouderen’ wel het principe van een muis begrijpen (indien dit laatste voorwerp nog zal bestaan). De vereenvoudiging van alledaagse rituelen is uiteraard ook een steun bij de financiële rompslomp van de vergrijzing. In de toekomst kan het internet nog veel meer aanbieden. In het ideale geval zou een website ons visueel en auditief moeten rondleiden doorheen de informatie. Het zou een 3D-voorstelling moeten worden met auditieve elementen, waarbij de belangrijkste informatie steeds vooraan in beeld wordt gebracht en bijkomende inhoud ’binnen handbereik’ is. Zover zijn we echter nog niet en een website wordt, zoals we die kennen, in 2D aangeboden via een plat scherm. De informatie staat structureel geordend naargelang de beschikbare plaats en technologie. Door deze beperking is niet alle informatie op een ’humane’ manier gepresenteerd

iii en moet er genavigeerd worden doorheen het web zonder de zekerheid dat het gewenste doel wordt bereikt. Voor mensen met een gezonde fysieke en mentale toestand is dit geen probleem. Maar nemen we nu het geval van de toelatingsprocedure voor de V.S. Iemand met een beperkt gezichtsvermogen kan misschien een computer gebruiken, maar hoe zal hij of zij het formulier zonder fouten invullen? De registratieprocedure wordt niet stap per stap getoond, maar is opgebouwd uit 1 groot ingewikkeld web van formuliervelden. Hoe gaat de persoon van Naam naar Adres, hoe keert hij terug bij een vergissing en hoe maakt hij zichzelf niet bekend als terrorist door het verkeerde bolletje aan te vinken? Verschillende organisaties - waaronder de pioniers van het internet - vragen zich daarom reeds lange tijd af hoe we websites kunnen maken die toegankelijk zijn voor elk medium en elke persoon. In het Engels vertaalt dit probleem zich in de term web accessibility. We moeten voorkomen dat het nobele doel van het internet (informatie voor iedereen toegankelijk maken) zich niet tegen zichzelf keert.

Overzicht ◦ Hoofdstuk 1 bespreekt web accessibility in het algemeen: de begrippen, probleemstellingen, soorten handicaps, standaarden, richtlijnen en soorten hulpmiddelen. ◦ Hoofdstuk 2 geeft tips voor het gebruik van HTML, CSS, JavaScript en behandelt de nieuwste technologieën ter bevordering van web accessibility. ◦ Hoofdstuk 3 bespreekt kort accessibility in multimediatoepassingen zoals Flash, Flex, SMIL en video. ◦ Hoofdstuk 4 onderzoekt hoe enkele nieuwe technologieën zoals ARIA, aangehaald in de voorafgaande hoofdstukken, momenteel in browsers kunnen worden toegepast.

iv

Conventies in dit eindwerk ◦ Dit eindwerk richt zich voornamelijk op oplossingen voor personen met een visuele handicap, omdat deze groep de meeste problemen ondervindt op het internet. Gebruikers met andere handicaps profiteren meestal mee van deze oplossingen. Het hoofdstuk over multimedia bevat een deel over ondertiteling voor gebruikers met een auditieve beperking. ◦ Voor een aantal Engelstalige computertermen bestaat er geen toepasselijke Nederlandse vertaling. Het woord tags wordt bijvoorbeeld gebruikt voor gereserveerde woorden in een programmeertaal of elementen van XML of HTML. Op andere plaatsen worden deze kortweg omschreven als ’elementen’. Ook de termen accessibility en toegankelijkheid worden door elkaar gebruikt. ◦ Een basiskennis van HTML en CSS is vereist om dit werkstuk te begrijpen. ◦ De voorbeeldcode die tussen de theorie gestoken is, wordt zoveel mogelijk leesbaar afgedrukt. Toch zijn sommige tekens mogelijks vervormd vanwege de beperkingen van het opmaakprogramma LaTeX. Daardoor worden in dit eindwerk de dubbele aanhalingstekens van HTML voor de waarden van attributen vervangen door enkele aanhalingstekens. Bij het overnemen van de voorbeelcode moet hier dus rekening mee gehouden worden.

Inhoudsopgave Woord vooraf

i

Inleiding

ii

Veelgebruikte begrippen

4

1 Accessibility: een overzicht 1.1 Definitie . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Web accessibility . . . . . . . . . . . . . . . . . 1.1.2 Accessibility en usability . . . . . . . . . . . . . 1.1.3 Het belang van web accessibility . . . . . . . . 1.1.4 Het belang van web accessibility voor bedrijven 1.1.5 Nooit iedereen . . . . . . . . . . . . . . . . . . 1.2 Mensen met een handicap . . . . . . . . . . . . . . . . 1.2.1 Soorten handicaps . . . . . . . . . . . . . . . . 1.2.2 Visuele beperkingen . . . . . . . . . . . . . . . 1.2.3 Auditieve beperkingen . . . . . . . . . . . . . . 1.2.4 Motorische beperkingen . . . . . . . . . . . . . 1.2.5 Cognitieve beperkingen . . . . . . . . . . . . . 1.3 Organisaties . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 W3C . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 AnySurfer . . . . . . . . . . . . . . . . . . . . . 1.3.3 WebAIM . . . . . . . . . . . . . . . . . . . . . 1.4 Standaarden en guidelines . . . . . . . . . . . . . . . . 1.4.1 Webstandaarden . . . . . . . . . . . . . . . . . 1.4.2 Richtlijnen . . . . . . . . . . . . . . . . . . . . 1.5 Wetgeving . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Verenigde Staten . . . . . . . . . . . . . . . . . 1.5.2 Europa . . . . . . . . . . . . . . . . . . . . . . 1.5.3 België . . . . . . . . . . . . . . . . . . . . . . . 1.6 Screen readers . . . . . . . . . . . . . . . . . . . . . . . 1.6.1 Werken met een screen reader . . . . . . . . . . 1.6.2 Beperkingen van screen readers . . . . . . . . . 1.6.3 Stand alone applicaties . . . . . . . . . . . . . 1.6.4 Extensies voor browsers . . . . . . . . . . . . . 1.6.5 Speciale browsers . . . . . . . . . . . . . . . . .

v

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 6 6 6 6 7 8 9 9 9 10 10 10 12 12 12 13 13 13 15 15 15 16 16 17 17 18 19 22 24

INHOUDSOPGAVE 1.7

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

26 26 26 27 28

2 HTML en Ajax 2.1 HTML richtlijnen . . . . . . . . . . . . . . . . . . . 2.1.1 Keep it simple . . . . . . . . . . . . . . . . 2.1.2 Gebruik de juiste HTML code . . . . . . . 2.1.3 Navigatie . . . . . . . . . . . . . . . . . . . 2.1.4 Tekst . . . . . . . . . . . . . . . . . . . . . 2.1.5 Formulieren . . . . . . . . . . . . . . . . . . 2.1.6 Afbeeldingen . . . . . . . . . . . . . . . . . 2.1.7 Tabellen . . . . . . . . . . . . . . . . . . . . 2.1.8 Links . . . . . . . . . . . . . . . . . . . . . 2.1.9 Frames . . . . . . . . . . . . . . . . . . . . 2.2 CSS richtlijnen . . . . . . . . . . . . . . . . . . . . 2.2.1 Voordelen van CSS t.o.v. web accessibility . 2.2.2 Nog enkele CSS hints . . . . . . . . . . . . 2.3 HTML 5 . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Veranderingen t.o.v. HTML 4 . . . . . . . . 2.3.2 HTML 5 of XHTML 2 ? . . . . . . . . . . . 2.4 WAI-ARIA . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Live regions . . . . . . . . . . . . . . . . . . 2.4.2 ARIA en tabindex . . . . . . . . . . . . . . 2.4.3 ARIA en screen readers . . . . . . . . . . . 2.4.4 Ondersteuning in HTML . . . . . . . . . . 2.4.5 Het validatie probleem . . . . . . . . . . . . 2.4.6 Browsers die ARIA ondersteunen . . . . . . 2.4.7 Screen readers die ARIA ondersteunen . . . 2.4.8 ARIA en HTML 5 . . . . . . . . . . . . . . 2.4.9 Alternatief voor live regions . . . . . . . . . 2.5 JavaScript richtlijnen . . . . . . . . . . . . . . . . . 2.6 JavaScript frameworks . . . . . . . . . . . . . . . . 2.6.1 Voordeel van JavaScript frameworks . . . . 2.6.2 BBC Glow . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29 31 31 31 32 33 34 34 35 37 37 39 39 41 44 44 49 49 51 51 52 52 53 54 54 54 54 56 59 59 59

3 Multimedia en accessibility 3.1 SMIL . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Voordelen van SMIL m.b.t. accessibility 3.1.2 SMIL en andere technologieën . . . . . . 3.2 VoiceXML . . . . . . . . . . . . . . . . . . . . . 3.3 PDF . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Flash . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Enkel toegankelijk in Windows . . . . . 3.4.2 Accessibility panel . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

61 62 62 64 65 67 68 68 69

1.8

Andere hulpmiddelen . 1.7.1 Output devices 1.7.2 Input devices . Test software . . . . . 1.8.1 WAVE . . . . .

vi . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . .

. . . . . . . .

INHOUDSOPGAVE . . . .

69 69 70 70

. . . .

72 73 73 74 74

5 Conclusie 5.1 Meer informatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78 79

Bibliografie

80

Lijst van figuren

84

3.5

3.4.3 3.4.4 Video 3.5.1

Een toegankelijke Flex . . . . . . . . . . . . . . . . . JW FLV Player .

vii interface . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

4 Onderzoek 4.1 NVDA . . . . . . . . . . . . . . . . . . . 4.1.1 De NVDA-toets op Mac . . . . . 4.1.2 Hoe NVDA een webpagina ‘leest’ 4.1.3 NVDA en ARIA . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Bijlagen .1 NVDA . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.1 Belangrijkse sneltoetsen voor webontwikkelaars .2 Fire Vox . . . . . . . . . . . . . . . . . . . . . . . . . . .2.1 Download locatie . . . . . . . . . . . . . . . . . .2.2 Installatie . . . . . . . . . . . . . . . . . . . . . .2.3 Belangrijkse sneltoetsen voor webontwikkelaars .3 JAWS . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.1 Belangrijkse sneltoetsen voor webontwikkelaars .4 IBM Home Page Reader . . . . . . . . . . . . . . . . . .4.1 Belangrijkse sneltoetsen voor webontwikkelaars .5 VoiceOver (Mac) . . . . . . . . . . . . . . . . . . . . . .5.1 Belangrijkse sneltoetsen . . . . . . . . . . . . . .6 Ondersteuning van browsers in screen readers . . . . . .6.1 FireFox 3.5 . . . . . . . . . . . . . . . . . . . . .6.2 Opera 9.5 . . . . . . . . . . . . . . . . . . . . . .6.3 Safari 3 . . . . . . . . . . . . . . . . . . . . . . .6.4 Internet Explorer 7 . . . . . . . . . . . . . . . . .6.5 Internet Explorer 8 . . . . . . . . . . . . . . . . .7 Drag-and-drop . . . . . . . . . . . . . . . . . . . . . . .8 Voorstel onderwerp eindwerk . . . . . . . . . . . . . . .9 Logboek . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

85 86 86 88 88 88 88 89 89 90 90 91 91 92 92 92 92 93 93 94 95 97

Verklarende Woordenlijst Accessible / Toegankelijk Ajax

API

Aria

ARIA-protocol

Client-side scripting

CSS

Volledig bruikbaar voor een doelpubliek Asynchronous JavaScript and XML. Dit is een verzameling van technieken in JavaScript en XML om asynchroon (= zonder een nieuw pagina verzoek) gegevens uit te wisselen met de server. Application Programming Interface. Een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel (meestal in de vorm van bibliotheken) Een HTML-attribuut dat gebruikt wordt voor image-maps. Specifieert een klikgebied. Niet te verwarren met het ARIA-protocol. Accessible Rich Internet Applications. Een protocol opgesteld door W3C dat aangeeft hoe websites toegankelijker kunnen gemaakt worden. Spitst zich vooral toe op equivalente tekst bij multimedia, toegankelijk links en formulieren, en goede HTML structuren. De recentste versie is ARIA 1.0, momenteel nog in ’draft’ modus (nog niet gelanceerd). Het programmeren van dynamische webpagina’s via programmacode die wordt uitgevoerd op de browser van de client. Meestal wordt deze code rechtstreeks ge¨ınterpreteerd en niet gecompileerd naar machinetaal. Vrijwel de enige bekende server-side scriptingtalen zijn JavaScript en Java (deze laatste taal wordt gecompileerd en kan niet communiceren met de HTML-code). Cascading Style Sheets. Een document met enkel opmaakregels die worden toegepast op het DOM van een webpagina of een XMLdocument. 1

Verklarende Woordenlijst

2

CSS 3

De lang verwachte opvolger van CSS 2.

DHTML

Dynamic HTML. Dit zijn attributen die worden gebruikt om acties van een gebruiker op te vangen, zoals het bewegen van de muis over een element (onMouseOut). Document Type van een (X)HTML pagina. Deze verwijst naar het DTD schema dat wordt gebruikt om de code te valideren. HTML validators zoals die van W3C baseren zich op het DTD. De meest gebruikte zijn: strict, loose en transitional. Document Object Model. Dit model is een objectgeoriënteerde benadering van gestructureerde documenten, zoals (X)HTMLbestanden Document Type Definition. Dit is het XML schema dat wordt gebruikt om XML zoals XHTML te valideren op een correcte structuur.

Doctype

DOM

DTD

HTML

HyperText Mark-up Language, de beschrijvende opmaaktaal om webpagina’s mee op te bouwen

jQuery

Een bekend JavaScript framework. Maakt het manipuleren van DOM elementen eenvoudiger dan via traditionele JavaScript.

MIME

Multipurpose Internet Mail Extension, oorspronkelijk voor e-mails bedoeld. Zegt aan de browser van welke type de inhoud van een document is. Voorbeelden van types zijn application/jpeg, text/xml, application/xhtml+xml Microsoft Active Accessibility, een API die aangeboden wordt aan ontwikkelaars van screen readers en andere begeleidende technologieën. Met MSAA kunnen typische Windows onderdelen worden aangesproken.

MSAA


3

Namespace in HTML

Een HTML-document kan worden omsloten met een namespace, die bovenaan in het head-element van de code wordt vermeld. De namespace verwijst naar een technisch document op het internet en laat toe andere soort HTML-tags te gebruiken via een prefix.

RIA

Rich Internet Applications. Dit zijn websites die met behulp van de nieuwste technieken de gebruiker zoveel mogelijk het gevoel van een desktop-applicatie geven.

Semantische code

Code die gebruikt wordt waarvoor het oorspronkelijk gedefinieerd is. Het is bijvoorbeeld semantischer
te gebruiken dan
, omdat h1 een standaard element van HTML is dat speciaal voor titels bedoeld is. Technologieën zoals screen readers weten bij
met zekerheid dat het om een titel gaat. Het programmeren van dynamische webpagina’s via programmacode die wordt uitgevoerd op de server en als resultaat HTML code doorstuurt naar de browser van de client. Bekende server-side scriptingtalen zijn PHP, ASP.NET (C# of VB.NET), Ruby en Python.

Server-side scripting

User interface

Vrij vertaald: een gebruikersinterface, is een geheel van grafische elementen die aan een gebruiker worden aangeboden.

W3C

World Wide Web Consortium. Wereldwijde organisatie die de groei van het World Wide Web promoot en webstandaarden creëert. Web Accessibility Initiative. Een afdeling van het W3C die zich toespitst op de toegankelijkheid van het internet.

WAI


WCAG

WHATWG

XHTML

XHTML 1.0 XHTML 1.1 XHTML 2

XHTML 5

XML

4

Web Content Accessibility Guidelines. Vrijblijvende richtlijnen, opgesteld door het WAI, die beschrijven aan welke voorwaarden een toegankelijke site moet voldoen. Naast de WCAG-richtlijnen, die bedoeld zijn om te functioneren in browsers, heeft WAI ook richtlijnen ontwikkeld voor applicaties zoals authoring tools (bijv. Dreamweaver): Authoring Tools Accessibility Guidelines (ATAG 1.0) en de User Agent Accessibility Guidelines (UAAG) Web Hypertext Application Technology Working Group, een associatie van Apple, The Mozilla Foundation en Opera Software die werkt aan HTML 5 Extensible HyperText Mark-up Language. XHTML is gebouwd op XML en is onderworpen aan de correcte syntaxregels van XML, zoals verplichte afsluiting van elementen en hoofdlettergevoeligheid. Een DTD is verplicht mee te geven in de Doctype van de HTML code. De XHTML versie van HTML 4. De XHTML versie van HTML 4 met verplicht MIME type. De XHTML versie van HTML 5 waarvan de ontwikkeling echter is gestopt. XHTML 2 is niet achterwaarts compatibel, HTML 5 wel. Een naam die wordt gegeven aan een HTML 5 document dat is opgemaakt met XHTML 2 code. eXtensible Markup Language. Dit is een opmaaktaal voor het structureren van data in de vorm van platte tekst. Het is ook leesbaar voor individuen. De Ajax-technologie maakt gebruik van XML om data uit te wisselen.

Hoofdstuk 1

Accessibility: een overzicht

5

HOOFDSTUK 1. ACCESSIBILITY: EEN OVERZICHT

1.1 1.1.1

6

Definitie Web accessibility

Web accessibility, ofwel toegankelijkheid van websites, heeft als doel websites bruikbaar te maken voor personen met lichamelijke of psychologische beperkingen, of voor personen die door een andere reden niet beschikken over voldoende mogelijkheden om een website te raadplegen.

1.1.2

Accessibility en usability

Vaak wordt accessibility (toegankelijkheid) verward met usability (gebruiksvriendelijkheid, bruikbaarheid). Er bestaat terecht veel discussie over. Het is niet altijd even duidelijk wat tot usability behoort en wat in het domein van accessibility valt. Een aantal voorbeelden ter illustratie: ◦ Teksten beter leesbaar en meer begrijpbaar maken voor gebruikers met cognitieve of taalproblemen, verhoogt de toegankelijkheid van een site maar ook de usability. [59, chapter 1] ◦ Een alt-attribuut voor de alternatieve beschrijving van een afbeelding is een toegankelijkheidsregel, maar als de beschrijving te langdradig wordt verwoord, is dit op zich weer een usability fout. ◦ Een handleiding op het internet over de installatie van een harde schijf kan perfect uitgelegd worden met duidelijke zinnen. Echter, hoe eenvoudig deze zinnen ook mogen zijn, personen met cognitieve problemen (zie pagina 10) kunnen moeite hebben om ze te begrijpen en zijn meer geholpen met verklarende foto’s over de handelingen. Het ontbreken van illustraties bij een handleiding is eveneens een usability-probleem. [59, chapter 1] Het onderscheid tussen beide begrippen wordt in de academische wereld dan ook nog volop bestudeerd. Het is echter de vraag of we hier lang moeten bij stil staan, want uiteindelijk is het doel van een site zowel bruikbaar als toegankelijk te zijn. Het is zeker dat accessibility een essentiële bouwsteen en meetbaar controlemiddel vormt om een website te bouwen, waarbij men zich eerst en vooral afvraagt: “Is het bruikbaar? Is elk onderdeel van de site voor iedereen leesbaar en bereikbaar?”. Vervolgens richt usability zich op de vraagstelling: “Hoe bruikbaar is de site voor iedereen?”.

1.1.3

Het belang van web accessibility

Indien de regels om de toegankelijkheid van een site beter te maken zo goed mogelijk worden nagestreefd, is dit niet alleen voordelig voor de personen met fysieke en mentale problemen, maar ook voor ’algemene’ gebruikers: ouderen (zeker met het oog op de vergrijzing), informatici die enkel met toetsenbord werken, nieuwe internetgebruikers, surfers met een beperkte internetverbinding, enz.


7

Het toepassen van web accessibility regels vormt de basis van een goede website [59, chapter 1]. ◦ Het verplicht de ontwikkelaar een site structureel en logisch op te bouwen, waardoor hij tevens makkelijker te onderhouden is. Voorbeelden zijn: tekst en css gebruiken i.p.v. afbeeldingen, scheiding van opmaak, inhoud en structuur. ◦ Een site wordt performanter door het gebruik van toegankelijke tekst i.p.v. tekst in afbeeldingen en caching van CSS-files. ◦ Een duidelijke navigatie is verplicht. ◦ Er wordt automatisch rekening gehouden met de webstandaarden, zodat de site in zowel oude en toekomstige browsers er met grote zekerheid goed zal blijven uitzien. De kans is dan ook groter dat de site ook leesbaar is op andere apparaten, zoals mobiele telefoons. ◦ Een goed opgebouwde plaats met juist gecategoriseerde informatie draagt bij tot zoekmachineoptimalisatie. Google is tenslotte de belangrijkste bezoeker van een site. Veel van de raadgevingen van de Google’s Webmaster Guidlines1 zullen automatisch gevolgd worden. Een alternatieve tekst voorzien bij een afbeelding, zodat de zoekrobot weet wat de afbeelding voorstelt, is daar een uitstekend voorbeeld van.

1.1.4

Het belang van web accessibility voor bedrijven

Naast bovengenoemde argumenten profiteren de bedrijven ook mee van een toegankelijke webstek: ◦ De wet Bedrijven hebben vaak regels rond discriminatie en het is wenselijk dat deze ook van kracht zijn op de website. Bovendien moeten bedrijven de anti-discriminatiewet naleven. Meer hierover in hoofdstuk 1.5.3. ◦ Financieel Aangezien 15% van de bevolking [59, hoodfstuk 1] [11] kampt met een beperking is het voor bedrijven financieel interessant deze groep aan te trekken tot de website. Een bedrijf bespaart ook door de gevolgen van de verschillende eerder genoemde voordelen van accessibility, zoals minder personeelskosten om een site te onderhouden, minder kosten aan serveronderhoud, enz. [59, chapter 1] ◦ Vindbaarheid van informatie Een ontwikkelaar die code schrijft met toegankelijkheid in het achterhoofd, of een ontwikkelaar die de site met een screen reader of tekstuele browser test, zal automatisch merken dat delen van de site moeilijk te vinden zijn. Onnodige hyperlinks of dubbelzinnige informatie zal de ontwikkelaar storen bij het testen van niet-visuele technologieën. Het navigeren naar de gewenste informatie dient in zo weinig mogelijk stappen gebeuren. Helaas achten niet alle webontwikkelaars toegankelijkheid belangrijk. Het is dus nodig van deze principes een evidentie te maken. IT-diensten en webdesign bedrijven moeten dit opleggen aan hun werknemers. Dit zal tevens de onwetendheid rondom het onderwerp wegwerken.

1

http://www.google.com/webmasters/guidelines.html


1.1.5

8

Nooit iedereen

Accessibility is geen exacte wetenschap. Er bestaan zeer veel soorten handicaps, maar er bestaan nog veel meer, zoniet een ontelbaar aantal soorten mensen. Iedere persoon is uniek en zijn gebreken zijn dat ook. Bovendien kan een gehandicapte persoon meer dan 1 type beperking hebben. Hoe maak je een website toegankelijk voor iemand die zowel een gehoorprobleem heeft als kleurenblind is? Niet iedereen beschikt trouwens over de juiste middelen om het toegankelijkheidsprobleem te verhelpen. Een blinde persoon heeft niet noodzakelijk een screen reader in huis. Het is dus onmogelijk te streven naar een voor 100% toegankelijke site. Toch moet men trachten het onderste uit de kan te halen en zoveel mogelijk barrières te elimineren. Elke verbetering op een website is een last minder voor iedereen.


1.2

9

Mensen met een handicap

Een exacte definitie van een surfer met een handicap bestaat niet. Men kan beter spreken van een ‘’functiebeperking’. Op het internet vallen deze beperkingen meestal weg, indien men via de goed functionerende delen van het lichaam de handelingen toch kan uitvoeren. Zo zijn er programmeurs die een computermuis afwijzen omdat het sneller werken is met toetsencombinaties. Een functiebeperking hoeft dus niet noodzakelijk een nadeel te zijn. Studies [59, hoodfstuk 1] [11] tonen aan dat maar liefst 15%2 van de wereldbevolking een of andere beperking heeft. Niet elke beperking zal echter voor problemen zorgen. In dit werkstuk worden enkel soorten beschreven die hinderlijk kunnen zijn als men op het internet wil surfen.

1.2.1

Soorten handicaps

We kunnen functiebeperkingen onderverdelen in 4 groepen: ◦ Visuele beperkingen ◦ Auditieve beperkingen ◦ Motorische beperkingen: deze hebben te maken met beweging ◦ Cognitieve beperkingen: dit zijn veelal mentale problemen

1.2.2

Visuele beperkingen

Deze groep personen heeft waarschijnlijk het meeste last om het web te doorbladeren. Tenslotte is het internet vooral een visueel medium door de overvloed aan afbeeldingen en het succes van video. Volgens een studie van WebAIM [35] ondervinden meer dan 80% van de internetgebruikers met een beperking problemen ten gevolge van een vorm van blindheid. ◦ Blindheid. Iemand is blind wanneer hij met beide ogen nog maximaal 10% van zijn omgeving visueel kan waarnemen. Blinden zijn niet in staat om met een muis te werken en zijn vaak afhankelijk van het toetsenbord. Alternatieve beschrijvingen voor afbeeldingen, figuren, grafieken, enzovoort.. zijn een must voor deze doelgroep. ◦ Kleurenblindheid. Personen kunnen volledig of gedeeltelijk kleurenblind zijn. Een website moet voldoende contrast hebben tussen de kleur van de tekst en de achtergrond. Combinaties van groen en rood, of geel en blauw, zijn af te raden voor bepaalde types van kleurenblindheid. Bezoekers moeten de mogelijkheid hebben een eigen stylesheet te laden met hun eigen kleurcodes (zie hoofdstuk 2.1.9). Er bestaat een online tool om na te gaan hoe een kleurcontrast voldoet aan bekende standaarden: http://www.snook.ca/technical/colour contrast/colour.html ◦ Beperkt gezichtsvermogen. Personen met een beperkt gezichtsvermogen of slechtzienden gebruiken meestal vergrotingssoftware (zie pagina 26) of extra grote monitoren om websites te doorbladeren. Ze ervaren problemen met kleine letters en absolute fontgroottes (zie hoofdstuk 2.2.1). 2

Het is in de praktijk vrij moeilijk hier getallen op te plaatsen omdat elk land z’n eigen meetmethode heeft. Meer info hierover is te vinden op http://www.w3.org/WAI/bcase/soc


1.2.3

10

Auditieve beperkingen

Doven en slechthorenden hebben vooral problemen met geluid van een internetvideo, waarbij het geluid de inhoud van de site bepaalt. Gelukkig zijn er al veel oplossingen beschikbaar om video te ondertitelen, zoals CapScribe, DotSUB en JW FLV Player (zie hoofdstuk 3.5). Doofheid is op zich een relatief begrip en er zijn verschillende gradaties: ◦ Milde slechthorendheid. Deze personen kunnen geen geluiden horen onder de 30 decibel. Gesproken tekst kan worden verstaan, zolang er geen storend achtergrondlawaai aanwezig is. ◦ Gematigde slechthorendheid. Deze personen horen geen geluid onder de 50 decibel en zijn aangewezen op hoorapparaten. ◦ Ernstige slechthorendheid. Geluid onder de 80 decibel is niet te horen en vaak volstaan hoorapparaten niet. Gebarentaal of liplezen is vaak de oplossing. ◦ Totale slechthorendheid of doofheid. Geluid onder de 95 decibel is totaal niet hoorbaar. Personen die geen geluid waarnemen zijn enkel geholpen met ondertiteling of beschrijving van het geluid. Het idee om gebarentaal of bewegende lippen naast een video te tonen is meestal onhaalbaar, vanwege de duur van sommige filmpjes, maar ook omdat lang niet alle slechthorenden met dezelfde gebarentaal werken.

1.2.4

Motorische beperkingen

Mensen met een motorische handicap zijn afhankelijk van het gebruik van een speciale muis of toetsenbord, of spraakherkenningssoftware. Ze kunnen alle handelingen verrichten maar hebben hier voldoende tijd voor nodig. ◦ Lage responstijd. Websites moeten voldoende tijd geven aan gebruikers die door hun aandoening niet snel kunnen reageren op veranderlijke elementen. Een voorbeeld is online bankieren dat moeilijke handelingen vereist en waar de gebruiker meestal na verloop van tijd ter beveiliging automatisch wordt uitgelogd. Autorefreshment in een webpagina moet ook zoveel mogelijk worden vermeden. ◦ Beperkte motorische controle. Sommige mensen hebben het moeilijk om kleine of stabiele bewegingen te maken met de muis. Spelletjes en te kleine uitklapmenu’s vormen vaak een probleem. ◦ Muis onbekwaam. Deze personen gebruiken enkel toetsencombinaties en stemherkenningssoftware.

1.2.5

Cognitieve beperkingen

Een persoon heeft cognitieve beperkingen als hij meer dan bj een gemiddeld persoon problemen heeft bij het volbrengen van een mentale taak, meer dan bij een gemiddeld persoon. Er bestaan een ontelbaar aantal types van cognitieve beperkingen. Het is onmogelijk voor de ontwikkelaar met al deze types rekening te houden.


11

Er zijn twee soorten cognitieve beperkingen: klinische en functionele. De klinische richten zich tot de medische oorzaak van het probleem. Voorbeelden zijn het syndroom van Down, dementie, dyslexie, leerproblemen. Functionele beperkingen zijn geen soort apart maar eerder een andere classificatie van de problemen. De onderverdeling positioneert zich bij het geheugen, de oplossing van problemen, aandachtsvermogen, taalvaardigheid, wiskundig inzicht en visueel vermogen. Deze problemen zijn voor de ontwikkelaar gemakkelijker te begrijpen en toe te passen op accessibility dan te handelen naar de specifieke naam van een aandoening. Een persoon met een klinische beperking heeft vaak last van een combinatie van de functionele beperkingen. Dit zijn enkele typische cognitieve problemen met betrekking tot webtoegankelijkheid: ◦ Leerproblemen. Niet iedereen met leerproblemen zal last ondervinden bij het werken aan een computer. Sommigen beseffen het zelfs niet. Maar sommige stoornissen zoals ADHD3 brengen ernstige leerproblemen met zich mee. ◦ Concentratiestoornissen. Mensen met concentratiestoornissen worden vaak snel afgeleid van de inhoud van een pagina door bewegende afbeeldingen en animaties. Ook ADHD is een oorzaak van concentratiestoornissen. Om deze functionele beperking tegemoet te komen is het raadzaam zo weinig mogelijk blinkende elementen op een webpagina te plaatsen en ongewenste pop-ups te vermijden. Personen moeten de mogelijkheid krijgen deze elementen uit te schakelen. Zorg ook voor genoeg witruimte en beperk de hoeveelheid informatie of plaats eerst een samenvattend overzicht. ◦ Taalvaardigheidsproblemen. Maar liefst 15 tot 20% [5] van de bevolking heeft een soort van taalvaardigheidsprobleem (bijvoorbeeld dyslexie). Webontwikkelaars en copywriters moeten heldere web teksten schrijven die gemakkelijk kunnen gescand worden. Dubbelzinnige zinnen, satire, sarcasme en andere humor wordt best vermeden in teksten die bedoeld zijn om belangrijke inhoud te beschrijven. Personen met bijvoorbeeld autisme kunnen dit immers anders gaan interpreteren. Een uitgebreide handleing over toegankelijke teksten schrijven voor het internet kan gevonden worden op de site van WebAIM4 . Een screen reader kan tevens ondersteuning bieden. ◦ Problemen met grote verzameling informatie. Dit cognitieve probleem overlapt enigszins met de vorige stoornissen omdat het vermijden van grote concentratie aan informatie vaak al voor een oplossing zorgt. Een andere manier is informatie te splitsen over meerdere pagina’s, met eventuele nummering en omschrijving van de stappen zodat de gebruiker niet verloren loopt.

3 4

Attention Deficit Hyperactivity Disorder http://www.webaim.org/techniques/writing/index.php


1.3 1.3.1

12

Organisaties W3C

W3C (World Wide Web Consortium) is een internationale organisatie bestaande uit bedrijven en organisaties uit de webtechnologie-wereld. W3C heeft als doel het WWW en internet te promoten en standaarden op te leggen. Het wordt geleid door Tim Berners-Lee, een van de bedenkers van het internet. Onder meer CSS, DOM, HTML, SVG, RDF, XHTML en XML werden door het W3C gestandariseerd. De documenten en public working drafts die W3C aanbiedt op haar website worden door ontwikkelaars van websites, browsers en andere software als belangrijk referentiepunt beschouwd. Alle richtlijnen over accessibility verwijzen naar de officiële, zeer uitgebreide specificaties en working drafts (voorlopige versies) van HTML, XHTML en CSS.

1.3.2

AnySurfer

AnySurfer, vroeger BlindSurfer, is een Belgische vzw ontstaan uit de samenwerking tussen Vlaamse Blindenzorg Licht en Liefde en het Waalse Oeuvre nationale des aveugles. De organisatie werkt met vrijwilligers en is erkend door de Vlaamse en Waalse overheid. De voornaamste activiteiten zijn: ◦ informatie en advies verstrekken over toegankelijke websites; ◦ labels5 toekennen aan websites die voldoen aan de accessibility richtlijnen van AnySurfer (zie figuur 1.1); ◦ opleidingen en gastcolleges verzorgen; ◦ workshops voor ontwikkelaars organiseren; ◦ maatwerk (zoals custom stylesheets) ontwikkelen voor specifieke websites; ◦ sensibiliseren. Het behalen van een label Voor het toekennen van de labels onderzoekt AnySurfer momenteel gemiddeld 1 site per week. Het baseert zich daarvoor op haar richtlijnen. Eenmaal het label is behaald mag een bedrijf geen aanpassingen meer uitvoeren. AnySurfer voert regelmatig steekproeven uit op labeldragers. Indien door wijzigingen niet meer aan de richtlijnen wordt voldaan, kan AnySurfer het label terug afnemen. Het bedrijf in kwestie wordt wel op voorhand ingelicht zodat het de eventuele fouten op tijd kan verhelpen. In België moet elke overheidsite voldoen aan de eisen van AnySurfer. Het merendeel van de labels wordt dan ook toegekend aan dit type websites. Commerciële sites vormen nog een minderheid, hoewel daar in de toekomst verandering in komt. AnySurfer heeft op zijn website een lijst6 staan van alle gescreende sites. 5 6

AnySurfer verstrekt 2 soorten labels: een Basislabel en AnySurfer Plus (strikter). http://anysurfer.be/nl/service/labeldragers


13

Daar de tarieven van een screening behoorlijk hoog zijn (vanaf 460 euro voor een audit en vanaf 120 euro voor validatie van 100 pagina’s) werkt dit voor sommige bedrijven soms afschrikwekkend. Zelfs overheidsbedrijven houden soms de boot af.7 Men kan zich dus afvragen of de overheid geen opvoedende rol hierin moet spelen en subsidies moet toekennen.

1.3.3

WebAIM

WebAIM (Web Accessibility in Mind) is een belangrijke organisatie van de universiteit van Utah die advies verstrekt rond web accessibility. De organisatie deelt gratis certificaten op basis van een betalende screening van een website, ze geeft trainingen en biedt zeer uitgebreide informatie8 aan over accessibility. Ze ontwikkelde tevens de testtool WAVE (zie pagina 27).

1.4

Standaarden en guidelines

De begrippen standaarden en richtlijnen (guidelines) worden soms met elkaar verward, omdat ze een gemeenschappelijk doel voor ogen hebben: de webontwikkelaar advies geven hoe een toegankelijk kan worden gemaakt. Richtlijnen zijn echter abstracter dan standaarden. Een voorbeeld is Guideline 1.3 van WCAG 2.0: “Zorg dat informatie en structuur gescheiden zijn van presentatie”. Dit is voor intepretatie vatbaar. Het is eerder bedoeld als een soort van ‘best practice’. Standaarden daarentegen kunnen technisch getest worden. Een richtlijn die bijvoorbeeld overal terug komt is “Zorg dat alle afbeeldingen een ALT-attribuut bevatten.”. Dit kan algoritmisch gecontroleerd worden. Standaarden zijn dus gemakkelijker op grote schaal toe te passen, maar door hun technische omschrijving kunnen ze nooit alle aspecten van web toegankelijkheid omvatten. Om die reden worden richtlijnen over het algemeen meer gebruikt dan standaarden.

1.4.1

Webstandaarden

Allereerst zijn er de algemene webstandaarden over HTML, XHTML en CSS, ontwikkeld door het W3C. Er zijn verschillende versies van. HTML 4.0.1 en XHTML 1.9 zijn volledig 7

Mijn moeder is diensthoofd informatica van een groot ziekenhuis. Bij de vernieuwing van de website werd bewust niet gekozen voor een screening vanwege kostprijs. Nochtans is het een OCWM ziekenhuis, en dus in principe overheid. 8 http://webaim.org/articles/

(a) Basislabel

(b) AnySurfer Plus

Figuur 1.1: De AnySurfer labels die op een website worden geplaatst


14

gestandariseerd en de specificaties zijn terug te vinden op de site van W3C9 . In hoofdstuk 2.2.2 wordt dieper ingegaan op HTML 5 en XHTML 2. W3C heeft ook richtlijnen over accessibility, WCAG. Naast WCAG zijn er ook de guidelines van Section 508 (zie pagina 15), waar Amerikanen zich vaak op baseren. WCAG 2.0 De eerste versie van WCAG (Web Content Accessibility Guidelines) is geschreven in 1999 door het W3C. Intussen zijn we beland bij WCAG 2.0. De controlepunten in deze tweede versie zijn anders geordend (beter gegroepeerd) en de regels zijn toestelonafhankelijk. Het geheel is een enorm document10 met regels die webontwikkelaars dienen te volgen om een toegankelijke site te maken. Het is echter beter het beknopte Techniques for WCAG 2.0 11 te lezen. Helaas bestaat er van beide documenten tot op heden nog geen officiële Nederlandse vertaling. WCAG 2.0 omschrijft technieken in verband met HTML (hoofdstuk 2), XHTML, CSS (hoofdstuk 2.1.9), JavaScript, ARIA (hoofdstuk 2.3.2) en SMIL12 . WAI WAI staat voor Web Accessibility Initiative Accessible. Het werd gesticht door het W3C in 1997 ter bevordering van het web voor mensen met een beperking. Het houdt zich bezig met volgende 5 zaken [59, chapter 2]: ◦ Zich ervan verzekeren dat de basistechnologieën van het internet de toegankelijkheid ondersteunen ◦ Richtlijnen ontwikkelen voor websites, browsers en authoring-applicaties ◦ Ontwikkeling van evaluatie-tools en herstel-tools voor toegankelijkheid ◦ Opleidingen verzorgen ◦ Onderzoek naar webaccessibility Het is een set richtlijnen opgesteld door W3C die aangeven hoe websites toegankelijker kunnen gemaakt worden. Samengevat spitst WAI zich toe op richtlijnen met betrekking tot ◦ equivalente tekst wanneer een afbeelding, geluidsbestand of video niet kan worden weergegeven; ◦ toegankelijke hyperlinks en formulieren, vooral voor mensen met motorische problemen; ◦ een correcte site-structuur, die ten goede komt aan mensen met leer- of taalproblemen. 9

http://www.w3.org/TR/html401/ , http://www.w3.org/TR/xhtml1/ http://www.w3.org/TR/WCAG20/ 11 http://www.w3.org/TR/WCAG20-TECHS/ 12 Synchronized Multimedia Integration Language: multimediapresentaties in XML vorm. Zie hoofdstuk 3 10


1.4.2

15

Richtlijnen

AnySurfer De richtlijnen van AnySurfer zijn gebaseerd op WCAG 1.0. Het is in feite een vertaalde versie gegoten in een begrijpbaar en toepasbaar overzicht. Momenteel is men bij AnySurfer bezig de richtlijnen aan te passen aan de nieuwe versie WCAG 2.0 die in 2008 werd doorgevoerd. De huidige richtlijnen zijn te vinden op http://www.anysurfer.be/nl/richtlijnen En nog vele anderen De meeste grote organisaties, die iets met internet te maken hebben of er een grote invloed op uitoefenen, wijden een groot deel van hun website aan accessibility. Voorbeelden zijn BBC, AOL, Apple, Adobe,..

1.5

Wetgeving

In sommige landen bestaat er reeds lang een vaste webtoegankelijkheidswetgeving, zoals in de Verenigde Staten. In België is er nog geen, hoewel overheidssites aan de richtlijnen van AnySurfer moeten voldoen. Hieronder een overzicht van de wetgeving [38] over accessibility in de voornaamste landen.

1.5.1

Verenigde Staten

De Verenigde Staten zijn koploper op het gebied van wetgeving rond internet toegankelijkheid. Reeds sinds 1990 is de ADA-wet van kracht (Americans with Disabilities Act), die bepaalt dat werkgevers en overheden redelijke aanpassingen moeten doorvoeren om mensen met een handicap niet te benadelen op grond van hun beperking. Omdat het Amerikaanse Ministerie beslist heeft dat het internet “a place of public accomodation” is, geldt dit ook voor websites. Door een mislukt rechtsgeschil over de ontoegankelijkheid van de toemalige site van AOL, heeft de wet op websites niet veel invloed uitgeoefend. Section 508 In 1998 ondertekende Bill Clinton de Workforce Rehabilitation Act, die later de gekende naam Section 508 kreeg. Hoewel deze regelgeving enkel van kracht is op overheidssites, is het vandaag ook voor commerciële bedrijven nog steeds een toonaangevende bron voor tips over accessibility. Bovendien moeten alle elektronische en informatieve technologieën aangekocht door de Amerikaanse overheid hieraan voldoen. De regels van Section 508 tonen grote overeenkomsten met de eerste graad prioriteitsregels van WCAG 1.0.


1.5.2

16

Europa

De Europese Unie heeft nog geen wetgeving rond internettoegankelijkheid. Toch lijkt het erop dat dit tegen 2010 het geval zal zijn. Een overzicht van een aantal mijlpalen: ◦ De Europese Commissie heeft een aantal documenten opgesteld rond webtoegankelijkheid waaruit blijkt [38] dat websites zouden moeten voldoen aan de WCAG 1.0 standaard. ◦ In 2006 schreven [43] [32] Europese ministers op een top in Riga dat tegen 2010 alle overheidssites moeten toegankelijk zijn, en dat er tegen 2007 een officieële regeling tot stand moet komen. ◦ In november 2007 kwam Europa met E-Inclusion [33], die vraagt om aandacht voor de economische en financiële nadelen als gevolg van onvoldoende aandacht voor gebruikers met een handicap, en hoe de ICT dat kan verhelpen.

1.5.3

Belgi¨ e

Hoewel in het verleden al een wetsontwerp [52] werd ingediend door Julie Fernandez Fernandez, staatssecretaris voor Personen met een handicap, is het begrip webtoegankelijkheid nog nergens vermeld in de Belgische wetgeving, in tegenstelling tot andere Europese landen zoals Duitsland en Groot-Brittannië. In België geldt er sinds mei 2007 wel een duidelijke anti-discriminatiewet [20] die stelt dat personen niet mogen gediscrimineerd worden in een publieke dienst op basis van hun handicap. Het ontbreken van redelijke aanpassingen voor de persoon met een handicap vormt een discriminatie in de zin van deze wet. Elke vorm van directe of indirecte discriminatie is verboden bij het leveren of het ter beschikking stellen van goederen en diensten aan het publiek.


1.6

17

Screen readers

Zoals de naam reeds zegt lezen screen readers informatie van het scherm af. Ze plaatsen zich boven de huidige applicatie. Ze zijn vooral bedoeld voor personen met een beperkt gezichtsvermogen. Voor gebruikers met andere beperkingen (of een combinatie ervan) bestaan er andere assistive technologies (zie pagina 25) zoals braille displays, screen magnifiers en voice recognition software. De meeste klassieke screen readers maken gebruik van ingebouwde software Text-to-Speech (TTS) van het besturingssysteem om tekst om te zetten naar gesproken tekst. Op Mac OS X is TTS verfijnder dan op Windows. Bovendien levert Mac OS X VoiceOver mee, een gratis screen reader (zie pagina 19). Personen met een handicap zijn dus beter af met een Mac, hoewel er voor de PC-markt meer commerciële en gesofisticeerdere screen readers bestaan. Voor het surfen op het internet zijn er twee mogelijkheden. Een persoon kan gebruik maken van stand alone screen readers zoals JAWS en Windows Eyes. Dit is meestal de beste keuze omdat de gebruiker dan maar 1 screen reader onder de knie moet hebben voor verschillende soorten applicaties. Als een webontwikkelaar een website wil testen op toegankelijkheid, is er geen nood aan de sprekende stem in andere applicaties, en maakt hij beter gebruik van screen readers die alleen voor de browser bedoeld zijn. Hij kan kiezen voor browsers die op maat gemaakt zijn of voor extensies (plug-ins) voor de browser. Screen readers die webpagina’s kunnen voorlezen maken gebruik van het DOM (Document Object Model) van de pagina en overlopen die van boven naar beneden. Opmaakelementen van de HTML-code worden overgeslagen en de uitgedunde code wordt in de virtual buffer van de screen reader gestoken. Belangrijke elementen zoals headings (hoofdingen) en vet-markeringen worden wel meegedeeld. Screen readers onderzoeken dus de broncode van een webpagina en niet het visuele resultaat. Dit is een belangrijk principe dat vele ontwikkelaars wel eens vergeten.

1.6.1

Werken met een screen reader

Vrijwel alle screen readers laten een gebruiker toe het scherm te overlopen met het toetsenbord. Sommige toetsencombinaties zijn gemeenschappelijk aan het besturingssysteem, zoals tab om van hyperlink naar hyperlink te springen. Andere combinaties zijn te vinden via de helpfunctie en worden het best zoveel mogelijk van buiten geleerd. De screen reader leest alle informatie voor die op het scherm staat, alsook de titel van een venster, alternatieve verborgen teksten (zoals het alt element in HTML), letters van afkortingen, enz. Sommige screen readers geven ook informatie over de lay-out, bijvoorbeeld met welke heading (h1, h2,..) een zin is opgemaakt of hoeveel elementen er zich in een lijst bevinden. Met het toetsenbord kan door de tekst worden genavigeerd.


18

De leercurve is vrij lang, omdat er veel mogelijkheden en toetsencombinaties bestaan. Hoe meer kennis iemand van een screen reader bezit, hoe meer voordeel er wordt uitgehaald. Voor testgebruikers zoals personen met een perfect gezichtsvermogen of webontwikkelaars kan een screen reader in het begin erg verwarrend overkomen.

1.6.2

Beperkingen van screen readers

◦ Afbeeldingen Screen readers kunnen geen afbeeldingen lezen. Ze kunnen enkel de beschrijving ervan weergeven die in de alt tekst van de respectievelijke afbeelding staat. ◦ Lay-out interpreteren Een gebruiker die geen visuele beperking heeft, kan in een oogopslag zien wat belangrijk is op een pagina. Hij filtert bijna onbewust de reclame en minder belangrijke elementen weg. Een screen reader kan dit niet en leest een website van boven naar onder af. ◦ Tabellen Net omdat screen readers informatie lineair van boven naar onder en van links naar rechts lezen, kan het overlopen van een tabel (zie hoofdstuk 2.1.6) erg complex zijn en een lange tijd in beslag nemen. ◦ Verschillende soorten Elke screen reader is verschillend en zal zijn eigen systeem van notificaties en presentatietechnieken hebben. Indien de website echter gebouwd is met correcte code, dan is de kans groot dat deze in elke screen reader leesbaar is, net zoals dit tegenwoordig bij webbrowsers reeds het geval is (met uitzondering van Internet Explorer dan). Het is dus niet aan de webontwikkelaar om hier veel rekening mee te houden. De last om de accessibility regels te volgen is al groot genoeg en moderne screen readers houden voldoende rekening met de huidige internetstandaarden zodat de verschillen minimaal blijven.


1.6.3

19

Stand alone applicaties

Dit soort screen readers waren het eerste op de markt. Ze kunnen elk hoekje van het scherm waarnemen, zowel van het besturingssysteem als van de voornaamste programma’s (en dus niet enkel webbrowsers). De bekendste zijn JAWS van Freedom Scientific, en Windows Eyes van GW Micro. JAWS (Windows) JAWS (Job Access With Speech) is wellicht de bekendste screen reader op het Windows platform, met een marktaandeel van 74% [35]. Het programma is betalend (rond 1000 euro) maar een demo van 40 minuten is beschikbaar. Om deze 40 minuten te herladen, moet de computer herstart worden. Al van bij de installatie legt een stem uit welke stappen men moet volgen om JAWS te laten werken (dit is bij de meeste screen readers het geval). Na het herstarten van de computer wordt JAWS automatisch geactiveerd. Er bestaan zeer veel toetsencombinaties die allemaal kunnen teruggevonden worden in het help-bestand. Deze zijn ook te wijzigen via de instellingen. De meeste sneltoetsen komen echter overeen met die van Windows zelf. Zij die beginnen met Insert zijn meestal typische JAWStoetsen. De bijlage op pagina 89 bevat een overzicht van de belangrijkste toetsencombinaties. NVDA (Windows, gratis) NVDA (Non-Visual Desktop Access) is een open source screen reader voor Windows. In tegenstelling tot JAWS is het gratis en uitvoerbaar vanaf een USB stick (zonder installatie). Er zijn meer dan 20 talen beschikbaar (geen Nederlands). De bijlage op pagina 86 bevat een overzicht van de belangrijkste toetsencombinaties. De ontwikkeling van NVDA staat dankzij het open source concept niet stil. Zo werd recent aangekondigd dat de ARIA-technologie (zie hoofdstuk 2.3.2) weldra zal ondersteund worden dankzij een samenwerking met Yahoo! [37]. Ander recent nieuws rond de ontwikkeling is te volgen op de website13 . NVDA volgt alle de bewegingen van de muis. Het speelt zelfs een bieptoon af die hoger wordt naargelang de muis hoger in het scherm klimt. Een ontwikkelaar zet dit best af. De instellingen zijn terug te vinden via het icoontje in de systeembalk. In tegenstelling tot andere screen readers is de configuratie van NVDA zeer gebruiksvriendelijk, althans voor voor personen zonder een visuele beperking. Andere interessante mogelijkheden van NVDA zijn ◦ ondersteuning voor FireFox 3 (voorlopig geen andere browsers) en Thunderbird 3; ◦ ondersteuning voor Microsoft Word, Excel, Outlook Express en Windows Mail; ◦ basisondersteuning voor Acrobat Reader, Java-applicaties en Lotus Sympathy; ◦ ondersteuning voor braille displays van Freedom Scientific of BRLTTY. 13

http://www.nvda-project.org/wiki/FutureGoals#ARIADragandDrop


20

VoiceOver (Mac, gratis) VoiceOver is een component dat standaard wordt meegeleverd met het besturingssysteem Mac OS X, samen met andere web accessibility tools. De toegankelijkheidsopties zijn te activeren via ’Universele Toegang’ van de systeemvoorkeuren, of via Cmd + F5. Een nadeel van VoiceOver is dat het nog niet overweg kan met Flash-animaties. De mogelijkheden van VoiceOver en de andere tools zijn nochtans zeer uitgebreid en vormen voor gebruikers met een lichte beperking een goedkoop alternatief voor commerciële en dure screen readers. Een overzicht van de mogelijkheden: ◦ Alle elementen van het besturingssysteem kunnen voorgelezen worden als er met de muis wordt overgegaan. ◦ Ondersteuning van het Nederlands. ◦ Een ondertitelpaneel toont de huidige actie of de naam van het huidige element in een groot lettertype. ◦ Wanneer de gebruiker letters intikt, worden de aangeslagen toetsen uitgesproken. ◦ De gebruiker kan een visueel Braille-paneel op het scherm plaatsen, tevens uitstekend om het vreemde alfabet te leren. Externe USB Braille displays worden ondersteund. ◦ HTML-pagina’s kunnen worden overlopen met dezelfde toetsencombinaties. Er is wel nog niet voldoende ondersteuning [34] voor WAI-ARIA (zie hoofdstuk 2.3.2) en voorlopig worden enkel Safari en Opera 9.5 herkend. ◦ VoiceOver werkt samen met zeer veel applicaties, omdat de meeste gemaakt zijn met de programmeertaal Cocoa die automatisch toegankelijkheidsopties toevoegt. De bijlage op pagina 91 bevat een overzicht van de belangrijkste sneltoetsen. Inbegrepen toegankelijkheidsopties die niet specifiek verbonden zijn aan VoiceOver maar van Mac OS X een zeer toegankelijk besturingssysteem maken: ◦ De kleuren van het scherm kunnen worden omgedraaid, zoals de Invert-modus in Photoshop (zie figuur 1.2). ◦ De kleuren van het scherm kunnen in grijstinten worden omgezet. ◦ Het contrast van het scherm kan worden aangepast. ◦ Het systeem kan knippersignalen tonen bij een melding van een programma. ◦ Het toetsenbord kan fungeren als muis.


(a) Normale weergave in Mac OS X

21

(b) Omgekeerde kleuren

Figuur 1.2: De Invert-modus van Mac OS X

Andere bekende screen readers Er zijn nog bekende screen readers die helaas niet allemaal kunnen behandeld worden in dit eindwerk. Een beknopt overzicht: ◦ Windows Eyes (Windows) ◦ Connect Outloud (Windows) ◦ Dolphin HAL (Windows) ◦ Dolphin SuperNova (zoals HAL maar met magnifier) (Windows) ◦ Orca (Linux, gratis) ◦ LSR (Linux, gratis) ◦ WebAnywhere (Online Flash-applicatie, gratis) DAISY Voor DAISY-boeken (zie hoofdstuk 3.1.2) zijn er speciale readers beschikbaar. De website van DAISY geeft een lijst weer van beschikbare software14 .

14

http://www.daisy.org/tools/tools.shtml?Cat=splayback


1.6.4

22

Extensies voor browsers

Naast de stand-alone screen readers bestaan er extensies, plug-ins en toolbars voor bekende webbrowsers. De bekendste is Fire Vox. Fire Vox Fire Vox is een plug-in voor FireFox die als een screen reader pagina’s leest. Zoals alle plug-ins voor FireFox is deze gratis te downloaden en werkt het op elk besturingssysteem waar de browser op ondersteund wordt. Het is een gemakkelijk alternatief voor de klassieke screen reader, en veel webontwikkelaars maken er dan ook gebruik van. Toch is Fire Vox niet ideaal. Enkele bemerkingen: ◦ Fire Vox vertraagt de browser. Dit valt op wanneer men in een invulvak van een formulier te snel tekens invoert en sommige daarvan niet worden opgenomen. Dit probleem valt niet op te lossen door in de instellingen van Fire Vox de optie ’Echo keys’ te desactiveren. ◦ Het gebruik van Ctrl + Shift + A is niet erg doeltreffend. Bij het herladen van eenzelfde pagina leest Fire Vox de inhoud voor waar hij voordien was blijven steken. Men zou verwachten dat dit bovenaan begint. ◦ Fire Vox bevat nog teveel fouten. Soms gebeurt het dat de plug-in niets voorleest terwijl het wel verwacht mag worden. De bijlage op pagina 88 bevat tips over de installatie en geeft een overzicht van de belangrijkste toetsencombinaties. Er zijn nog andere plug-ins voor FireFox die de toegankelijkheid van de browser verbeteren, zoals AnyColor, Firefox Accessibility Extension15 , WebVisum, Colorful Tabs, CLiCk, Speak en ImageTweak. IBM Easy Web Browsing (Windows) Easy Web Browsing (EWO) is een commerciële plug-in voor Internet Explorer waarvan de ontwikkeling is stopgezet. Het kan wel nog steeds gedownload worden met een 30 dagen trialversie. Het product kon vroeger aangekocht worden door bedrijven om werknemers met een functiebeperking gemakkelijker de interne website te laten gebruiken. Vandaag kan de plug-in helaas enkel gebruikt worden om de site van IBM te doorzoeken. De software voorziet Internet Explorer van een toolbar en kan tekst voorlezen in verschillende talen (geen Nederlands), lettertypes vergroten en kleurschema’s van een website aanpassen. Indien een taal in de stembibliotheek ontbreekt, zal hij deze automatisch downloaden, op voorwaarde dat deze beschikbaar is. Het voegt ook extra geluidjes toe aan acties, zoals tijdens het binnenhalen van een bestand, het laden van een pagina en het klaar zijn met laden. 15

http://firefox.cita.uiuc.edu/


23

Opera met Voice (Windows) Opera is ongetwijfeld de meest geavanceerde en vooruitstrevende browser op de markt. Deze browser ondersteunt bijna altijd als eerste de nieuwste technologieën, zoals ARIA (zie hoofdstuk 2.3.2), maar ook de nieuwe webstandaarden waardoor het probleemloos slaagt voor de ACID3-test16 Daarnaast biedt Opera volgende toeters en bellen aan ter ondersteuning van de toegankelijkheid: ◦ Het kan geluiden afspelen bij gebeurtenissen zoals ’pagina geladen’ en ’download gereed’. ◦ Het laat de gebruiker toe lettertypes en fontgroottes van standaard HTML-elementen aan te passen voor elke webpagina. ◦ Gebruikers kunnen muisgebaren gebruiken voor het bladeren in een site. ◦ Toetsencombinaties zijn te wijzigen en er kunnen ook nieuwe sneltoetsen toegevoegd worden. Inbegrepen in de browser is het Voice-pakket, helaas enkel beschikbaar voor Windows. Met Voice ingeschakeld (via de voorkeuren) is het mogelijk tegen de browser te praten, tekst te laten voorlezen en zelf specifieke woorden toe te kennen aan commando’s.

Codevoorbeeld 1 Voice programmeren voor Opera: Browser zegt automatisch ’Hello World’ < !DOCTYPE html PUBLIC ’ −//VoiceXML Forum//DTD XHTML+Voice 1 . 2 / /EN’ ’ h t t p : / /www. v o i c e x m l . o r g / s p e c s / multimodal /x+v /12/ dtd / xhtml+v o i c e 1 2 . dtd ’>

1 2 3 4 5 6 7 8 9 10 11 12 13 14

. .
H e l l o World !
I f your b r o w s e r i s v o i c e enabled , you w i l l h e a r i t say ’ H e l l o , world ! ’ .

15 16

Het Voice-pakket kan ook worden aangewend om tekst op een webpagina programmatorisch te laten voorlezen of zaken te laten inspreken en hierop controles te voeren. Deze techniek heet XHTML + Voice, gebruikt VoiceXML (zie hoofdstuk 3.1.2) en vereist de toevoeging van een extra namespace en DTD bovenaan de broncode. Codevoorbeeld 1 laat zien hoe via een speciale event-handler tekst, beschreven in block-element, kan worden voorgelezen door de browser. Jammer genoeg is Opera voor Windows dus de enige versie die overweg kan met VoiceXML. De mogelijkheden die deze techniek met zich meebrengt zijn veelbelovend voor web accessibility. 16

Een webpagina die test hoe goed een webbrowser aan bepaalde webstandaarden voldoet.


1.6.5

24

Speciale browsers

Lynx Lynx is een gratis open-source browser waarin pagina’s worden weergegeven als pure tekst. Afbeeldingen, opmaak en JavaScript worden weggefilterd. Deze techniek heet ook wel linealiseren. Het programma loopt in de console van het besturingssysteem (cmd.exe op Windows, Terminal op Mac OSX, Console op Linux). Navigeren gebeurt door toetsencombinaties zoals de pijltjes (rechts = hyperlink volgen, links = vorige pagina, omhoog en omlaag = door pagina navigeren) en de G toets (URL ingeven). De browser is vooral bedoeld voor gebruikers die moeilijk met een muis kunnen werken en voor surfers met een beperkte internetverbinding. Afbeelding 1.3 toont hoe Google in Lynx wordt weergegeven. Er bestaat ook een online versie genaamd Lynx Viewer17 .

Figuur 1.3: Google in Lynx.

17

http://www.yellowpipe.com/yis/tools/lynx/lynx viewer.php


25

pwWebSpeak (Windows) pwWebSpeak is een alternatief voor Fire Vox, in die zin dat het een aparte webbrowser is die de auditieve eigenschappen al automatisch bevat. Helaas is het programma enkel beschikbaar voor Windows, wordt het niet verder ontwikkeld en gebruikt het alleen Engelstalige stemmen. Het is wel gratis. pwWebSpeak is een tekstuele browser, er staan geen afbeeldingen of opgemaakte elementen in. Gebruikers met een vaste screen reader zullen dit programma waarschijnlijk niet gebruiken, aangezien de functionaliteit al in hun vaste screen reader aanwezig is. Maar het kan echter handig zijn voor webontwikkelaars om code aan web accessibility tests te onderwerpen. Het is minder vervelend dan Fire Vox omdat het programma volledig apart operereert en veel snelller is. IBM Home Page Reader (Windows) Home Page Reader (HPR) is een visuele, auditieve en tekstuele browser ontwikkeld door IBM. Het werd op non-actief gezet in 2006 maar is nog steeds te downloaden18 .

Figuur 1.4: Google in Home Page Reader . Figuur 1.4 toont hoe Google wordt weergegeven in HPR. In de linkerkant van het programma zien we de reeds bezochte pagina’s. Onder het hoofdvenster staat een gelinealiseerde weergave van de site. Home Page Reader leest automatisch elk element voor via Text-to-Speech van Windows. Het programma heeft ook een ingebouwd mail programma. Home Page Reader is net als pwWebSpeak een van de beste screen readers om door webontwikkelaars getest te worden. De bijlage op pagina 90 bevat een overzicht van de belangrijkste toetsencombinaties. 18

http://browsers.evolt.org/?homepagereader/


1.7

26

Andere hulpmiddelen

Naast screen readers zijn er zijn meer dan duizend soorten hulpmiddelen voor personen met een handicap, gaande van eenvoudige objecten zoals een grote muisbal, tot zeer gesofisticeerde technieken zoals eye-tracking. Ze werken altijd samen met aangepaste software, die de bewegingen vertaalt naar herkenbare acties voor het besturingssysteem. Het gebruik van een toetsenbord is echter nog steeds geen overbodige luxe. Het is dan aan de programmeur om de applicaties ook toegankelijk te maken via het toetsenbord met zo weinig mogelijk toetsaanslagen. Hieronder volgt een beknopt overzicht van enkele belangrijke hulpmiddelen.

1.7.1

Output devices

Dit soort apparaten geeft informatie, geproduceerd door een programma op de computer, aan de gebruiker terug via een extern apparaat. Bekende output devices zijn het beeldscherm, de printer en de geluidsboxen. Refreshable Braille display Refreshable Braille displays hebben dezelfde beperkingen en noden als tekstuele screen readers. Beiden linealiseren twee-dimensionale informatie naar een-dimensionale ’pure’ tekst. In plaats van de tekst dan voor te lezen via een speech synthesizer, zet het programma de tekst om naar voelbare brailleletters. Screen magnifiers Screen magnifiers, vrij vertaald ’schermvergroters’, zijn conceptueel zeer eenvoudige hulpmiddelen. Ze doen niets anders dan specifieke delen op het scherm uitvergroten, zoals met een vergrootlas, en worden voornamelijk gebruikt door slechtzienden die niet volledig blind zijn. In de meeste besturingssystemen zijn screen magnifiers reeds aanwezig. In Windows is dit te bereiken via bureau-accessoires. Op Mac zijn de sneltoetsen te activeren via Universele Toegang in de systeemvoorkeuren, maar standaard kan er ook al ingezoomd worden door Ctrl ingedrukt te houden en te scrollen via het muisballetje. Voor Windows bestaan er tevens commerciële tools zoals ZoomText19 . Deze bieden de gebruiker meer opties zoals Dual Monitor en verscherpen de uitvergrote letters.

1.7.2

Input devices

Input devices zijn het omgekeerde concept van output devices. De gebruiker kan opdrachten geven via deze apparaten aan de computer met zijn stem, handen, ogen of lichaam. Bekende input devices zijn de muis, het toetsenbord, aangepaste toetsenborden, de microfoon en de scanner. Stemherkenningssoftware Met stemherkenningssoftware kan een persoon via een microfoon tekst inspreken en opdrachten geven aan de computer. Indien het software betreft die zich op een ruime woordenschat richt 19

http://www.aisquared.com


27

moet de gebruiker de taal beheersen en goed kunnen articuleren. Bij gespecialiseerde software met vakjargon is dit minder nodig. Een klassiek voorbeeld is de radioloog. In meer en meer ziekenhuizen gebruikt men spraakherkenning en de kwaliteit van herkenning ligt zeer hoog, zelfs bij radiologen met een minder goede uitspraak. De gebruikte terminologie is relatief beperkt en deze context wordt vooraf geladen in het systeem waardoor de spraakherkenningssoftware deze woorden zeer vlot herkent. In de meeste spraakherkenningspaketten kan men het systeem ‘trainen’, dit wil zeggen dat de computer nieuwe woorden wordt aangeleerd zodat die nadien beter herkend worden. De betere software traint ook op basis van stemkleur, accent of bepaald uitspraakpatroon. Dus ook in een algemene context is de mate van correcte weergave ook heel sterk afhankelijk van de voorbereiding, de training en niet alleen van de taalbeheersing en articulatie. Volgende producten zijn bekende stemherkenningsprogramma’s: ◦ Dragon NaturallySpeaking (Windows) ◦ MacSpeech Dictate (Mac) ◦ IBM ViaVoice (Windows, Mac) Hulpmiddelen voor personen met motorische handicap Personen met een motorische handicap kunnen meestal geen muis of toetsenbord gebruiken. De noodzakelijke bewegingen zoals klikken kunnen worden gesimuleerd met speciale hulpmiddelen zoals: muisstokken, speciale klikapparatuur, grote trackball voor de muis, dynamisch toetsenbord, eye-tracking, enz.

1.8

Test software

Test software, ook wel testing tools genoemd, zijn er voor de webontwikkelaars om te controleren hoe goed een website aan de web accessibility standaarden voldoet. Geen enkele testtool kan op alle regels controleren. Daar zijn twee redenen voor: ◦ Er moet een keuze gemaakt worden welke richtlijnen/standaarden worden gebruikt. Die van WCAG 2.0 zijn bijvoorbeeld anders dan die van Section 508. Een richtlijn kan ook anders geformuleerd zijn, andere prioriteiten hebben of niet diep genoeg gaan. ◦ Mocht er een algemene wetgeving bestaan waarbij de testtool op alles controleert, dan nog zijn er regels die enkel door het menselijk oog kunnen opgemerkt worden, zoals inhoudelijke structuur en leesbaarheid. Het voordeel van testing tools is dat ze de controleerbare zaken op grote schaal zeer snel kunnen overlopen, iets waar een persoon zelf onmogelijk in staat toe is. De bekendste en gratis beschikbare testtool is WAVE. Er bestaan nog vele andere softwarepakketten, al dan niet betalend, zoals Bobby (bekendste), InFocus, LIFT-machine, Ramp Ascend, WebKing en WebXM. Er zijn ook gratis toolbars voor de browser beschikbaar, waaronder die van WAVE, de Web Accessibility Toolbar en de Section 508 Toolbar. Commerciële softwarepaketten bieden meestal de mogelijkheid ook op andere richtlijnen te testen. De prijzen variëren van 50 tot 2500 USD.


1.8.1

28

WAVE

De onderzoekers bij WebAIM (zie pagina 13) ontwikkelden het gratis stukje software WAVE om websites te testen. Het is beschikbaar als een FireFox toolbar, en kan ook rechtstreeks worden uitgevoerd op http://wave.webaim.org . Het algoritme zal de code van een website doorzoeken op fouten tegen toegankelijkheid en plakt deze vervolgens als icoontjes over de pagina’s zodat er een mooi visueel overzicht ontstaat. De tool toont alleen eenvoudige fouten, zoals een te kleine tekst, het ontbreken van alternatieve beschrijvingen voor een afbeelding, ongewenste aanwezigheid van JavaScript en ontbrekende labels. WAVE controleert niet op alle regels van Section 508 of WCAG, omdat deze vaak voor intepretatie vatbaar zijn. Men kan ook kiezen voor ’structured view’. Daarbij worden elementen op de webpagina genummerd. Dit geeft een goede indicatie in welke volgorde een screen reader de elementen zal overlopen. Als laatste is er de ’outline view’ om visueel uit te testen hoe een pagina door tekstuele screen readers zal ge¨ınterpreteerd worden. Dit staat wel zeer streng ingesteld. Als de structuur geen headings (h1, h2, h3) bevat, zal ’outline view’ niets weergeven. Een mooi voorbeeld van zo’n slechte site is http://www.batchloadincinerators.com .

Hoofdstuk 2

HTML en Ajax

29

HOOFDSTUK 2. HTML EN AJAX

30

Het gebruik van Ajax-technieken1 op webpagina’s zorgt ervoor dat informatie snel kan veranderd worden zonder dat men de pagina hiervoor moet herladen. De informatie wordt asynchroon opgehaald, en niet samen met de hele webpagina. Dit maakt een website intu¨ıtiever en performanter en men tracht op deze manier de gebruiksvriendelijkheid van desktop applicaties te evenaren. Websites met dergelijke eigenschappen heet men ook wel Rich Internet Applications (RIA). Deze gebruiksvriendelijkheid geldt echter niet voor gebruikers met een handicap. Voor screen readers is het detecteren van deze veranderingen ten gevolge van Ajax bijzonder moeilijk. ARIA Live Regions (zie hoofdstuk 2.4) maken het mogelijk specifieke delen van een pagina aan te duiden die gevoelig zijn voor verandering. Deze techniek is echter nog niet volledig ingeburgerd. Door het voordeel van de Ajax-techniek zijn webontwikkelaars dus steeds meer geneigd webapplicaties te maken die gebruik maken van een intu¨ıtieve user interface om een betere gebruikerservaring te creëeren. Deze interface is dan opgebouwd uit afbeeldingen, CSS en JavaScript, in plaats van terug te vallen op gekende elementen van het operating systeem zoals desktop applicaties doen. Dit maakt het nadelig voor hulpprogramma’s zoals screen readers omdat ze niet weten hoe ze met deze elementen moeten omgaan. Helaas is niet enkel Ajax en een complexe interface een probleem voor screen readers. Ook gewone HTML-elementen worden vaak niet goed ge¨ınterpreteerd. Dit hoofdstuk bespreekt eerst veel voorkomende fouten met HTML-elementen en CSS, en vervolgens het de technologieën HTML 5, WAI-ARIA, JavaScript en Ajax.

1

Asynchronous JavaScript and XML


2.1

31

HTML richtlijnen

Voordat een site toegankelijk kan gemaakt worden, moet het concept web accessibility goed begrepen zijn. De meeste fouten ontstaan door de onwetendheid over het onderwerp. Want hoewel het wenselijk is de regels rondom correcte HTML code te volgen, zijn er logische stappen die het merendeel van de problemen al kunnen oplossen. Een aantal voorbeelden: ◦ Kunstenaars pakken graag uit met grafisch verbluffende of abstracte websites. Bijna altijd speelt de perceptie van het concept voor de bezoeker een grote rol. De kunstenaar profiteert daarbij van elke vrijheid in de keuze van de kleuren en onderverdeling van de pagina. Nochtans is het bij kunst meestal de bedoeling dat iedereen er toegang toe heeft. Openingsuren van de tentoonstelling, die meestal wel moet kunnen bezocht worden door personen met een handicap, zijn echter onvindbaar. Men moet hiermee rekening houden indien de website als doel heeft informatie te verschaffen of een product te verkopen van de kunstenaar. Een mooi voorbeeld is te vinden op de homepagina van een student van Hogeschool Gent2 . De tekst over de student grafische beeldvorming staat gealigneerd volgens de achtergrond, schuin hellend naar rechts. Dit is met HTML of CSS zeer moeilijk te verwezenlijken en dus plaatste de student de tekst in een afbeelding. Tekst in een afbeelding is echter een zware accessibility fout. Een ander voorbeeld van een slechte site is die voor de expositie van kunstenaar An Te Liu3 . Hoewel de opbouw zeer eenvoudig en duidelijk is, zijn de links naar CV en info voorgesteld als afbeeldingen. ◦ Kleurgebruik om de navigatie op een site eenvoudiger te maken komt de gebruiksvriendelijkheid ten goede. In sommige gevallen zijn de kleuren niet noodzakelijk om de site begrijpbaar te maken, maar is het enkel een extra hulp. Sommige websites zijn echter volledig gebaseerd op kleuren. Gebruikers die deels of volledig kleurenblind zijn vallen aldus uit de boot. Hoewel volgende regels geen garantie bieden op een toegankelijke website (enkel mensen kunnen dat) is het toch een goede basis. Het is trouwens onmogelijk alle regels te volgen en een site te laten valideren op alle guidelines (zie hoofdstuk 1.3.3).

2.1.1

Keep it simple

Het is nooit goed te veel tekst te plaatsen. Hou het kort en bondig. Ook voor gebruikers zonder een beperking is dit voordelig, want webpagina’s worden steeds ’gescand’. Hoe minder tekst, hoe leesbaarder een site is en hoe vlugger hulpmiddelen zoals screen readers de pagina kunnen overlopen.

2.1.2

Gebruik de juiste HTML code

Hoewel dit hoofdstuk net handelt over welke HTML code de beste is, moet het ook als een algemene richtlijn beschouwd worden. Gebruik bijvoorbeeld enkel
tags om lijsten te 2 3

http://webs.hogent.be/∼056958st/bookmark/me.html http://www.anteliu.com


32

maken, want tenzij roles (zie hoofdstuk 2.3.2) ingezet worden, zullen screen readers niet weten dat het stuk code een lijst betreft. Valideer tevens de code4 .

2.1.3

Navigatie

Titels Een titel moet steeds passen bij zijn inhoud. Gebruik enkel de
,
, ..
elementen van HTML om ze te definiëren. Navigatie bovenaan Omdat screen readers de broncode van de pagina van boven naar beneden lezen, en niet in de volgorde van hoe het gepresenteerd wordt in de browser, moeten de belangrijkste navigatieelementen bovenaan in de code staan. Later kan die via CSS naar eigen keuze worden verplaatst. Op die manier moet de persoon met een screen reader niet eerst alle inhoud overlopen vooraleer te kunnen navigeren via het menu. Het is tevens een goed idee een bladwijzerlink te plaatsen naar de positie waar de inhoud begint. Deze verwijzing kan via CSS best verborgen worden, terwijl een screen reader de gebruiker nog steeds kan aanbieden om meteen naar de inhoud van de pagina te springen. Hoe een element op een toegankelijke manier verborgen wordt, is te lezen op pagina 42. Plaats eventueel een access key (zie volgend punt) met waarde 2 aan de bladwijzerlink. Codevoorbeeld 2 Menu bovenaan in code + ’Skip to content’-bookmark 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

..

Skip t o c o n t e n t

< l i> < l i> ..

T i t e l p a g i n a

4

http://validator.w3.org


33

Access keys Een gebruiker kan met de tab toets gemakkelijk navigeren doorheen de hyperlinks op de pagina, en deze activeren door te enteren. Het is nog gemakkelijker speciale toetsencombinaties te definiëren voor typische links zoals ’Skip to content’ en ’Home Page’. Dit kan door het attribuut accesskey toe te voegen aan het hyperlink-element. De waarde van zo’n access key mag maar 1 karakter tellen (letter of cijfer in Unicode). Een voorbeeld van zo’n implementatie is te zien in codevoorbeeld 2. Ook de formulier-elementen button, label, input, legend en textarea mogen een access key bevatten. De activatie van de sneltoetsen hangt af van de browser en het besturingssysteem. In Safari op Mac is dit Ctrl + Alt + de accesskey, terwijl FireFox op Mac met Ctrl + accesskey werkt. In Windows browsers en JAWS is het meestal Alt + de accesskey. JAWS leest trouwens de access key voor als “link: Home page, ALT + 1”, Windows Eyes doet dit niet. Sommige browsers, zoals Camino voor Mac, ondersteunen zelfs geen access keys. Er bestaat helaas geen standaard voor veel voorkomende access keys. Onderzoek door Sitepoint [14] heeft echter uitgewezen dat volgende toetsen veel gebruikt worden op Amerikaanse overheidssites en de site van W3C: ◦ H : Home Page ◦ S : Skip to content ◦ K : Accesskeys legende ◦ 0 tot 9 : Navigatie items De site van WebAIM (zie 1.3.2) raadt dan weer andere sneltoetsen aan5 . Een studie [2] door WATS (een organisatie zoals WebAIM) waarschuwt echter voor het gebruik van access keys. De sneltoetsen van het besturingssysteem, de browser of de screen reader kunnen ermee interfereren. Op de website van WATS is een overzicht te vinden met sneltoetsen die voor problemen kunnen zorgen.6 Beschrijvende links Een hyperlink met als omschrijving ’Meer’ of ’Volgende’ is onduidelijk. Verwoord altijd beknopt wat de referentie zal inhouden. Maak indien nodig gebruik van het attribuut title.

2.1.4

Tekst

De juiste taal Wanneer bepaalde tekst in een andere taal staat, definieer dit dan ook in de HTML code. Dit kan via het attribuut lang (zie codevoorbeeld 3). Specifieer ook de globale taal van de pagina in de head-sectie van het document. 5 6

http://www.webaim.org/techniques/keyboard/accesskey.php http://www.wats.ca/show.php?contentid=43


34

Voorbeeldcode 3 Een toegankelijke tabel in HTML 1 2 3 4 5 6 7

..
I k had een <span lang=’ f r ’>d e j a vu d e z e nacht .

2.1.5

Formulieren

Bij HTML-formulieren is het vooral van belang de naam van een veld in een label te plaatsen. Op die manier kan een screen reader omschrijvingen aan de juiste velden koppelen (zie codevoorbeeld 4). Indien een omschrijving niet gewenst is doordat de functie van het element visueel meteen duidelijk is, zoals bij een zoek-veld rechts bovenaan een website, dient men het label onzichtbaar te maken met CSS (zie pagina 42 om dit op toegankelijke wijze te doen). Andere zaken bij formulieren waarop gelet moet worden: ◦ Groepeer grote gemeenschappelijke delen van een formulier met fieldset en legend. ◦ Vertrouw niet enkel op een opvallende kleur wanneeer een veld de aanduiding ‘verplicht’ moet krijgen. Gebruik client-side validatie (JavaScript) voor extra controle op dit veld. ◦ Ingewikkelde velden zoals wijzigbare tabelcellen waar niet meteen een semantisch label bij past, moeten een title-attribuut te krijgen. ◦ Image buttons moeten een alt-attribuut hebben. ◦ Het is raadzaam om geen tabindexes te gebruiken als de tabvolgorde in orde is. Het gevaar is namelijk dat men anders een tabindex vergeet toe te kennen aan een of meerdere formuliervelden, en dat de screen reader of browser verward geraakt. Voorbeeldcode 4 Labels koppelen aan formulier-elementen 1 2

Familienaam :

2.1.6

Afbeeldingen

Ongetwijfeld de klassieker van alle accessibility regels is de verplichte alt-code. Nochtans zijn er veel ontwikkelaars die dit vergeten. Elke afbeelding dient met deze code een alternatieve beschrijving te krijgen. Deze regel geldt ook voor elke area bij image maps. Indien een afbeelding tekst bevat (en eventueel fungeert als knop), zorg dan dat het lettertype groot genoeg en leesbaar is. In sommige browsers zoals Internet Explorer wordt zo’n knop namelijk niet mee vergroot wanneer er wordt ingezoomd. Codevoorbeeld 5 toont een correcte implementatie van een image map.


35

Voorbeeldcode 5 Toegankelijke image maps 1

2 3 4

<map id =’map1 ’> <area href =’ l i n k 1 . html ’ a l t =’Het g e z i c h t van Karel ’ t i t l e =’ Karel ’ shape= r e c t coords = ’ . . . ’> <area href =’ l i n k 2 . html ’ a l t =’De broek van S o f i e ’ t i t l e =’ S o f i e ’ shape= r e c t coords = ’ . . . ’>

5 6

Zonder alternatieve tekst zal een screen reader de gehele hyperlink proberen voorlezen, hoe moeilijk de tekens ook zijn die erin voorkomen. Het is dus werkelijk noodzakelijk dit atttribuut erbij te zetten. Doe dit ook bij elementen zoals scripts, applets, frames, grafische knoppen (), video en spacers 7 . Indien de tekst te lang is, gebruik dan het longdesc-attribuut met daarin de URL van een HTML-pagina met de langere beschrijving. De testing tool WAVE (zie hoofdstuk 1.8) markeert ontoegankelijke afbeeldingen met een speciaal symbool.

2.1.7

Tabellen

Tabellen zijn voor screen readers zeer lastig om te overlopen. Een gewone gebruiker kan in 1 oogopslag de juiste cel vinden, een gebruiker met een screen reader dient elke rij en kolom een voor een te overlopen. Het is daarom belangrijk cellen en hun omgeving juist te benoemen. Codevoorbeeld 6 toont hoe een tabel op een correcte wijze moet worden opgemaakt. Uitleg bij de code van de tabel 1. Beschrijving. Plaats bij voorkeur een beschrijving. Dit kan via twee HTML tags: ◦ Een tabel kan een titel krijgen met heading elementen, maar het is beter gebruik te maken van . Dit is zowel zichtbaar in een gewone browser als screen readers. ◦ <summary> beschrijft de tabel. Dit mogen meerdere zinnen zijn. Het wordt niet getoond in de browser, maar screen readers kunnen het wel lezen. 2. Rijen en kolommen. Als een screen reader wil weten waar een cel zich bevindt in de tabel, maakt hij gebruik van deze elementen: ◦ . Het gebruik van het element wordt dikwijls nog te weinig toegepast en vaak valt men terug op gewone tags om de bovenste rij en linkse kolom te omschrijven. Het is echter dankzij het th-element dat een screen reader kan weten waar een cel zich bevindt. ◦ abbr Het is geen slechte zaak een abbr-attribuut aan een th-element te koppelen. Sommige screen readers zullen na verloop van tijd deze korte naam uitspreken i.p.v. de volledige naam van de kolom of rij, wat luistertijd bespaart voor gebruikers met een screen reader. 7

kleine onzichtbare afbeeldingen die de lay-out helpen opmaken


Voorbeeldcode 6 Een toegankelijke tabel in HTML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

36


37

◦ Soms wil men een afsluitende rij met bijvoorbeeld totalen. Hier kan voor gebruikt worden. Analoog bestaan de tags en . 3. Complexe tabellen. In complexe tabellen dient een cel verwijzingen te leggen naar omvattende cellen, rijen of kolommen. Dit kan door aan de td-tag van de cel het attribuut headings mee te geven. Daarin staan de namen van de id’s van de omringende elementen waartoe een cel behoort, gescheiden door spaties. De omringende elementen kunnen op hun beurt weer verwijzen naar bovenliggende elementen. Het is echter aan te raden tabellen zo eenvoudig mogelijk te houden. Dit is niet alleen in het voordeel van de ontwikkelaar, maar ook voor de persoon die een screen reader gebruiken. JAWS en tabellen JAWS (zie hoofdstuk 1.6.3) overloopt tabellen als volgt: ◦ Alt + pijl links/rechts. De JAWS-cursor verplaatst zich een kolom naar links of rechts en leest deze voor. Bijvoorbeeld: ‘Pink ladies appelen, euro one point twinty, euro one point sixty..’. Als de laatste kolom is bereikt zegt JAWS: ‘you are on the last column’. ◦ Ctrl + Alt + num 5. JAWS leest de huidige cel voor: ‘Column 2, Row 2, Pink ladies appelen Delhaize, euro one point sixty‘. Het programma zegt dus achtereenvolgens het nummer van de rij, de kolom, de titel van de kolom, de eventuele extra th inhoud en uiteindelijk de celinhoud.

2.1.8

Links

Hyperlinks moeten een betekenisvolle naam hebben. Nog beter is de naam zo te formuleren dat hij onafhankelijk is van de context van de pagina, zodat screen readers hen in hun zogenaamde ‘linklijsten’ kunnen steken. “Lees meer”-links bij nieuwsberichten zijn toegestaan, maar de titel van de samenvatting moet dan ook aanklikbaar zijn. Bij links rond afbeeldingen is het aangeraden het klikgebied te vergroten, want afbeeldingen kunnen niet proportioneel geschaald worden met de tekst. Zo hoeft een slechtziende gebruiker niet veel moeite doen om te mikken op de link.

2.1.9

Frames

Frames zijn verouderde HTML technieken waarbij een volledige HTML-pagina in een andere pagina wordt gegoten met een bepaalde afmeting. Die ingebedde pagina functioneert volledig autonoom en kan niet communiceren met de omringende pagina. Het werd in het verleden vaak toegepast om een menu-structuur overal zichtbaar te houden, hoe diep er ook naar beneden gescrold wordt. Frames zijn vanuit accessibility standpunt echter volledig af te raden. Zijn ze toch noodzakelijk, dan moeten er title, name en longdesc attributen bij. Een iframe is minder problematisch.


38

Moderne screen readers gaan echter probleemloos om met frames, maar wel elk op hun eigen manier. JAWS beschouwt heel de frameset als een pagina, terwijl Home Page Reader de frames eerst apart presenteert. Het is een goede gewoonte het element noframes te gebruiken voor oude screen readers die frames niet ondersteunen. Inline frames, in HTML een iframe genoemd, zijn voor screen readers geen probleem. Op vlak van toegankelijkheid zijn ze onderworpen aan dezelfde voorwaarden als gewone frames. Toch is een div-element in combinatie met de CSS eigenschap overflow:auto een beter alternatief voor een iframe, omdat het dan in verbinding staat met omringende pagina.


2.2

39

CSS richtlijnen

Het spreekt misschien niet voor zich dat CSS (Cascading Style Sheets) kan bijdragen tot toegankelijkheid. Ze spelen nochtans een belangrijke rol.

2.2.1

Voordelen van CSS t.o.v. web accessibility

◦ Het scheidt vormgeving van inhoud. Dit maakt de code ordelijker. ◦ User Stylesheets Door de scheiding kan een gebruiker via speciale tools (bijvoorbeeld Greasemonkey8 ) het CSS bestand overschrijven door zijn eigen op maat gemaakte CSS code (User Stylesheet), met als doel elementen anders te organiseren of te verbergen. Omdat CSS stijlen overridable zijn is het zelfs niet nodig het oorspronkelijke CSS bestand volledig te wijzigen. Codevoorbeeld 7 toont een User Stylesheet waarin de gebruiker beslist tekst in paragrafen in het blauw weer te geven. Om ervoor te zorgen dat de kleureigenschap niet terug wordt overschreven door andere code, moet er !important naast staan. Voorbeeldcode 7 User Stylesheet: overschrijven van properties afdwingen met !important 1 2

body { c o l o r : b l u e } p { c o l o r : i n h e r i t ! important }

◦ Media types Stylesheets kunnen toegewezen worden aan bepaalde type media (scherm, tv, browser, printer) via de @media regel bovenaan de CSS code. Wil men bijvoorbeeld CSS regels enkel op de uitvoer van een printer laten gelden, moet het media type print meegegeven worden (zie codevoorbeeld 8). Er bestaat ook een media type voor braille (braille) en mobiele telefoons (handheld). Voorbeeldcode 8 Media types in CSS 1 2 3 4

@media p r i n t { p { .. } h1 { . . } }

◦ Kapitaliseren. Een woord in drukletters in de HTML-code kan ervoor zorgen dat screen readers het woord letter per letter voorlezen. Vermijd dit dus en kapitaliseer het woord met CSS, zoals in codevoorbeeld 9. Voorbeeldcode 9 Kapitaliseren in CSS 1 2 3

. drukletters { t e x t −t r a n s f o r m : u p p e r c a s e ; }

8 een extensie voor FireFox waarmee de gebruiker zelf kleine stukjes Javascript-code aan webpagina’s kan verbinden om zo zijn favoriete website aan te passen


40

◦ Spati¨ ering. Een belangrijk woord ’strekken’ door de letters te scheiden met spaties is een accessibility fout. Screen readers zullen het woord letter per letter voorlezen. Om toch visueel hetzelfde effect te krijgen, kan in CSS gebruik gemaakt worden van font-stretch. Analoog zijn er ook de eigenschappen text-indent, word-wrap en text-indent. ◦ Automatische nummering Paragrafen of andere HTML-elementen kunnen automatisch genummerd worden met CSS (zie codevoorbeeld 10). Voorbeeldcode 10 Automatische nummering met CSS 1 2 3 4

P: before { c o n t e n t : c o u n t e r ( paragraph ) ’ . c o u n t e r −i n c r e m e n t : paragraph }

’ ;

◦ Aural Cascading Style Sheets (ACSS) Deze niet zo bekende eigenschap van CSS 2 defnieert hoe tekst moet worden uitgesproken door de screen reader. De geluidsterkte kan worden meegeven, maar ook het type stem en een geluidje dat vooraf of achteraf moet afspelen. Codevoorbeeld 11 toont hoe een titel omschreven met
zal worden uitgesproken met een luide stem, en daarna een ’ping’. ACSS wordt momenteel enkel ondersteund [28] door Opera (Windows) en de screen readers Fire Vox, pwWebSpeak en EMACspeak (Linux). In het toekomstige CSS 3 formaat wordt ACSS vervangen door een nieuwe spraakmodule. Voorbeeldcode 11 Uitspraak van tekst door de screen reader aansturen met CSS 1 2 3 4

H1 { richness : 90; cue−b e f o r e : u r l ( ” p i n g . au ” ) }

◦ Relatieve fontgrootte In CSS kunnen relatieve waarden meegegeven worden aan de grootte van een lettertype, via em of procenten. De waarde van font-size moet zoveel mogelijk relatief geijkt worden. Internet Explorer 6 kan met het gebruik van pixels (niet relatief) tekst niet veranderen van grootte waarbij de verhoudingen met andere tekstgroottes gelijk blijven. Als basis fontgrootte mogen wel pixels gebruikt worden, bijvoorbeeld in body of html. 14 pixels is een ideale grootte voor gewone tekst. ◦ Structurele afbeeldingen Omdat screen readers alle afbeeldingen aan de gebruiker meedelen, al dan niet via het alt-attribuut, is het handig dat structurele afbeeldingen die niet essentieel zijn voor de inhoud verborgen blijven voor tekstuele browsers zoals screen readers. Meestal is dit het geval met structurele afbeeldingen die de lay-out bepalen van de website, of bijkomende afbeeldingen zoals een screenshot van de website waar een hyperlink naar verwijst.


41

Via CSS kunnen afbeeldingen aan een element worden toegekend via de background eigenschap. Het is zelfs mogelijk CSS-selectors te laten baseren op patronen in een attribuut van een HTML-element. Codevoorbeeld 12 toont hoe een icoontje van Facebook gezet kan worden naast elke link die naar een facebook.com pagina verwijst. Op die manier kunnen ook icoontjes geplaatst worden die het type link voorstellen (externe link, nieuw venster, bookmark, pdf, Worddocument,.. ). Voorbeeldcode 12 Een icoon van Facebook achter iedere facebook.com link a [ h r e f ∗=’ f a c e b o o k . com ’ ] { background−image : u r l ( ’ f a c e b o o k . png ’ ) ; }

1

◦ Image Replacement Technique Met background-image, beschreven in het vorig puntje, kan ook aan image replacement gedaan worden. Deze techniek maakt het mogelijk dat een tekst toch leesbaar is wanneer een specifieke techniek om ze weer te geven niet aanwezig is. In voorbeeldcode 13 wordt een introductietekst opgebouwd uit een afbeelding, hoewel ‘Introduction’ als tekst is gecodeerd. Dit komt omdat de tekst door een negatieve indent uit het scherm wordt geplaatst, en de afbeelding van background-image toch blijft staan. Het voordeel is dat een screen reader die de afbeelding negeert toch de titel kan voorlezen. Andere bekende Image Replacement Techniques zijn die om titels, opgemaakt in een Flashanimatie, van een alternatieve toegankelijke versie te voorzien, zoals sIFR. Voorbeeldcode 13 Image replacement met CSS 1 2 3 4 5 6 7 8

I n t r o d u c t i e
.. /∗ CSS ∗/ #i n t r o { t e x t −i n d e n t : −100em ; h e i g h t : 25 px ; background : u r l ( ’ i n t r o d u c t i e . g i f ’ ) no−r e p e a t ; }

2.2.2

Nog enkele CSS hints

◦ Achtergrondkleur Sommige gebruikers hebben een ander kleurenschema in hun browser omdat ze een skin zetten op hun operating systeem, zoals Windows Plum. Dit zorgt ervoor dat de standaard achtergrondkleur op een website niet wit is, maar bijvoorbeeld grijs. Om steeds het contrast met zekerheid te behouden tussen de achtergrondkleur en de kleur van de tekst, dien je dit specifiek te vermelden met CSS (codevoorbeeld 14). ◦ Goede leesbaarheid Bevorder steeds de leesbaarheid, ook voor vergrootglas-applicaties en personen met dislexie. Zoek het ideale evenwicht tussen de regelhoogte en tekstgrootte. Dit kan met de eigenschappen font-size en line-height.


42

Voorbeeldcode 14 Logische kleuren met CSS afdwingen body { background−c o l o r : # f f f ; }

1 2 3

◦ Definieer drukletters met CSS Woorden zoals ’CONTACT US’ worden door screen readers vaak gelezen als ’Contact U S’. Schrijf daarom dergelijke woorden met kleine letters in HTML, en maak er drukletters van via de CSS regel text-transform: uppercase. ◦ Onderlijn Designers vinden onderstreepte hyperlinksvaak lelijk in het uitzicht van een website. Volgens Jacob Nielsen, een van de grootste internet pioniers, moet een hyperlink onderlijnd worden zodat elke gebruiker weet dat het een link is. Ook de stippellijn rondom een gefocuste link heeft wel degelijk een accessibility reden. Stop deze dus niet weg. Het is zelfs geen slecht idee de boord te accentueren met de eigenschap outline. Om bijvoorbeeld een dik rood kader rond een gefocuste link te plaatsen, kan in CSS geschreven worden: :focus outline: thick solid red. ◦ Verkleurde links Net zoals bij onderstreepte hyperlinkshebben ontwerpers een hekel aan de andere kleur die een link krijgt wanneer de surfer deze reeds bezocht heeft. Dit is echter een visueel hulpmiddel en het moet aldus behouden worden. Het is wel mogelijk de kleur aan te passen, alsook de opmaak te definiëren van links in ’hover state’ (wanneer de muis erover hangt). In het eerste geval kan dit via :visited en in het tweede geval via :focus, :hover, :active (zie codevoorbeeld 15). De drie soorten hover states zijn nodig omdat Internet Explorer :focus niet ondersteunt. Voorbeeldcode 15 Kleuren van links en bezochte links met CSS a: visited { background−c o l o r : y e l l o w ; }

1 2 3 4 5 6 7 8

a : f o c u s , a : hover , a : a c t i v e { c o l o r : #990000; f o n t −w e i g h t : b o l d ; }

◦ Hyperlinks en kleurenblindheid Gebruikers die een of meerdere kleuren niet kunnen onderscheiden, kunnen soms het verschil niet zien tussen de kleur van een onbezochte hyperlink en een reeds bezochte hyperlink. Daarom bedacht Frank M. Palinkas van Opera een systeem met icoontjes, die in een legende bovenaan een webpagina worden verklaard. De icoontjes komen naast de hyperlink te staan via de background eigenschap van CSS en de selectors a:visited en a:link. Een uitgebreid artikel hierover staat op de site van Opera9 . 9

http://dev.opera.com/articles/view/building-accessible-static-navigation-wi/


43

◦ Elementen verbergen. Tekst die verborgen wordt met display: none of visibility: hidden is onzichtbaar op het scherm. Bij display: none lijkt het alsof de tekst er nooit geweest is en als visibility: hidden wordt gebruikt, neemt de tekst wel de voorbehouden ruimte in beslag, maar is er niets te zien. Verborgen tekst kan worden aangewend om informatie aan screen readers te geven die de gewone gebruiker van een browser niet hoeft te zien (bijvoorbeeld meer informatie voorzien voor een “Lees meer”link). Het gebruik van deze CSS-properties wordt in sommige screen readers doorgevoerd, zoals JAWS en NVDA. In andere screen readers zoals Home Page Reader wordt dit genegeerd, omdat het CSS niet ondersteunt. Beter is gebruik te maken van negatieve positionering die een element buiten het scherm plaatst (zie codevoorbeeld 16).

Voorbeeldcode 16 Verbergen via negatieve positie 1 2 3 4 5 6

. hidden { position : absolute ; l e f t : 0; top : −10000px ; o v e r f l o w : hidden ; }

Algemeen kan men stellen dat het verbergen van elementen zoveel mogelijk moet vermeden worden. Indien dit niet anders kan, dan moet men er trouwens zeker van zijn dat het ontbreken van JavaScript niet verhindert dat een element niet opnieuw zichtbaar kan gemaakt worden [48]: Stel dat het element standaard al op verborgen staat, en men wil dit met JavaScript activeren ten gevolge van een actie van de gebruiker. De gebruiker heeft echter JavaScript uitgeschakeld en hij zal het element dus nooit te zien krijgen. Men moet dus ervoor zorgen dat JavaScript het element op voorhand ook kan verbergen, indien men het later zichtbaar wil maken. ◦ Overmatig gebruik vermijden In sommige gevallen kan CSS een negatieve impact hebben op webtoegankelijkheid, zoals wanneer div’s elkaar teveel overlappen door toedoen van CSS positionering. Een voorbeeld daarvan is te vinden in referentie [55]. In Safari is het onmogelijk de naam van de auteur van het artikel te selecteren door erover te slepen, want een deel van de bovenliggende titel wordt mee geselecteerd.


2.3

44

HTML 5

In 2008 werd door het W3C de opvolger van HTML 4.01 gelanceerd: HTML 5, waarvan er ook een XHTML versie bestaat: XHTML 2. Hier werd maar liefst 5 jaar aan gewerkt waarvan het grootste deel door WHATWG (Web Hypertext Application Technology Working Group), bestaande uit Apple, the Mozilla Foundation en Opera Software10 . De specificatie is trouwens voorlopig enkel beschikbaar als ‘public working draft’ moet en dus moet de laatste hand nog gelegd worden, men vermoedt in oktober dit jaar [58]. Tot op heden ondersteunen slechts een handvol browsers de mogelijkheden van HTML 5. Safari (versie 4.0.2) en Opera (versie 9.6.4) [25] nemen de grootste voorsprong. Er bestaat een lijst met de huidige stand van zaken11 . Voor Internet Explorer 8 moeten enkele nieuwe DOM elementen met JavaScript worden geregistreerd zodat CSS ze kan aanspreken12 .

2.3.1

Veranderingen t.o.v. HTML 4

Het grote voordeel van HTML 5 is de ondersteuning voor semantische elementen, zodat een webpagina kan onderverdeeld worden in herkenbare sections. Dit is van belang voor de toegankelijkheid omdat bijna alle websites gemeenschappelijke onderdelen hebben. Een uniforme markering voor veel terugkerende secties maakt het voor screen readers nog eenvoudiger pagina’s te overlopen of delen te verbergen. Er zijn nog meer veranderingen in HTML 5 met betrekking tot web accessibility. Een volledig overzicht is te vinden op http://www.w3.org/TR/html5-diff/ , en de volledige specificaties van HTML 5 op http://www.whatwg.org/specs/web-apps/current-work/ Hier volgt een beknopt overzicht: Krachtigere formulieren Oorspronkelijk waren deze specificaties gepland in Web Forms 213 (ook van WHATWG) maar zijn ze nu grotendeels opgenomen in HTML 5. Tot op heden zijn de mogelijkheden van Web Forms 2 enkel ge¨ımplementeerd in de browser Opera. Een van de voordelen van deze formulieren is dat het voor bepaalde elementen beroep zal doen op de user interface van het onderliggende besturingssysteem. Een uitstekend voorbeeld is de datum-kiezer (zie figuur 2.1 en codevoorbeeld 17). Terwijl dit in HTML 4 moest gemaakt worden met JavaScript, kan dit nu in 1 enkele regel. Het resultaat is opgebouwd met bouwstenen van het onderliggende operating systeem, wat op accessibility vlak een goede zaak is. Andere uitgewerkte voorbeelden zijn terug te vinden op de website van W3C14 . 10 11 12 13 14

http://www.whatwg.org http://wiki.whatwg.org/wiki/Implementations in Web browsers http://html5doctor.com/how-to-get-html5-working-in-ie-and-firefox-2/ http://www.whatwg.org/specs/web-forms/current-work/ http://www.w3.org/2007/03/WF2/Overview.html


45

Voorbeeldcode 17 Datum kiezer in HTML 5 1

Figuur 2.1: Datum kiezen met HTML 5

Audio en video Door de nieuwe audio en video elementen van HTML 5 hoeft een webontwikkelaar geen rekening meer te houden met het eventueel ontbreken van specifieke plug-ins voor browsers. Vandaag wordt vooral Adobe Flash gebruikt om de zekerheid te bieden dat de video of het geluidsbestand kan afgespeeld worden in de browser van de gebruiker. Flash video’s hebben echter grote tekortkomingen op het vlak van toegankelijkheid. Op een speciale pagina van Youtube15 kan de nieuwe video-tag uitgetest worden (zie codevoorbeeld 18). Het formaat van het filmpje op Youtube is MP4, maar dit kan evengoed MPEG of AVI zijn, zolang de browser het ondersteunt. Merk ook de mogelijkheid op om de video te besturen met button elementen, en het p-element voor meer informatie. Jammer genoeg heeft voorlopig enkel Safari een aanvaardbare implementatie van het video element. Andere browsers lijken niet te volgen16 en sommige codecs zullen zelfs uiteindelijk niet ondersteund worden in HTML 5 [56]. Toch is er geen reden tot paniek. Toen HTML 1 werd ge¨ıntroduceerd, vloog de IMG tag aanvankelijk terug naar de achtergrond, maar werd later dan toch door alle browsers opgenomen. Sommige personen zoals de directeur van Opera geloven toch dat de nieuwe open standaarden van HTML 5 de Flash-video’s overbodig zullen maken [57]. Vandaag is er echter nog geen enkele browser die alle mogelijkheden van de audio en video elementen ondersteunt. FireFox 3.5+ [36], Safari 3.1+ [22] [21], Chrome 3 [31] en Opera 10 [19] doen dit wel, maar in beperkte mate. FireFox en Opera hebben bijvoorbeeld nog geen support voor het MP3-formaat. Uitgebreide informatie over het audio-element is te vinden op html5doctor17 . 15

http://www.youtube.com/html5 De HTML5 implementatie van Tinyvid ( http://tinyvid.tv/show/3d198wqepg78m ) werkt wel in FireFox 3.5 en dan weer niet in Safari 17 http://html5doctor.com/native-audio-in-the-browser 16


46

Voorbeeldcode 18 HTML 5 implementatie van een Youtube video 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Meer i n f o r m a t i e o v e r de v i d e o kan h i e r komen . .

You must have an HTML5 c a p a b l e b r o w s e r .

Nesting van headings Dankzij het nieuwe section element is het mogelijk meerdere heading-elementen te plaatsen op een pagina. Ontwikkelaars komen dikwijls niet toe met h1, h2 en h3 om nieuwe subtitels te definiëren. Codevoorbeeld 19 toont wat nu mogelijk is. Code zoals
is hierdoor niet meer nodig en dit is in het voordeel van screen readers. Voorbeeldcode 19 Nesting van headings 1 2 3 4 5 6

T i t e l p a g i n a

S u b t i t e l
<s e c t i o n>
T i t e l s e c t i e

. .

Groepering elementen Het element figure kan een onderschrift koppelen aan een afbeelding, video, lijst, enzovoort, wat de toegankelijkheid ten goede komt (zie figuur 20). Voorbeeldcode 20 Groeperen met het figure-element 1 2 3 4

< f i g u r e> i n f o o v e r f o t o

Sommige ontwikkelaars [40] geloven zelfs dat het figure-element belangrijker kan worden dan een alt of longdesc-attribuut, omdat er meer opmaakmogelijkheden bestaan voor bijkomstige informatie. Een ander argument is dat afbeeldingen die de inhoud bepalen op die manier vlugger zullen aanzien worden als betekenisvol door screen readers en dat onbelangrijke afbeeldingen voor bijvoorbeeld opmaak zo gemakkelijk kunnen worden overgeslaan.


47

Groter klikgebied In HTML 5 is het mogelijk meerdere soorten elementen in een hyperlink te plaatsen. Dat maakt het klikgebied trouwens groter (zie codevoorbeeld 21). Het alt-attribuut van de klikbare foto kan nu volledig kan gewijd worden aan zichzelf, terwijl het in HTML 4 de hyperlink moest beschrijven. Voorbeeldcode 21 Een groter klikgebied 1 2 3

T i t e l van een a r t i k e l

Lorem ipsum d o l o r s i t amet , c o n s e c t e t u r a d i p i s i c i n g e l i t

L e e s meer

4 5

Event model voor drag-and-drop operaties Drag-and-drop operaties zijn al langer ondersteund door JavaScript-frameworks, maar met HTML 5 komt er hiervoor nu ook standaard ondersteuning in browsers. Het DOM wordt uitgebreid met attributen zoals draggable en events ()dragstart, drop en dragover). Deze kunnen vervolgens in JavaScript opgevangen worden. Codevoorbeeld 22 illustreert dit. In de bijlagen op pagina 94 wordt uitgelegd hoe een drag-and-drop-operatie in de praktijk toegankelijk kan gemaakt worden met ARIA. Tot nog toe hebben enkel FireFox 3.5, Safari en Internet Explorer 8 de drag-and-drop-events ge¨ımplementeerd. In Safari werkt het draggable-attribuut mits een CSS tweak. Er zijn ook oplossingen voor de andere browser via JavaScript18 . De volledige specificatie van drag-and-drop events in HTML 5 kan gelezen worden de site van W3C19 . En nog veel meer Andere semantische elementen in de nieuwe HTML 5 specificatie zijn o.a. details, time, required en Microdata20 (niet te verwarren met de microformats-specificatie die enkel gebaseerd is op class names). 18 19 20

http://html5doctor.com/native-drag-and-drop/ http://dev.w3.org/html5/spec/Overview.html#dnd http://www.whatwg.org/specs/web-apps/current-work/#microdata


Voorbeeldcode 22 Drag-and-drop met jQuery en HTML 5 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

Drag me !
Drop h e r e ! <s c r i p t type=’ text / j a v a s c r i p t ’> $ ( document ) . ready ( f u n c t i o n ( ) { $ ( ’# n e w s c h o o l . dragme ’ ) . a t t r ( ’ draggable ’ , ’ true ’ ) . bind ( ’ d r a g s t a r t ’ , f u n c t i o n ( ev ) { var dt = ev . o r i g i n a l E v e n t . d a t a T r a n s f e r ; dt . s e t D a t a ( ’ Text ’ , ’ Dropped i n zone ! ’ ) ; return true ; }) . bind ( ’ dragend ’ , f u n c t i o n ( ev ) { return f a l s e ; }) ; $ ( ’# n e w s c h o o l . drophere ’ ) . bind ( ’ d r a g e n t e r ’ , f u n c t i o n ( ev ) { $ ( ev . t a r g e t ) . a d d C l a s s ( ’ d r a g o v e r ’ ) ; return f a l s e ; }) . bind ( ’ d r a g l e a v e ’ , f u n c t i o n ( ev ) { $ ( ev . t a r g e t ) . remov eClass ( ’ d r a g o v e r ’ ) ; return f a l s e ; }) . bind ( ’ d r a g o v e r ’ , f u n c t i o n ( ev ) { return f a l s e ; }) . bind ( ’ drop ’ , f u n c t i o n ( ev ) { var dt = ev . o r i g i n a l E v e n t . d a t a T r a n s f e r ; a l e r t ( dt . getData ( ’ Text ’ ) ) ; return f a l s e ; }) ; }) ;

48


2.3.2

49

HTML 5 of XHTML 2 ?

In de meeste moderne browsers is er ondertussen ondersteuning voor HTML 5. Het gebruik van XHTML 2, dat volledig onderworpen is aan XML regels, wordt afgeraden omdat onder meer Internet Explorer er problemen mee heeft, en het W3C recent [42] besloten heeft zich vooral te concentreren op HTML 5. Het is echter wel interessant de schrijfstijl van XHTML 2 in HTML 5 te gebruiken, mocht er in de toekomst toch nog sprake zijn van XHTML 2. Wil men volledig gebruik maken van XHTML 2, dan dient het juiste MIME type te worden meegegeven. Dit kan geforceerd worden in een .htaccess bestand van een directory met de regel: AddType application/xhtml+xml .xhtml Wordt dit niet gedaan, dan zal de browser het XHTML 2 bestand zien als gewone HTML 5 code. Omdat Internet Explorer en oude versies van Opera het formaat XHTML 2 nog niet ondersteunen kan via scripting bepaald worden welke browser het juiste MIME type moet meekrijgen. Voorbeelden in PHP en ASP.NET zijn te vinden op de website 456breastreet21 . Voorbeeldcode 23 Een correcte structuur voor XHTML 2 1 2 3 4 5 6 7 8 9

Example document
Example paragraph

2.4

WAI-ARIA

WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) is een protocol ontwikkeld door W3C om Rich Internet Applications toegankelijker (RIA) te maken. Vaak laat men het voorvoegsel WAI vallen en spreekt men over ARIA. Het is bedoeld om meer semantiek te brengen in onduidelijke of ingewikkelde HTML structuren. Het ARIA protocol is de oplossing voor vele toegankelijkheidsproblemen die Ajax met zich meebrengt. Voornamelijk het onvermogen van een screen reader om te weten welke elementen door Ajax in de code zijn veranderd, en hoe de gebruiker op de hoogte moet gebracht worden. ARIA komt hieraan tegemoet. Het bekendste attribuut dat ARIA gebruikt is role. Dit kan verbonden worden aan HTMLelementen zodat een screen reader kan weten wat de functionaliteit ervan is. Op die manier kan er ook sneller met het toetsenbord genavigeerd worden, zonder al teveel op Tab te moeten drukken. Een voorbeeld van een role die een gebied omschrijft is
..
. 21

http://www.456bereastreet.com/archive/200408/content negotiation/


50

Roles zijn de oplossing voor het toegankelijkheidsprobleem van zelf ontwikkelde user interfaces. Men wil bijvoorbeeld een selectievakje grafisch aantrekkelijk maken. In plaats van te werken met de klassieke HTML-code hiervoor, wordt het nagebouwd met afbeeldingen, CSS en JavaScript. Een screen reader zal dit echter niet herkennen als een selectievakje maar door het geheel een role met waarde checkbox mee te, kan dit wel. Het geheel kan nog toegankelijker gemaakt worden met de attributen onkeydown en onclick. De WAI-ARIA specificatie kan worden onderverdeeld in volgende elementen: ◦ Roles beschrijven de functie van een element of verzameling van elementen. Ze worden gekoppeld aan een element via het attribuut role. Er kunnen meerdere roles toegekend worden door ze te scheiden door een spatie. De waarde van het role attribuut hoort niet dynamisch veranderd te worden (bijvoorbeeld via JavaScript), om screen readers niet onnodig te verwarren. · widget roles. Mogelijke waarden zijn progressbar, slider, button, tree, textfield, checkbox, alert en dialog. · structural roles / landmarks roles. Deze roles dienen om gebieden op een pagina aan te duiden die vaak terug keren op websites. Mogelijke waarden zijn main, secundary, group, section, liveregion, tab, navigation, menubar, toolbar, breadcrumbs, search en banner. Een volledige lijst van alle mogelijke waarden is te vinden op http://www.w3.org/TR/wai-aria/ . ◦ States beschrijven de toestand van een element. In tegenstelling tot roles mogen zij wel dynamisch veranderd worden. Mogelijke states zijn busy, expanded, invalid, checked, grab, pressed, disabled, hidden en selected. ◦ Properties zijn zoals states, maar beschrijven eerder een eigenschap dan een toestand. Sommige properties kunnen dynamisch veranderd worden, terwijl anderen beter statisch blijven (zoals ’required’). Sommige properties kunnen bij een role horen, zoals required bij textfield kan staan. Mogelijke properties zijn activedescendant, atomic, autocomplete, channel, controls, datatype, describedby, dropeffect, flowto, haspop-up, labelledby, level, live, multiline, multiselectable, owns, posinset, readonly, relevant, required, secret, setsize, sort, tabindex, templateid, valuemax, valuemin en valuenow. De bovenstaande properties zijn geen ’waarden’ zoals bij roles, maar namen van attributen. Een voorbeeld van een geldige property met een waarde is:


2.4.1

51

Live regions

Sommige properties zijn bedoeld om live regions aan te duiden. Dit zijn gebieden op een pagina die gevoelig zijn voor verandering, bijvoorbeeld ten gevolge van automatische updates door Ajax. Volgende properties komen in aanmerking: atomic, live, busy, relevant en channel. ◦ Live is property die de waarden off, polite en assertive kan aannemen. Ze stellen een niveau van beleefdheid voor. Het wordt gebruikt om aan een screen reader te vertellen of de gebruiker moet verwittigd worden bij een verandering. Bij het niveau assertive zal de screen reader de gebruiker altijd informeren bij een verandering, of tenminste zo snel mogelijk. Bij polite wordt er gewacht tot de gebruiker klaar is met zijn huidige actie. Er bestaat zelfs een niveau rude dat aangewend dient te worden voor zeer dringende boodschappen. Voorbeeldcode 24 Live region met ARIA
..

1 2 3

◦ Atomic wordt gebruikt om de screen reader te laten weten of hij heel het omvattende gebied moet meedelen dat veranderd is, of enkel het deel dat effectief is gewijzigd. Het neemt de waarden true of false aan. ◦ Busy op true plaatsen vertelt de screen reader dat hij moet wachten met het aankondigen van de verandering totdat alle elementen geladen zijn. ◦ Relevant is een property die een lijst bevat met door spatie gescheiden waarden additions, removals, text en all. Dit zijn de type gebeurtenissen die zich kunnen voordoen bij een verandering. De screen reader mag enkel de verandering meedelen als het van het type is dat in het attribuut relevant is opgegeven (zie codevoorbeeld 25). Voorbeeldcode 25 Relevant: De screen reader zal enkel waarschuwen als er elementen zijn toegevoegd

1 2 3

2.4.2

ARIA en tabindex

ARIA zorgt ervoor dat elk DOM-element het attribuut tabindex kan krijgen. Met tabindex kan een element gefocust worden, zodat de screen reader zich daarop positioneert en het element met het toetsenbord direct kan worden aangestuurd.


52

Dit komt handig van pas wanneer een webapplicatie via Ajax of JavaScript een foutmelding op het scherm toont. De screen reader kan dit niet automatisch opmerken, tenzij het een focus krijgt. Er zijn twee manieren om een element gefocust te krijgen tijdens een actie. Het wordt geprogrammeerd via JavaScript: ◦ Zet tabindex op 0. Dit zorgt ervoor dat het element gefocust wordt. ◦ Zet tabindex op -1. Dit zorgt voor hetzelfde effect, maar moet toegepast worden wanneer de gebruiker de actie zelf activeert, bijvoorbeeld door een muisklik.

2.4.3

ARIA en screen readers

In hoofdstuk 4 wordt onderzocht hoe screen readers omgaan met ARIA. In de bijlagen op pagina 94 wordt uitgelegd hoe een drag-and-drop-operatie in de praktijk toegankelijk kan gemaakt worden met ARIA.

2.4.4

Ondersteuning in HTML

HTML 4 en XHTML 1.1 Algemeen wordt gesteld dat HTML 4 het gebruik van ARIA-code niet ondersteunt, omdat HTML 4 niet uitbreidbaar is met namespaces (zie woordenlijst op pagina 1) voor de namen van de properties en states. XHTML 1.1 is wel uitbreidbaar (zie codevoorbeeld 26). De prefixen wairole, waistate en x2 worden gedefiniëerd voor de head-sectie van de code. De prefix x2 is in principe niet nodig in browsers die het attribuut role ondersteunen. Voorbeeldcode 26 Geldige ARIA code in XHTML 1.1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

< !DOCTYPE html PUBLIC ’ −//W3C//DTD XHTML 1 . 1 / /EN’ ’ h t t p : / /www. w3 . o r g /TR/ xhtml11 /DTD/ xhtml11 . dtd ’> .. ..

Copyright © 2024 ADOC.PUB. All rights reserved.
About Us | Privacy Policy | Terms of Service | Copyright | Contact Us | Cookie Policy

Sign In

Email

Password

Remember me Forgot password?

Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close

De p r i j z e n van f r u i t en g r o e n t e n

Rode p a p r i k a s Pink l a d i e s a p p e l e n

D e l h a i z e &e u r o ; 0 . 8 0 &e u r o ; 1 . 2 0
C a r r e f o u r &e u r o ; 1 . 0 0 &e u r o ; 1 . 6 0

Gemiddelde &e u r o ; 0 . 9 0 &e u r o ; 1 . 4 0

Arteveldehogeschool. Eindwerk. Web Accessibility. Rich Internet Applications toegankelijk maken voor gebruikers met een functiebeperking

Recommend Documents

,

, ..

Skip t o c o n t e n t

T i t e l p a g i n a

I n t r o d u c t i e

T i t e l p a g i n a

S u b t i t e l

T i t e l s e c t i e

T i t e l van een a r t i k e l