A few years ago I got a call from a salesman who suggested I visit their new company website, just launched that week. "What did I think?", he inquired.
I could not believe my eyes. What loaded on-screen before me was a mess. I could hardly see the text in the menus, let alone read it. I clicked on what I assumed was a link (it was) and arrived on another page. I strained to make sense of it. My eyes hurt. I told him that I had trouble navigating the site, that the colour contrast seemed a bit low. He said it looked fine to him.
I dug into the stylesheet behind the site, and the penny dropped. They'd used red text on a green background. Ugh.
More recently I followed a link on Twitter to an online visualisation that highlighted changes in a particular metric spread across certain categories (the guilty shall remain anonymous). It did not make any sense so I showed it to a colleague. She said that it looked fine, and that they'd used a scale from red through to green to show the primary data. Fail!
Those experiences are typical for me because I have red-green colour blindness. Both really annoyed me because I make websites for a living, or rather one website - www.radionz.co.nz - and I know that sort of thing is avoidable and unnecessary.
We (Radio New Zealand) care about and take great pride in the accessibility of www.radionz.co.nz. We acknowledge it's not perfect though, and we keep working at it while keeping up-to-date with latest research and techniques. One of our web team is a member of the working group for the NZ Government Web Standards. This is serious and important work.
But it wasn't always like that for me or, in fact, for most people building websites.
The early days of the web were highly experimental, born out of frustration for its text-centric focus and the vast gap between that and printed magazines. The first highly 'designed' sites used a range of work-arounds to achieve print-like layouts. These included converting text (usually headings) into graphics (so an exact font could be used), nested tables and blank spacer images, graphics split into dozens of pieces inside tables, and image maps.
It was possible to create some fairly spectacular looking pages with these techniques, but there were major problems. Sites were expensive to build and more expensive to maintain. Lots of strange code was required to support Netscape and Internet Explorer's different ways of rendering HTML. When a new web browser version came out, everything had to be tested, and reworked. Use of Cascading Style Sheets (CSS) to control the look and layout was minimal, again because of limited and inconsistent support by web browser software. Getting a site to look 'pixel perfect' (or even close) in every type browser was rocket science.
Worst of all, few sites were designed for ease of use by anyone other than those with fully-functioning upper limbs, 20/20 vision, and an IQ 'average' or above.
This all changed in 1998 when The Web Standards Project (WaSP) was formed. They, according to Wikipedia, "…campaigned for standards that reduced the cost and complexity of development while increasing the accessibility and long-term viability of any document published on the Web."
The standards themselves had been (and continue to be) defined by an international body called the World Wide Web Consortium (W3C) whose members included the major browser makers. The core standards had been ignored in favour of proprietary extensions that (ultimately) forced developers to support only one browser. Remember those site buttons, 'Best viewed in Browser X'?
The W3C standards allow the World Wide Web and a host of other applications to exist on the internet together, and for those applications to be available to everyone. The aim of these open standards is interoperability, and to lower the barrier to entry to enable participation at the lowest possible cost.
Anyway, I was convinced by WaSP's pitch, and like many others at the time I became a zealot for the Web Standards cause, this inevitably leading me down the path to the web accessibility initiative, WAI.
It seemed like good sense at the time and like most good followers of the cause I adhered to the published best practices espoused by The Prophets, wearing the results like a badge of honour. For years I followed the prescription of standards, but along the way something changed.
After the fourth iteration of the RNZ site was launched (in 2008) I realised that we'd been doing things differently. No longer did we simply follow the 'recipes' advocated by others; those practices had become a way of life and we were developing our own ways of doing things to suit our content. New content areas were being created, and we were thinking about accessibility issues without thinking about them. Theory had turned into practice and I thought we'd truly arrived; we finally had accessibility sorted.
But later that year I got some feedback that completely changed my view. Someone had attended a session on screen readers run by the Blind Foundation, and had blogged about one small problem with our site. I was mortified. A problem with OUR site?
The issue was that links in the features section of the home page did not make sense to screen readers. The links following each feature had the text "Find out more", a common pattern on many sites, and a screen reader navigating the page would hear a series of links read thus:
- link: Find out more
- link: Find out more
- link: Find out more
Not very helpful, so we added hidden text to each link:
- link: Find out more about Podcast Classics
- link: Find out more about Enzology
- link: Find out more about Nine To Noon
Technically, the extra text sits in a span with a CSS class that is hidden from the visual layout. After that, we made the use of additional descriptive hidden text standard practice on the site.There are also hidden headings to say what each section of the page is for: Main navigation list, Menu, secondary navigation, and so on. This was a simple change.
This incident was a wake-up call for me, and highlights the reality: your accessibility effort is never complete, and without constant work your site will become run-down and less accessible over time. Beyond simple HTML markup, the same is true for other accessibility issues such as colour contrast and labelling - run down, they will.
When we developed a new audio player for the site, I subscribed to the Assistive Technology Interest Group run by the Blind Foundation. I did this to enlist the help of the community who'd potentially have the most issues with a popup player, and for whom it is probably most important to get it right. One of the benefits of talking with real people directly (instead of commissioning a report) is that a conversation can develop. The player was fine-tuned through several iterations based on detailed and specific feedback. Compared with the usual build it, test it, fix it approach, I think the process resulted in a better outcome for everyone.
I was amazed by the helpfulness of people on the list and their willingness to explain things that were obvious to them, but not to me. I also benefited from reading conversations about other access issues. While on the list I discovered that the technology and community is changing all the time - for example, the Accessible Rich Internet Applications (ARIA) specification is moving on at a great pace but not all people use the same screen reader software or even the same version of a screen reader.
The desire to keep improving also drove the design of our custom Content Management System (CMS). This is the sortware that controls the layout of the site, and that generates the HTML underlying every page. It has built-in features to allow us to tightly control the generated HTML while still allowing for frequent updates by many people. This effort was recognised with an ONYA award in 2010.
From a development point of view, there is not one box into which you can put 'people who are unable to see', or 'people who cannot use a mouse', and then derive a general approach to serve that group. You must understand the whole community and how they interact with your site and your content. It is ture that you cannot serve absolutely everyone; you have to make choices. But don't do it based on generalised assumptions.
My experience raised some interesting questions. Why is it that many web projects to do not talk directly to their end users, and especially to those whose experience of the world differs markedly from their own? Or if they do, it is via a third party?
I was born in the 60s and like most children of my generation when we asked question about someone who looked different to us, we were scolded by our parents. I have a vague recollection of looking for a moment too long at someone using a wheelchair and being told not to stare. For my generation disability seemed to be a thing that you hid away and did not discuss. I once shared these thoughts during a presentation, and there were a lot of heads nodding in agreement.
Today, disabled people are not hidden away, nor do they feel the need to hide. They attend the same schools as everyone else. They have the same opportunities. 'They' are now 'us'.
I suspect that many people don't engage with the disabled because we are embarrassed, afraid of feeling stupid, of saying the 'wrong thing', or have no idea where to start. It has been my experience that most people are willing to share their experience and give you feedback - you just have to ask and be prepared to listen and learn.
The important message is this: web accessibility is not a box to tick. It is not simply an event or a process to follow, even though those are important. It is a conversation, a partnership - one that has to involve those for whom your site exists to serve.
My challenge to you this week is to rethink your approach to web accessibility.
Richard Hulse is the New Media Manager and Webmaster at Radio New Zealand. He blogs at http://richardhulse.blogspot.co.nz/ and tweets @richardhulse.