Data Tramp

I was walking home after a snowstorm last year and noticed a man in a wheelchair ahead of me. His wheelchair was of a higher quality than most I see rolling around – looking more like it was made in a high-end bicycle shop than a hospital ward. He crossed the street and began to struggle at the other curb. The wheelchair ramp had been swept clean and accessible, but a large chunk of ice sat in the street blocking the way.

As I went to help something hit me. People had gone out of their way to clear the curb by the ramp. These people had the best of intentions to make the sidewalk accessible - but they stopped short of actual Accessibility.

Defining the problem

I like the Irish National Disability Authority’s definition of web accessibility:

“The goal of web accessibility is to ensure that information or services delivered through websites are available to and usable by the widest possible audience. This requires that all users can:

• Perceive and understand the information provided
• Perceive, understand and operate the website navigation
• Perceive, understand and operate the controls and inputs

To achieve this, the design must take into account the fact that the ability to see, hear, make inputs, read text or process information varies from user to user, across time and across situations of use.”

There is a lot of talk about accessibility on the Internet, but very few people actually pay this kind of attention to how users view their material. The key phrase above is that ability “varies from user to user.” Designers are often paid to present a single optimal aesthetic solution without considering the sub-optimal reality of how their implemented designs may “look” to some users.

I could go into the myriad of impairments that would prevent people from being able to utilize a website site – but there are already great articles on the subject out there (including articles on disabilities which often go overlooked… such as cognitive impairment). I don’t think the problem lies in the general population knowing that limited users have problems using the internet. I think the problem is that the general population doesn’t know why they should care.

Now I should point out that I don’t blame developers or customers who want to ditch accessibility for “higher-end technologies” and more intricate interfaces (although I maintain that ALL interfaces can be made accessible at some cost). It’s a matter of target audiences. Most people I talk to on the topic wonder why they should spend time targeting a small percentage of their potential audience. Why is the cost worth the benefit?

Ah… but the thing to keep in mind here is that there is a whole class of lawyer out there who’s express intent is getting rich off of other people’s “oversight” and “prejudice.” Business practices that overlook or discriminate against minority groups generally result in multimillion-dollar legal fallouts.

Swimming against the tide

Businesses can fight the idea of paying for accessible websites and web applications for now. They can fight the same way community pools fight daily against lawsuits when kids hop fences and drown. They can fight the same way the PGA fought allowing handicapped golfers to use golf carts on the tour. They can fight the way banks fought Braille keypads on ATMs (I still want to know how blind people find the earphone jack on those things).

And fight businesses have so far. The internet community has seen big test cases come out against airlines (like South West), banks (Such as Bank of America), and retailers (such as Target). Thus far companies have been winning these test cases - but with private companies handling more critical government-style services such as voting and healthcare these days, the line between commercial protection from Section 508 and the legal loopholes around the ADA is rapidly fading. The plain fact is that eventually the law will shift to protect the disabled; it’s just a matter of time and a matter of who gets sued or fined first to force the issue.

All of this said - I don’t think we really need the threats. I think most people, on some level, realize that providing their content to the widest possible audience is a good thing. The more pressing question is how do we achieve accessibility in an affordable way? In other words, how can we squeeze as much benefit as possible out of the cost?

My suggestions

The following are my suggestions to developing accessible websites - along with potential side benefits to doing the work.

Develop your content

As it turns out, the same writing skills used to assist people with Cognitive Disabilities will also assist everday “fully enabled” users as well. Keep things short and simple. Use subheadings to separate content and give context. Use bullet points and graphics to break up content in a sea of text. Use <dfn>, <acronym> and <abbr> to define terms, acronyms and abbreviations. Write in a reverse pyramid format - presenting the most critical information up front and drilling into details. Oddly enough… these are all things I learned to use in news writing classes at journalism school. Poor writing skills will never win points with an audience - spend time on the task of creating content or hire someone to do it instead.

Develop with Web Standards

Most assistance tools for the internet are machine based. The problem is that machines are HORRIBLE at understanding context. Proper, semantic markup for content is a must for accessibility where users need to use screen readers or special browsers to surf the web. The side benefit here (actually maybe the main benefit) is a Search Engine Tuning boost. It also makes the website more scalable as well. This is far from a bandwagon, folks - if a developer is using inline styles for anything - fire them immediately and find someone who knows what they are doing.

Develop first without styles

I am sure everyone has a very pretty aesthetic design for their website. However pretty designs do nothing for the visually impaired - or for search engine crawlers, for that matter. Before beginning the development of CSS have the developer take a look at the content on screen without styles. What order does it appear in? Is the content ordered in a logical way? Often we developers build HTML pages left to right and top to bottom because it’s easier - the way my site is built here, actually. However long navigation lists or auxiliary information appearing before the content in our documents will Negatively affect SEO on dynamic sites with constantly changing content. Ensuring main content shows up first will also assist restricted users who visit the site with screen readers. Content up top means less to listen to and wade through to get to content

