Een interactieve kaart toevoegen aan een webpagina is via meestal goed gedocumenteerde JavaScript API's inmiddels vrij eenvoudig geworden. Er is een ruim aanbod aan kaartleveranciers die meestal gratis hun materiaal ter beschikking stellen. Alles lijkt aanwezig om met wat regels JavaScript een kaart aan een pagina toe te voegen. Maar hoe zorg je er vervolgens voor dat zo'n kaart op een site ook voldoet aan de webrichtlijnen?

Problemen

Een van de belangrijkste problemen met de interactieve kaarten is dat ze afhankelijk zijn van Javascript. In de webrichtlijnen wordt Javascript betiteld als een optionele technologie. De kaarten gebruiken JavaScript om slepen, zoomen en pannen mogelijk te maken. Zonder JavaScript werken deze kaarten meestal niet eens. In dat geval zal er dus een alternatieve weergave moeten worden getoond.

Doordat de kaart in- en uitgezoomd kan worden kan de kaart oneindig veel informatie bevatten. Deze grote hoeveelheid informatie wordt weergegeven in afbeeldingen. Volgens de webrichtlijnen zou je die afbeeldingen moeten voorzien van "een effectieve alternatieve tekst" via het alt-attribuut (Richtlijn R-pd.7.1). Maar een kaart bevat zo veel informatie dat dat bijna ondoenlijk is om een goede en nuttige alt-tekst hiervoor te schrijven. Maar net zoals een technologie optioneel kan zijn is het belangrijk om te weten dat sommige informatie ook optioneel kan zijn.

Verder lijken de meeste kaartleveranciers ervan uit te gaan dat de gebruiker beschikt over een muis. En in de gevallen dat er rekening is gehouden met het toetsenbord als invoerapparaat ontbreekt het weer aan standaardafspraken over welke toetscombinaties gebruikt moeten worden en kan er bijvoorbeeld geen gebruik worden gemaakt van de tab-toets om door de lijst met klikbare elementen te navigeren.

Oplossingen

Ga uit van de data

Meestal zal de kaart niet het uitgangspunt zijn van wat er op de kaart weergegeven moet worden. In de meeste gevallen wordt de kaart niet primair gebruikt voor navigatiedoeleinden. Bovendien is de kaart meestal niet meer dan een achtergrond waarop de daadwerkelijke gegevens gepresenteerd worden.

Om op een toegankelijke manier met kaartweergaves te werken op een site moet je uitgaan van de basis: de gegevens die je op de kaart wilt presenteren. De kaart is niet het doel op zich. Dat is de informatie die je via de kaart wilt overbrengen. Het biedt een context voor de gegevens die je wilt presenteren.

Vaak zal het gaan om specifieke locaties, een route, of een gebied op de kaart waarover je meer informatie wilt geven. Dergelijke gegevens kunnen prima beschrijvend in een HTML-tabel of -lijst worden weergegeven op een webpagina. Als je de pagina zo bouwt dat deze gegevens al standaard in de HTML aanwezig zijn heb je de meest toegankelijke vorm al gewaarborgd. Deze gegevens zijn dan namelijk ook zichtbaar als JavaScript uit staat.

Voorbeelden

Maar welke gegevens vormen dan de basis waarop de kaart is gebaseerd? Vaak is het voldoende om je af te vragen hoe je de informatie op de kaart aan iemand via de telefoon door zou kunnen geven. Wat zou je vertellen? Je zult alleen de geografische punten die van belang zijn noemen en geen uitgebreide opsomming geven van alle geografische informatie op de kaart die niet van belang is maar nu eenmaal wel op een kaart aanwezig is. Aan de hand van een aantal voorbeelden wordt dit misschien wat duidelijker.

Risicokaart.nl

Op de Risicokaart worden allerlei risico's in Nederland getoond zodat o.a. burgers kunnen zien welke risico's er in de directe omgeving spelen. Dit is een voorbeeld van punten die op de kaart worden getoond.

De risicokaart is eigenlijk een grote databank met gegevens waarbij ervoor is gekozen om deze via een kaart te ontsluiten. Een bezoeker kan op de kaart zien welke risico's er in de directe omgeving zijn. Zonder kaart is het natuurlijk prima mogelijk om op basis van een postcode of adres dergelijke informatie in een tabel of lijst te tonen. Op de huidige site is kaart helaas de enige manier om de gegevens te raadplegen.

Fileinformatie

De ANWB heeft een aantal regiokaarten waarop de files op de snelwegen worden getoond. Dit is een voorbeeld van een lijn die op de kaart wordt getoond.

Op de filekaarten worden de plaatsen en de intensiteit van files getoond op snelwegen. De locaties en lengtes van files zijn prima in tekst te omschrijven. Teksten zoals:

A27 - 3 km - Gorinchem richting Utrecht tussen Noordeloos en Lexmond

bieden eigenlijk alle informatie die ook op de kaart wordt weergegeven. Dergelijke berichten kennen we ook van de radio. Als het lastig is om vast te stellen wat de eigenlijke informatie is die overgebracht moet worden dan kan het dus handig zijn om te bedenken hoe je de informatie op de kaart via de radio of telefoon zou communiceren. Dat is de informatie die je in de pagina als tekst ook moet verwerken.

KNMI Neerslagradar

Op de neerslagradar van het KNMI wordt de buienontwikkeling boven Nederland getoond. Eigenlijk betreft het hier in tegenstelling tot de voorgaande kaarten een animatie die bepaalde gebieden weergeeft.

De neerslagradar toont de buien boven Nederland in een geanimeerd kaartje. Naar mate de tijd verstrijkt schuiven de buien over het land heen. Eigenlijk is dit een gedetailleerdere weergave van weersverwachtingen zoals we die al langer kennen in de vorm van:

"In het zuidoosten eerst nog af en toe motregen, van het westen uit zonnig. In de zuidoostelijke helft van het land is het nog zwaar bewolkt en in het zuidoosten valt eerst nog af en toe wat motregen. In het westen is het inmiddels zonnig geworden. De bewolking trekt vanmiddag en vanavond naar het oosten weg."

In de meeste gevallen zal het bovenstaande voldoende zijn. Mocht je de detaillering toch over willen brengen, dan zou je nog kunnen overwegen om bijvoorbeeld op basis van een zoekopdracht naar een postcode of adres een tijdslijn te tonen waarop wordt aangegeven op welke tijdstippen er buien wordt verwacht op die plek.

Opzet kaartpagina

De gegevens die via JavaScript worden getoond op de kaart kunnen dus prima in de vorm van een tabel of lijst in de pagina worden opgenomen.

Om de pagina waarmee de kaart wordt getoond niet te zwaar te maken is het aan te raden om bij kaarten waarin veel gegevens worden getoond de gegevens over meerdere pagina's te verdelen. Dit kun je doen door gebruik te maken van paginering.

Als je verder op de kaart de mogelijkheid biedt om selecties te maken dan moet je op de pagina van de kaart zelf ook al de mogelijkheid bieden om de lijstweergave ook al te filteren op bijvoorbeeld categorieën.

Interactie met de gegevens

Afhankelijk van de hoeveelheid gepresenteerde gegevens kun je hulpmiddelen toevoegen die het raadplegen van de gegevens mogelijk maken. Net zoals een kaart ook een middel is om de gebruiker te helpen bij het raadplegen van de gegevens, moet je vervangende hulpmiddelen aanbieden als de kaart niet kan worden getoond.

Een veel toegepaste interactie die wordt toegevoegd aan een dergelijke kaart is het filteren van de gegevens op de kaart. Door selecties te maken kunnen markers op de kaart worden verborgen of juist zichtbaar gemaakt. Dergelijke selecties zijn natuurlijk prima in HTML te bouwen.

Als de HTML wordt voorzien van de gegevens in een lijst- of tabelvorm, dan kan de kaart er via JavaScript aan toe worden gevoegd en kunnen de filterlinkjes worden voorzien van alternatieve events die de kaart in plaats van de lijst met gegevens beïnvloeden.

Geografische context

Als alternatief voor de geografische context die een kaart biedt kun je overwegen om extra selectiemogelijkheden te bieden, zoals inperken op plaatsnaam of postcode. Of je zou de lijstweergave kunnen voorzien van extra sorteermogelijkheden op basis van bijvoorbeeld provincie. De mogelijkheden hangen natuurlijk af van de gegevens die je tot je beschikking hebt.

Als je de gegevens en selectiecriteria in de HTML aanbiedt, heeft dat als voordeel dat de kaartpagina ook vindbaar wordt op die gegevens door zoekmachines. Als je alleen een linkje naar de data plaatst op de kaartpagina heb je dat voordeel niet.

Wisselen tussen lijstweergave en kaartweergave

