Op 29 maart organiseert ITworks een seminarie over Ajax: “Ajax voor web developers”. Ik ben uitgenodigd om er een halfuurtje vol te praten over de toegankelijkheidsproblemen die Ajax kan veroorzaken en welke oplossingen voorhanden zijn.
Ajax is leuk, Ajax is fijn, maar het is ook erg buzzz. Voor de webbies die vandaag ontwaken uit een coma die geduurd heeft sinds 18 februari 2005: Ajax is een modewoord voor de techniek waarbij een stukje van een webpagina ververst wordt met gegevens die — op de achtergrond — van een webserver worden geplukt.
Een typische Ajax-applicatie gebruikt JavaScript en het XMLHttpRequest object voor het uitwisselen van data met de webserver, een collectie serverscripts voor de verwerking, XML als datatransportmiddel, nette XHTML voor de markup van de pagina’s, CSS voor de vormgeving en — opnieuw — JavaScript om de inhoud van de webpagina in real time bij te werken — enkel waar dat nodig is. Wat voor code op de server wordt uitgevoerd, is niet van belang: dat kan PHP, ASP.Net, ColdFusion of nog wat anders zijn. Wat wel belangrjik is, is dat het antwoord dat de server terugstuurt, opgepikt en verwerkt kan worden door het script aan de client-zijde. XML is hiervoor het best geschikt, vandaar de x in Ajax.
Als je net uit een coma ontwaakt, kan dat best verwarrend klinken. Een bekend scenario ter illustratie:
Je wil je registreren voor een webdienst. Je vult de gewenste gebruikersnaam en wat andere gegevens in en klikt vervolgens op de verzendknop. in de statusbalk van je browser verschijnt een voortgangsbalkje en even later floept een andere pagina op je scherm. Je browser heeft een volledige nieuwe pagina opgevraagd, terwijl er eigenlijk niet veel veranderd is: enkel een rood kruisje duidt aan dat de gekozen gebruikersnaam al in gebruik is en je dus een andere moet kiezen.
Met Ajax zou het zo kunnen: nog terwijl je de gebruikersnaam aan het intypen bent, zie je het kruisje verschijnen of weer verdwijnen. Omdat er erg weinig gegevens over en weer gestuurd hoeven te worden en de communicatie met de server asynchroon verloopt, kan bij iedere toetsaanslag een verzoek naar de server gestuurd worden om te controleren of de ingetypte tekenreeks herkend wordt als een gebruikersnaam die voorkomt in de database. Met behulp van DOM-manipulatie kan de HTML-code waaruit de pagina is opgebouwd en die ondermeer de markup voor de weergave van het kruisje bevat, live worden bijgewerkt — tijdens het typen.
Dat is een relatief eenvoudig voorbeeld van hoe je Ajax kan gebruiken om de gebruikservaring van webapplicaties te verhogen, maar Ajax kan natuurlijk nog veel meer.
Tijdens het seminarie wil ik het hebben over welke gevolgen Ajax heeft voor de toegankelijkheid van je website en wat je kan doen om Ajax toegankelijk(er) te maken:
- Wat is graceful degradation, of hoe kan je ervoor zorgen dat Ajax-applicaties hun functionaliteit behouden als JavaScript uigeschakeld of niet beschikbaar is?
- Moderne hulpprogramma’s voor blinden en slechtzienden bieden ondersteuning voor JavaScript, maar de manier waarop deze internetgebruikers de inhoud van een webpagina opnemen (m.b.v. kunstmatige spraak, braille of schermvergroting) maakt het moeilijk om dynamische updates op een pagina op te merken of te localiseren. Er zijn verschillende — goeie, en minder goeie — methodes om daar een mouw aan te passen. Ik zal ze demonstreren aan de hand van praktische voorbeelden.
8 reacties
1 Pascal Van Hecke // 11 maart 2006 om 12:22 pm
Wow!
Ik kom zeker :-))
2 Erlend // 12 maart 2006 om 10:28 am
Oh Oh…ik zou er maar al te graag naartoe willen gaan maar dat valt midden in mijn stage.
3 Christophe Strobbe // 23 maart 2006 om 6:53 pm
Een half uurtje is nogal kort voor wie in toegankelijkheid ge?nteresseerd is, maar ik ben wel nieuwsgierig. Ik vraag me bijvoorbeeld af of AJAX gebruikt kan worden om aan het volgende criterium uit WCAG 2.0 te voldoen: “When an authenticated session has an inactivity timeout, the user can continue the activity without loss of data after re-authenticating.” (Zie http://www.w3.org/TR/2005/WD-WCAG20-20051123/guidelines.html#time-limits-server-timeout; hopelijk wordt WCAG 2.0 binnenkort een ‘Last Call Working Draft’.)
4 Roel // 25 maart 2006 om 12:46 pm
@Christophe: Interessant. Het is idd mogelijk om alle ingevoerde gegevens op een pagina op afgesproken tijdsintervallen te bewaren m.b.v. Ajax calls waar de gebruiker niets van merkt. Dat zou bvb. interessant zijn voor applicaties als Tax-on-Web waar ‘gewone’ bezoekers al erg veel tijd doorbengen op eenzelfde pagina, maar waar mensen met een functiebeperking mogelijk nog een stuk meer tijd voor nodig hebben. Als er dan een timeout optreedt (of als je internetverbinding of zelfs de electriciteit uitvalt), dan moet het mogelijk zijn om de laatste staat van een pagina bij een volgende login automatisch te herconstrueren op basis van de bewaarde data (invoervelden/checkboxes/radiobuttons).
Dat kan uiteraard enkel als JavaScript ingeschakeld of beschikbaar is, waardoor aan dit WCAG ijkpunt wellicht niet strikt voldaan kan worden.
5 Christophe Strobbe // 27 maart 2006 om 11:14 am
@Roel: WCAG 2.0 eist niet dat pagina’s werken zonder JavaScript; in plaats daarvan heeft de WCAG Working Group het concept “baseline” bedacht, d.w.z. de set van technologie?n (markuptalen, scripttalen enz) waarvan de ontwikkelaar veronderstelt dat ze ondersteund worden door de browsers van de gebruikers. Deze baseline wordt vastgelegd door de wetgever, de opdrachtgever of een andere partij, afhankelijk van de situatie. In zekere zin is baseline niets nieuw: iedere ontwikkelaar hanteert sowieso al een baseline, maar WCAG 2.0 eist dat die expliciet is in conformance claims.
Conclusie: wie AJAX wil gebruiken op een WCAG 2.0-conforme website, moet dus een baseline hebben waar JavaScript, DOM en XMLHttpRequest in staan; indien die dingen niet in de baseline staan, moet de site ook werken zonder AJAX.
6 Sam // 27 maart 2006 om 5:31 pm
Ben mijn beurt te vroeg gegaan.
Hier lees ik al een antwoord.
7 Roel // 27 maart 2006 om 9:55 pm
Bedankt voor de verduidelijking, Christophe. Ik ben bekend met het concept ‘baseline’ uit WCAG 2, en het lijkt een interessant idee. Toch vrees ik dat het voor nogal wat verwarring kan gaan zorgen: het is immers niet omdat een browser JavaScript ondersteunt, dat een screenreader overweg kan met de veelzijdige dingen die je met JavaScript kan (onClicks en onMouseOvers triggeren lukt nog wel met Jaws, maar DOM-updates worden niet door alle screenreaders opgepikt). Kan je van een internetgebruiker verwachten dat hij eerst de baseline gaat bestuderen voor hij kan inschatten of een site toegankelijk is voor hem/haar?
8 Christophe Strobbe // 28 maart 2006 om 5:11 pm
@Roel: Zonder WCAG 2.0 kunnen gebruikers de baseline niet bestuderen (als ze dat al zouden willen) omdat ontwikkelaars of eigenaars van sites deze informatie achterhouden, terwijl ze, zoals ik eerder zei, altijd een soort baseline in hun achterhoofd hebben. Als een ontwikkelaar of opdrachtgever denkt of zegt: “Iedereen heeft Flash, dus dat kunnen we wel gebruiken; JavaScript 1.4 is nu ook vrijwel algemeen ondersteund”, dan heeft hij het over een baseline. Met WCAG 2.0 moet deze informatie expliciet gemaakt worden. Voor eindgebruikers is dat misschien niet zo nuttig (hoewel, als daar ooit een RDF-taal voor ontwikkeld wordt, kunnen browsers daar misschien wel iets mee doen), maar het is zeer belangrijk voor de ontwikkelaar of de eigenaar van de site.
Idealiter wordt een baseline door de wetgever vastgelegd; indien de wetgever zich beperkt tot overheidssites, dan zullen veel website-eigenars zelf een baseline kunnen vastleggen, net als nu al het geval is.