Remove extraneous images from markup

One misconception is that Accessibility means that the impaired user should be exposed to all the same content and actions as any other user of the site. This is simply not the case. A picture of a girl dancing through flowers on a financial website makes sense to a user who can see the image and comprehend the implied branding and stylistic sense. A blind user will normally hear their screen reader say - in a monotone voice - “Girl dancing through flowers.” This does not help site branding or stylistic sense - much less than help the user obtain what they were looking for - namely the content. Instead, only include images in markup which contain some sort of content or meaning - and include rich ALT attribute descriptions which actually describe necessary meaning and context to the user.This one warrants an example. A developer is working on an art history website and providing a page on a topic - say paintings with a distinctive feature. She decides to give a few image examples - so obviously, as key content, these would be included in <img> elements. However, leaving alt attributes which say something like “La Gioconda by Leonardo Da Vinci” will not necessarily make the image more accessible. Say something helpful to give context… such as “La Gioconda, otherwise known as the Mona Lisa by Leonardo Da Vinci, features a young woman whose gaze meets with the viewers, mouth curled in an almost expressionless smile.” Now, if there is an image which is not part of the content of the site - say border images or bullets, use CSS to include them. This technique, again, will assist with search engine optimization and make the website more scalable. The major side benefit, however, may come from how the site is viewed from mobile devices - which typically have troubles viewing inline images.

Use page titles and page descriptions

Users without the ability to visually identify which section of a website they are in - or even which website they visited - are more susceptible to getting lost. Since one of the basic precepts of design is context, I don’t think I need to explain why this is a bad thing. Hence, the first thing in a webpage body should be a very short context helper. A page title, page description and maybe breadcrumbs can go a long way to helping a handicapped user figure out where they are and what they can do there. These titles and descriptions can be hidden with CSS.

Action Keys and internal navigation

Setting up internal navigation on pages is important. While there isn’t much in the way of an auxiliary benefit out of it (aside from extra hooks for CSS maybe…) it gives important navigational features to limited users - especially on sites which do not use header tags often. Set up anchor elements with name attributes (<a name=”space”>) at each major section of the site so it can be linked directly. Then include a navigation menu to these sections. This includes primary and sub navigation, content sections, etc.While internal navigation may be difficult to provide on dynamic sites, access keys should be simple to implement. Features of a site which exist throughout - such as a contact page or a search feature - should be assigned an access key. It is also helpful to create an accessibility statement page which gives an index as to which access keys are being used and then assign that page an access key of ‘0′ on every page… such as Jeremy Keith did over at Adactio. I recommend following the UK government standard for deciding what keys to assign where.

Offer an audio version of key content

I don’t think the average person needs a marketing expert to tell them that a trained broadcaster reading content will be more pleasant sounding than a computerized screen reader – especially on sites with hard to pronounce locations, industry terms or acronyms. Recording an audio alternative to text content on the site will also ensure proper pronunciation of complicated words. Link it at the top or as an item in internal navigation - or offer it as a hidden link at the top of each section of content. All love for Freedom Scientific, but if I were a corporation I wouldn’t want to trust how my marketing sounds to JAWS. Might as well have a speak and spell read beer commercials. For the uninitiated, listen to JAWS read punctuation.

Spell it out

One of the things I lament about the trend towards dynamic based Content Management System websites is that, while our content is easier to publish, it is also generally harder to describe. We live in a culture of Acronyms, abbreviations and industry terminology – much of which may not be readily understood by segments of the audience. This situation becomes more complicated when an audience is trying to get at information through a screen reader. Read a Rachel Ray recipe on food network’s website and imagine trying to figure out “While you’re searing that steak, add a Tbsp of EVOO to the rue we just made - it’ll be de-lish!” (wait… in all seriousness… I doubt Rachel would ever add olive oil to a rue.)If acronyms must be used, couple them with a well thought out Aural Style Sheet. These can explain to a screen reader when to spell out “E-V-O-O” or say “Extra-Virgin Olive Oil” instead of the incomprehensible “ee-vooh”. Aural style sheets can also affect how fast difficult terminology is read.

In conclusion

I threw out a lot of ideas here… but the avid reader will notice I didn’t even touch design considerations such as high contrast color pallets (…looking for a good color-safe palette? hop over to Bob Stein’s site), large controls and text size. Go read a design blog to learn those… or maybe leave some ideas in comments below. The take away here is to keep limited users in mind when building sites - and test the results of the work being done to make sure the users are being served. The best of intentions didn’t help that guy in the wheelchair get to the cleared handicap ramp… me and three other people did.

If you liked this entry, please consider linking it: