Before even looking at the application my first response is a simple one – provide an accessible alternative. That is give the user a phone number or address where they can receive appropriate assistance or better still, think about what the application’s main function is, can any of it be delivered in a static form? With a bit of work the answer is usually yes.

It’s impossible to make GIS data fully accessible. These applications are inherently visual and cannot be understood or even made usable to screen readers but that doesn’t mean to say the WCAG should go out the window.

Commonly the problems I see with new GIS based applications are:

• Invalid markup, likely to result in unpredictable behaviour in various browsers and therefore the dreaded “Best viewed with Internet Explorer…” message.
• Form labels not associated with inputs. I have no motor impairments yet find it frustrating when a lazy developer expects me to click on a tiny input box as opposed to the large label beside it.
• Fixed fonts. IE6 still has a large share of the browser market so we must cater for these users by using ems/keywords/percentages in font sizing.
• Reliance on colour alone. Colour is used to define regions or features on a map. If shades of one colour are used several times, unless you aren’t colour blind and have a top of the range monitor you won’t see the difference.

These issues are only covered by the WCAG but I’m a firm believer that accessibility should go further than the WCAG and common sense should prevail.

Non-WCAG issues I come across include:

• Poor error recovery. Not directly covered by any WCAG 1.0 checkpoint this is something developers constantly overlook. Users click on a form submit, perhaps not choosing options and nothing happens. At least thats how it appears unless you they notice the error message at the bottom of the page in that nice off white colour.
• Unintuitive GUIs. The developers know how to navigate the GIS, the clients do but does anyone else? That’s usually the first thing I spot, being removed from these projects, as I spend my first 20 minutes figuring out what I’m supposed to do.
• Non-standard forms. Every form on the web has it’s submit button to the side or at the end, right? Unfortunately not. Placing a submit button at the top of list of checkboxes is just dumb and goes completely against normal practice. You wouldn’t ask someone to complete a form then ask them to sign and date the top of it would you?

I could go on but would prefer to look at what can be done to improve GIS data. It appears that many of these systems are built on top of legacy applicatons and accessibility and usability is bolted on at the end. Like any well planned website project, accessibility and usability must be considered from the outset. I would like to challenge these application developers to start thinking outside of the box. For example, why must the system dictate what colour county borders are? Why can’t I as a user customise that feature and select my own colours. In fact why do I need to use the system in the first place? Why can’t I complete a simple form with my postcode, check the info I’m interested in and receive a nice colour map with supporting documentation?

Perhaps therein lies the answer (to some situations) in that the map is something a user turns on should they want it there and then but that the user can still get their answers without it. With Google leading the way in GIS and their intuitive GUI, it’ll be interesting to see what comes next.