Omdat sommige bezoekers misschien ook meer baat hebben bij een lijstweergave dan een kaartweergave is het handig om beide opties altijd aan te bieden. Knippen en plakken van adresgegevens vanuit een lijst is bijvoorbeeld een stuk eenvoudiger dan dat je iedere marker moet openen om gegevens te kopiëren. Dring daarom bezoekers met een browser die JavaScript ondersteunt niet automatische alleen een kaartweergave op.

Te vaak wordt er nog uitgegaan van bezoekers die de informatie op een site alleen maar lezen. Zeker bij grote hoeveelheden informatie zal men juist de gegevens ook op andere manieren willen (her)gebruiken dan oorspronkelijk door de makers is bedacht. Denk aan projecten zoals data.gov of data.gov.uk die publieke informatie ontsluiten voor hergebruik. Door de gegevens in een gestructureerd open formaat aan te bieden faciliteer je hergebruik al.

Bijkomend voordeel van de data in de pagina opnemen is dat de kaartpagina ook voor zoekmachines vindbaar wordt. Een zoekmachine indexeert de data in de tabel- of lijstweergave waar vervolgens op gezocht kan worden. Deze mate van vindbaarheid laat zich met een JavaScript-oplossing minder makkelijk realiseren.

Kaart

Tot nu toe hebben we het voornamelijk gehad over de data die uiteindelijk op de kaart gepresenteerd wordt, en nog niet hoe deze gegevens nu op een kaart kunnen worden getoond. Er zijn verschillende manieren beschikbaar om te werken met kaarten, waarvan de Google Maps-achtige varianten de meeste flexibliliteit bieden. Omdat dergelijke dynamische kaarten soms te uitgebreid zijn voor het doel dat je probeert te realiseren kun je ook nog statische of semi-statische server-side kaarten overwegen. Deze licht ik hieronder kort toe.

Statische kaart

Een kaart kan als eenvoudige afbeelding worden toegevoegd. Aanpassingen aan de kaart moet je in dat geval echter ook altijd in de afbeelding doorvoeren. Als er veel in de gegevens wordt gemuteerd kan dit al vrij snel een kostbare aangelegenheid worden. Eigenlijk wil je in zo'n geval dat een wijziging in een database meteen de kaart aanpast, server- danwel client-side.

Semi-statische server-side kaarten

Kaarten worden server-side gerenderd en worden als 1 afbeelding verstuurd. Er zijn ook allerlei server-side oplossingen, maar ik beperk me in dit artikel tot webdiensten die gratis ter beschikking worden gesteld.

Met de Google Static Maps API kun je dynamisch statische plaatjes laten genereren die je in de pagina kunt tonen. Markers kunnen via argumenten in de url worden meegegeven.

http://maps.google.com/maps/api/staticmap?center=De%20Dam,%20Amsterdam&zoom=14&size=240x240&maptype=roadmap&markers=color:red|color:red|label:P|52.3730708888889,4.89134073055556&sensor=false

Omdat sommige browsers een beperking hebben voor wat betreft de lengte van url's is het aantal markers dat je weer kunt geven op de kaart beperkt. Internet Explorer kan bijvoorbeeld overweg met url's van maximaal 2048 karakters. Hierdoor valt deze oplossing voor grote hoeveelheden markers eigenlijk af.

Daarnaast kunnen op het moment van schrijven met de Static Maps API slechts 1.000 unieke afbeeldingen per dag worden gegenereerd. Dit soort beperkingen is overigens iets waarbij je ook bij de andere hier besproken oplossingen rekening moet houden. Het is altijd raadzaam om van te voren uit te zoeken wat de gebruiksvoorwaarden zijn voordat je besluit een oplossing te kiezen. Zeker als het om een site gaat die druk bezocht wordt.

Dynamische kaarten

Het voordeel van bijvoorbeeld Google Maps is dat er al veel standaardfunctionaliteit via de JavaScript API wordt aangeboden waardoor je een basiskaart hebt waar je in lagen de informatie kunt presenteren. Daarbij moet je wel eerst een keuze maken voor een bepaalde kaartleverancier. Iedere kaartleverancier heeft namelijk zijn eigen API met specifieke mogelijkheden. Code voor de ene kaartleverancier werkt doorgaans niet met de API van een andere.

Mapstraction is een standaard API voor allerlei verschillende kaartleveranciers. Het biedt de mogelijkheid om één keer code te schrijven en door het aanpassen van een configuratieinstelling over te stappen op een andere kaarteleverancier. Functioneel is de API de grootste algemene deler en worden alleen functionaliteiten ondersteund die door alle leveranciers worden aangeboden. Het is dus verstandig om je goed te oriënteren over de mogelijkheden die de Mapstraction API biedt t.o.v. de API van de kaartleverancier waar meestal veel meer mee mogelijk is.

Toegankelijkheid

Browserondersteuning voor toetsenbordnavigatie

Google Maps-achtige kaarten hebben een "eigen" interface. Daarom moet je extra rekening houden met het waarborgen van de toegankelijkheid.

9.2.1
Alle elementen die hun eigen interface hebben, kunnen op een apparaatonafhankelijke manier worden bestuurd.

Met apparaatonafhankelijk wordt hier invoerapparaat bedoeld. Kaartleveranciers houden slechts beperkt rekening met toetsenbordnavigatie. En waar er al rekening wordt gehouden met het gebruik van het toetsenbord bestaan er geen algemene toetscombinaties waarmee de bezoeker kan navigeren.

Opera, de browser, biedt de mogelijkheid om met speciale toetscombinaties visueel tussen onclick elementen te navigeren. Eigenlijk zou je willen dat alle browsers dit standaard aan boord hadden. Met de pijltjestoetsen navigeer je naar alle elementen met een onclick-event zoals ze op de pagina worden weergegeven. Dus niet in de volgorde van de HTML, maar zoals de elementen op de pagina worden weergegeven met CSS.

Standaard toetsenbordnavigatie

Toetsenbordnavigatie wordt door de kaartleveranciers op verschillende manieren opgelost. Google Maps heeft een mogelijkheid om keyboardnavigatie te gebruiken. Het nadeel is dat er geen standaard afspraken voor de toetscombinaties voor pannen, zoomen, etc. zijn. Hierbij moet je dus wel met een legenda werken om duidelijk te maken welke toetsen gebruikt kunnen worden. Tabnavigatie zorgt er voor dat er ook een voorspelbare manier is om met de verschillende interacties in de kaart te kunnen werken.

Tabnavigatie toevoegen

De enige elementen die in HTML focus kunnen ontvangen via tab-navigatie zijn links, image map gebieden en formulierelementen. Het probleem met veel kaarten is dat de navigatieopties zoom en pan niet zijn opgebouwd met een van de elementen die focus kunnen ontvangen in HTML. Navigatieopties komen voor als <div>'s, <img>'s en in een enkel geval als <a>. In het laatste geval is het automatisch al mogelijk om de tab-toets te gebruiken in combinatie met een return om de knoppen te gebruiken. Als de kaartleverancier gebruik maakt van een <div> en een <img> dan moet er naar andere oplossingen worden gezocht.

In het artikel Keyboard Accessible Google Maps beschrijft Patrick Lauke een hack waarmee de bezoeker wel tabnavigatie kan gebruiken. Na het opbouwen van de kaart inclusief navigatie-elementen voegt hij via JavaScript aan de navigatieknoppen elementen toe die wél focus kunnen krijgen. Maar eigenlijk zou je willen dat de kaartleveranciers al standaard rekening zouden houden met het gebruik van elementen die focus kunnen krijgen voor dit soort knoppen.

Naast de navigatieknoppen zouden de markers op de kaart ook nog moeten worden voorzien van focus-elementen. Op die manier wordt het ook mogelijk om de pop-ups bij de markers te openen, zonder gebruik te hoeven maken van de muis.

Skip-links toevoegen

Mochten er veel markers op de kaart worden geplaatst is het ook raadzaam om een skip-link toe te voegen waarmee je over de lijst met markers naar de eventuele rest van de content kunt springen. Mocht je dan met de tab-toets door de pagina navigeren dan hoef je niet eerst alle markers langs als je bij content wilt komen die onderaan in de HTML staat.

Ten slotte

Het feit dat Google Maps gebaseerd is op JavaScript hoeft geen reden te zijn om de informatie die wordt weergegeven niet toegankelijk te maken. Het is heel goed mogelijk om op website met geografische kaarten te werken die aan de webrichtlijnen voldoen. Door de kaart vanaf het begin als een visualisatie van gegevens te beschouwen dwing je jezelf om uit te gaan van het basismateriaal. Op basis daarvan ga je dan gelaagd bouwen en voeg je functionaliteiten toe met gebruik van de technieken die door de browser worden ondersteund.

• Home
• Artikelen
• Colofon