Can You Really Have an Accessible Google Map?

Well, yes – according to Greg Kraus of LecShare Inc, in a presentation entitled “Creating Accessible Google Maps“, part of EASI’s (Equal Access to Software and Information) webinar series.  Kraus has developed some JavaScript code that calls the Google Maps API (Application Programming Interface), which he has generously made freely available to the accessiblity community.

This allows a Google map to be accessible in two ways:

1. Navigation - By creating form buttons and tying some JavaScript commands to them a Google map’s navigation can be made keyboard (and screen reader) accessible.  It allows the user to Zoom In/Out, have Normal/Satellite/Hybrid views and pan North, South, East and West.  Details on how to accomplish this are available from Making Google Maps Accessible (Part 1 – Controls).  (However, the actual maps themselves will not be screen reader accessible – only the controls).

2. Providing Accessible Data – Data, such as name, website, weather, etc, can be entered into an accessible form, which is stored in a database.  The data is then retrieved from the database via the scripting mechanism described in Making Google Maps Accessible (Part 2 – Accessible Data), and displayed both on the map on custom made pushpins and as an ordered list, which is accessible to screen readers.  Because the pushpins can be custom made, the font associated with the pushpins can also be made larger.

Although Google Maps only understand latitude and longitude co-ordinates, rather than actual addresses, Google does provide a publicly available API which will do the translation for you.  However, it should be noted that any information that shows terrain or streets will be inaccessible to screen reader users.  Nevertheless, descriptions could be added to the pushpins to describe their relationship with other features.

It was quite exciting to see attempts to make something as inaccessible as a map accessible and it’s great to see that Greg Klaus has made his work freely available to us all.

A Systems Approach Model to Web Accessibility

Paul Bohman, one of the original founders of WebAIM (Web Accessibility In Mind) gave a webinar on “Systems-Approach Models of Web Accessibility: Because Techniques Are Not Enough” last week.

As well as mentioning the usual “dos and don’ts” for web accessibility, he talked about how accessibility should be part of an organisation’s culture, in the same way that recycling is often seen as part of an organisation’s ethical commitment.  Most organisations in the UK (United Kingdom) have recycling strategies and policies (although there may be some legal encouragement here) and encourage staff to actively play their part.  In the same way, accessibility should be actively encouraged – from purchasing accessible equipment and software right through to ensuring that disabled people are actively encouraged to apply for jobs within the organisation.

Bohman stated that the web and e-learning now provides an historic opportunity for disabled people to access information independently for the first time ever.  Yet, if web resources are designed to be unfriendly or inaccessible, then this opportunity is wasted.

Web accessibility is not just about making sure that web developers and content creators follow the W3C WAI (World Wide Web Consortium Web Accessibility Initiative) specifications and guidelines. It also needs to involve people and services outside of an organisation’s actual main web site.  Of course, there may be additional costs but much of these costs can reduced by ensuring that accessibility is considered from the very beginning.  Particular parts of an organisation’s system mentioned by Bohman include:

* Web Services – Ensuring that any web services accessed as part of the web site or e-learning system are accessible.

* Intranet – An organisation’s public web site may be accessible but its private intranet also needs to be accessible to both employees and students alike.  For example, if the intranet portal links through to a person’s payroll or financial details, these need to be accessible. It is easier and cheaper to include accessibility right from the start.

* Libraries - Although a library may not have any influence over which journals are available electronically, details should be kept up-to-date on the library’s (accessible!) database.

* Learning Management Systems – Although VLE (Virtual Learning Environment) developers, such as BlackBoard, have made significant efforts to make the student side accessible, work is still required to ensure that the tutor side is also as accessible.  Most tutors are expected to create electronic resources for their students but generally they are not specialists in accessibility.  Prompts should be available which encourage accessible authoring of resources.

Future Proofing – Are students on computer or teaching courses actually taught how to make systems and content accessible?

* Purchasing – In the US (United States), Section 508 requires that the most accessible product of its type is purchased by federal organisations.  Most purchasing departments therefore are well aware of the VPAT (Voluntary Product Accessibility Template), which explains where a product is and is not accessible.  If the question of accessibility is not raised when purchasing a product, then the likelihood of it actually being accessible will be fairly slim.  Therefore, someone using assistive technologies, such as a screen reader, will only be able to work or learn in that organisation for as long as the actual systems and products used by that organisation are accessible.

* Recruitment – Although it is fairly easy and cheap to include a requirement for accessibility knowledge in a job advertisement or job description, actually testing a potential candidate’s knowledge can be take time.

* Training – It is not acceptable for an organisation to state that they have an interest in accessibility, it needs to be supported by relevant training at a relevant level across departments.  For example, the accessibility training received by a web developer will be different to that received by a purchaser.  Although there may be substantial upfront costs, it should be on-going and take whatever form is necessary.

In order for every part of the system to be effectively involved in accessibility, it is imperative that an organisation’s leadership is committed to it and that adequate budgets are provided. 

Bohman ended the webinar by stating that implementing accessibility benefits everyone because everyone has the potential to require accessible systems at some point.

It was interesting to hear accessibility likened to the recyling strategies and policies that many organisations have adopted.  These seem to be quite successful so perhaps a similar approach could be taken for ensuring that accessibility is seen as part of an organisation’s ethos.

One comment made by one of the moderators during the presentation, which I found quite interesting, was that the use of wireless devices may actually do more for accessibility than accessibility advocates have managed to achieve.  Perhaps it doesn’t matter how or why accessibility is achieved, as long as it is achieved!

NIIMLE Presentation – Accessible and Engaging?

I’ve just seen the presentation from NIIMLE (Northern Ireland Integrated Managed Learning Environment), which describes how what it does and how it can benefit students.

The great thing about the actual presentation is that it has tried to be both engaging and accessible. There are short paragraphs of text in the presentation, which are also spoken out loud, whilst information itself is presented very clearly and is supported by an engaging animation and colour scheme.

The NIIMLE portal also seems to have some form of personalisation and the NIIMLE development team have also attempted to incorporate the WAI (Web Accessibility Initiative) guidelines.

So full marks to the NIIMLE Team for an accessible and engaging presentation.