Met AJAX kun je door het gebruik van scripts onderdelen van een pagina verversen zonder dat de hele pagina opnieuw moet worden geladen. Dat scheelt voor bezoekers van de site snelheid en bovendien dataverkeer. AJAX wordt voor het eerst op het internet genoemd in 1997en staat voor ‘Asynchronous JavaScript and XML’. Natuurlijk is het beter voor de toekomst van een site als gewerkt wordt met de XML-standaard en alle afgeleiden daarvan maar die worden op dit moment nog niet door alle browsers ondersteund. AJAX heeft daarom de kans om snel op te komen. Hopelijk is er snel een oplossing of wordt de techniek opgenomen door W3C of een andere standaardisatie organisatie. AJAX is meestal slecht toegankelijk omdat er gewoonweg geen rekening met toegankelijkheid wordt gehouden en omdat er geen alternatief is.
**********
26-9-2006 (update):
Het W3C heeft de eerste concept versie uitgebracht van Accessible Rich Internet Applications (WAI-ARIA). De nieuwe WAI-ARIA richtlijnen maken toegankelijkheid van dynamische web content zoals AJAX en DHTML straks mogelijk. Er zijn maar liefst drie documenten ontworpen om dit mogelijk te maken.
De roadmap beschrijft de toegankelijkheid van dynamische Web content gemaakt met technologieën als AJAX en DHTML. Roles biedt oplossingen voor gebruikers interface instrumenten en navigatie API’s. States and Properties legt het verband tussen behaviours en opmaak van het document. Het werk is nog in de concept fase. Experts worden opgeroepen mee te werken aan de verdere uitwerking. Nu al geeft het document een duidelijk inzicht in de richting die W3C in samenwerking met belanghebbenden heeft genomen.
**********
Ontwikkelaars van websites waren denk ik al langere tijd jaloers op de interactiviteit en de snelheid van desktop software. Die kloof lijkt nu met AJAX op een eenvoudige manier en met gebruikmaken van bestaande technieken gedicht te zijn. Tenminste totdat de XML familie echt wordt ondersteund want die werkt natuurlijk beter en scheelt op de lange termijn veel hoofdpijn. Hou bij AJAX toepassingen dus rekening met toegankelijkheid en hou het simpel, want je wenst je beste vrienden geen gecompliceerde AJAX toepassing toe...
De werking van AJAX is snel te zien bij Google suggests. Terwijl je een woord intypt wordt constant de lijst van zoekwoorden ge-update. Het mooie bij Google suggest is dat het formulier ook bruikbaar is zonder JavaScript ondersteuning. Daaruit blijkt dat toegankelijkheid ingebouwd kan worden. Weliswaar is dan wel een deel van de functionaliteit weg maar de informatie is nog steeds bereikbaar.
AJAX is ook de basis voor Google Maps, Gmail, Flickr, del.icio.us, Basecamp en anderen. Volgens de kenners gaat AJAX de manier waarop we omgaan met het web grondig wijzigen. Daarom worden AJAX en Web 2.0 vaak in een adem genoemd. Hopelijk duurt dat niet meer al te lang.
AJAX is niet nieuw, het is eerder een handige combinatie van verschillende bestaande webtechnieken en standaarden. Je kunt met AJAX interactieve websites bouwen zonder dat mensen dingen hoeven te installeren (De meeste browsers ondersteunen het standaard). Dat is ook de belangrijkste reden voor het grote succes: het werkt in principe op iedere moderne browser die JavaScript (of precieser XML-http-request) ondersteunt. Voor wie het graag technisch wil: AJAX maakt gebruik van standaard technologieën voor het web zoals HTTP, (X)HTML, CSS, JavaScript, Document Object Model (DOM) en XML. Er kan dus als een bouwer of opdrachtgever dat wil volgens de W3C webstandaarden worden gewerkt aan kwaliteit en toegankelijkheid. Niet echt nieuw dus!
Het verschil tussen pagina’s met AJAX en traditionele pagina’s met javascript zit hem in de XML-http-request. Als iemand nieuwe data van een pagina opvraagt, dan wordt niet zoals bij traditionele pagina’s de hele pagina opnieuw geladen maar alleen de nieuwe of missende data. Daardoor is de communicatie over en weer met een pagina dus ook sneller. Voor webwinkels dus een belangrijke technologie. Jesse James Garret geeft in zijn artikel ‘Ajax: A New Approach to Web Applications’: (februari 2006) een mooie definitie en een duidelijk overzicht van AJAX. Voor de liefhebbers is er een meer technische uitleg van de XML-http-request door Drew McLellan ‘Very dynamic web interfaces’:
Er is ruzie online over wie het heeft uitgevonden. Gregg Travis was er bijvoorbeeld al in 1997 mee bezig, maar dat er mensen zijn die het eerder claimen hoeft niemand te verwonderen. Hierboven is al geconcludeert dat AJAX een combinatie is van verschillende bestaande webtechnieken en standaarden.
JavaScript werd in 2006 gebruikt op 57 procent van de websites (http://www.securityspace.com/s_survey/data/man.200608/techpen.html). Daarmee heeft het een enorme invloed op de (on)toegankelijkheid van het internet.
Als het gaat om AJAX hebben W3C en de Webrichtlijnen van de Nederlandse overheid een aantal relevante richtlijnen:
W3C IJkpunt WCAG 6.3: "Zorg ervoor dat pagina's bruikbaar zijn, als scripts, applets of andere programma-objects uitstaan of niet worden ondersteund. Als dit niet mogelijk is, lever dan equivalente informatie op een alternatieve toegankelijke pagina". Voor wie AJAX gebruikt is dit een moeilijk ijkpunt om aan te voldoen. Het ijkpunt eist dat de informatie en de functionaliteit van de pagina met en zonder AJAX beschikbaar moeten zijn (prioriteit 1/drempelvrij).
W3C IJkpunt WCAG 6.4: Zorg er in het geval van scripts en applets voor dat event handlers onafhankelijk zijn van het invoerapparaat (prioriteit 2). Een Event handler is een script dat start als er iets gebeurt, als bijvoorbeeld de muis beweegt, als er wordt geklikt, als een toets wordt ingedrukt. Event handlers attributen beginnen vaak met "on", zoals in "onclick" en "onmouseover". Event handlers kunnen berekeningen uitvoeren, formulieren opsturen en meer. Als Event handlers meer doen dan de presentatie van een element wijzigen, dan moeten ontwikkelaars volgens het W3C het volgende doen:
"Use application-level event triggers rather than user interaction-level triggers. In HTML 4.01, application-level event attributes are "onfocus", "onblur" (the opposite of "onfocus"), and "onselect". Note that these attributes are designed to be device-independent, but are implemented as keyboard specific events in current browsers."
Als het in het geval van scripts en applets niet lukt om event handlers onafhankelijk te laten zijn van het invoerapparaat, lever dan extra input mogelijkheden. Specificeer dan bijvoorbeeld twee handlers voor hetzelfde element:
W3C IJkpunt WCAG 7.3: Vermijd beweging in pagina's totdat user agents gebruikers in staat stellen bewegende content te bevriezen. Als er dus bewegende delen in een pagina zijn, bijvoorbeeld via scripts of style sheets, zorg dan dat de gebruikers dat effect gemakkelijk kunnen uitzetten of ongedaan maken. Dit is tegenwoordig vaak met de escape toets mogelijk.
W3C IJkpunt WCAG 8.1: Maak elementen zoals scripts en applets direct toegankelijk of compatibel met hulptechnologieën. Prioriteit 1 als functionaliteit belangrijk is en niet elders gepresenteerd, anders Prioriteit 2.
W3C IJkpunt WCAG 9.2: Zorg ervoor dat elk element dat zijn eigen interface heeft, aangestuurd kan worden op een apparaatonafhankelijke manier.
W3C IJkpunt WCAG 9.3: Specificeer voor scripts liever logische event handlers dan apparaatafhankelijke event handlers.
Ook W3C ijkpunten ten aanzien van formulieren zijn van belang voor AJAX. Het is belangrijk dat mensen met een screenreader zelf een formulier kunnen invullen bijvoorbeeld zonder dat de focus steeds naar het begin van de pagina verschuift door een pagina-refresh. In het kader van de toegankelijke interactie met dynamische content heeft W3C een Dynamic Accessible Web Content Roadmap opgesteld. Deze geeft een goed inzicht in de richting die we uitgaan en is verplichte leeskost voor mensen die toegankelijke content willen maken.
Relevante Webrichtlijnen zijn:
R-pd.14.1 Gebruik geen client-side script voor onmisbare functionaliteit op webpagina’s, tenzij het gebrek aan ondersteuning voor deze scripts voldoende wordt afgevangen door HTML alternatieven en/of server-side script. Dit is vergelijkbaar met de richtlijnen van het W3C die eisen dat pagina's ook werken als scripts niet worden ondersteund. JavaScript en andere scripttalen mogen dus wel als ze gebruikt worden volgens de specificatie, als ze maar een alternatief hebben voor mensen en machines die het niet ondersteunen.
R-pd.1.3 Maak de functie van de website niet afhankelijk van optionele technologie, zoals CSS en client-side script: optionele technologie dient de informatie op de site en het gebruik ervan te complementeren en niet de toegang ertoe te belemmeren wanneer deze technologie niet ondersteund wordt.
R-pd.2.7 Indien client-side script wordt gebruikt, gebruik ECMAScript volgens de specificatie.
R-pd.13.5 Gebruik geen client-side script of formulieren als de enige manier om informatie op de site te bereiken. Deze heeft natuurlijk te maken met de anderen die hierboven staan.
De beste manier om uit te vinden of deze Web 2.0 toepassingen met AJAX werken is door het met gebruikers uit te proberen. Joe Clark deed dat, met Basecamp. Hij legde de richtlijnen voor toegankelijkheid van W3C even aan de kant, daar is hij namelijk niet zo’n fan van en vroeg aan gebruikers of zij er nog kaas van konde maken: Bekijk de testresultaten van het onderzoek van Joe Clark. De bevindingen zijn niet schokkend slecht, maar ook niet geweldig hoopvol. Hij heeft er een mooi artikel over geschreven: .
Toegankelijkheid en AJAX kan dus wel maar vergt wel een aanpak vanaf het begin. Dus niet achteraf een opleveringskeurinkje en dan nog even wat aanpassingen doen maar direct vanaf het begin gebruikers inschakelen en meenemen in de testen. Deze aanpak levert dan echter wel een enorm aantal voordelen op waarvan kostenbesparing wel de balangrijkste is en direct daarna de toegankelijkheid voor iedereen, zelfs voor mensen met een functiebeperking en senioren.
Zoals de richtlijnen van W3C en overigens ook de Webrichtlijnen voorschrijven moet de informatie en functionaliteit van pagina’s ook beschikbaar zijn met en zonder scripts en applets. Als AJAX niet wordt ondersteund zorg dan dat de browser kan terugvallen op de erkende standaarden voor code. Als JavaScript uitstaat (bijvoorbeeld vanwege beveiliging van de computer van de bezoeker) zorg dan voor een alternatief als basis. Dit heet in mooie termen, de unobstrusive JavaScript aanpak. Er is dan altijd en voor iedere gebruiker een opvang. In de handleiding van de Webrichtlijnen staat een wat uitgebreidere uitleg over gelaagd bouwen.
Het kan bijvoorbeeld handig zijn als bij het invullen van een bepaald formulierveld telkens na het typen van een letter resultaten worden getoond onder het invulveld. Er wordt dan technisch gezien een onchange event handler aangeroepen en een aanvraag naar de server gedaan. De server zendt de gevonden resultaten terug die dan direct onder het invulveld worden getoond. Mensen met een Screenreader zien dat niet maar worden ook niet bij het invullen gestoord omdat de focus op het invulveld blijft. Voor anderen kan het juist een uitkomst zijn. Zij hoeven alleen nog maar via de tabtoets of met de muis naar het resultaat te gaan onder het invulveld. Als JavaScript uitstaat kan het invulveld dus nog steeds gebruikt worden.
Uitleg van W3C ijkpunt 63 over dat sites ook moeten werken zonder scripts en applets.
W3C over toegankelijkheid van dynamische content
http://www.webstandards.org/2006/05/04/ajax-accessibility-and-screenreaders/
http://www.sitepoint.com/subcat/javascript
http://www.accessifyforum.com/viewtopic.php?t=2660
http://www.sitepoint.com/blogs/2005/03/10/usability-and-accessibility-with-ajax/
http://webaim.org/techniques/javascript/
Steven Pemberton keek alvast vooruit naar Web 4.0: http://www.w3.org/2006/Talks/06-08-steven-web40/. Chris Freshcontext (gelukkig niet zijn of haar echte naam, hoop ik tenministe) is van mening dat Web 3.0 gaat om het semantic web (voor interactie tussen machines) en dat Web 4.0 het ‘lerende web’ is, meer richting artificial intelligence: http://blog.outer-court.com/forum/17079.html
