Intro to Public Transport Web Accessibility

PT is an area where web site accessibility seems to be of particular importance, bearing in mind that many serious users of this information will already be under way, using cellphones, palmtops, or other browsing platforms of possibly limited functionality, or maybe over expensive hotel telephone connections. What's more, public transport is used by disabled persons, who would not be able to drive by reason of their disability (low vision, for example): where we, the taxpayers, are subsidising public transport for social reasons it seems to me that we are entitled to insist, via legislation and/or codes of practice, that information about public transport be properly accessible to everyone who needs to use it. For perhaps the first time, the WWW makes it possible for one and the same source of information to be available to all kinds of browsing situation, if only it is applied properly.

Many PT web sites fall short of this ideal, and in many cases for reasons that would be easy to remedy, if their operators would just use the web as it was designed, rather than starting off on the wrong foot (PDF files meant for their paper timetables; more recently, even interactive Flash presentations, for Heaven's sake) and then only half-heartedly, if at all, trying to offer some kind of second-class accessibility to limited parts of their information.

Jointly with Iain W. Logan, around 1997/8 we developed some notes and accessibility examples in the hope of doing a little education in this area. (This work pre-dated the Web Accessibility Initiative at W3C, although there were certainly some excellent accessibility guides already available.)

Note added Nov. 2000: I'd like to emphasise that these pages were based on the materials which were to hand at that time, i.e HTML3.2. Nowadays we can do much better, in terms of using CSS to suggest an attractive presentation, with relatively little risk of it impairing accessibility in unusual browsing situations.

One reader sent the following in email (the emphasis is mine!) (note that the reader's remarks refer to the respective sites at the date of comment):

I see you have an interest in making public transit information accessible. You might want to browse the Delaware Valley Rail pages. DVARP does an excellent job of putting up usable train schedule information. I believe they started with Philadelphia and are somehow going to end up covering the entire country one of these days. I rely on the site for Maryland commuter rail info and DVARP's Amtrak pages are *much* better than the official Amtrak site.

Oh, and http://www.dot.gov/ now has *two* Lynx accessible versions - a "graphics" page that works well with Lynx and a "text" page that works well with Lynx. Eventually someone is going to have a vision and realize that he can collapse the two into one and clean up the [INLINE]s with ALT="". Oh well, as long as the substance works I'm not going to fuss about the fine points. ADA (Americans With Disabilities Act) compliance is definitely getting to be an issue for the US .gov websites and perhaps for .edu and .com sites.

(The DVARP site is now at http://www.dvarp.org/).

Well, I visited the DOT site and, apart from the fact that it triggered Lynx's "Bad HTML" alert, the graphical page was more accessible to Lynx than it was to my usual graphical browser, since I have text sized such that normal-sized text is comfortable to read (why would anyone not do that?) - but most of their text was displayed microscopically small due to the widespread use of FONT SIZE="-2".

I really can't resist hammering home the point made by my correspondent, that an initiative by a group of passengers themselves was actually producing a more useful web site than the organization that was supposedly offering them the service.

Peter Parker of Melbourne, Australia, also emailed me in Dec. 2000 with a similar tale: he had been so dissatisfied with the official public transport site there that he had decided to produce his own. The official site is visually OK when viewed in a conventional graphical-browser situation, but it fails to make constructive use of even the elementary techniques for accessibility to other browsing situations: instead, it starts off by arguing with the customer about their choice of browser, and demanding that they must use FRAMEs.

It compounds this by breaking down the information by mode and by operator, making it virtually impossible for anyone not already well familiar with the system to make use of it, e.g for planning the most effective journey from A to B. Or to put it another way, the official site was provider-oriented where it should have more usefully been customer-oriented.


|Up| |RagBag|About the author|