Posted on by & filed under Accessibility, Basics.

Quick Win

Create a site/web application with very simple and logical structure (navigation and branding in the header on top, then meaningful heading, followed by the main content), dark gray text on a white or very light background. This way you will please all your users, disabled or not. Fill the alt attribute of the images with meaningful content. Try to navigate the site using a (free) screen reader like VoiceOver or ChromeVox, and adjust accordingly.

Disability on the web does not equal blindness

When a web designer thinks of accessibility most of the time he or she thinks of a blind person. This is the same oversight, which focuses most of the architectural accessibility thinking around the wheelchair. It is true, that on today’s web the most prohibiting disability is blindness, but we need to think of other disabilities, like people with motor disabilities (difficulty or inability to use the hands), hearing impairments, other forms of visual impairments (low vision, poor eyesight or various types of color blindness;) and not in the last place cognitive and intellectual disabilities.

WCAG

In the late 90’s the world realized, that a common effort is needed to improve the accessibility of the World Wide Web for people with disabilities. In 1997 the W3C (World Wide Web Consortium) created Web Accessibility Initiative (WAI) with the endorsement of the White House. Two years later this project published the Web Content Accessibility Guidelines or WCAG.

The latest stable technical standard WCAG 2.0 has 12 guidelines that are organized under the principles of perceivable, operable, understandable, and robust. For each guideline, there are testable success criteria, which you can pass at three levels: A, AA, and AAA. You can call a website fully accessible, if it meets WCAG 2.0 AAA in all criteria, but that often needs resources and budget way over the figures allocated for accessibility. In a later blogpost I will talk about WCAG 2.0 AAA requirements and fulfillment strategies in detail, but for now, let’s see what we can do on a tight accessibility budget.

Accessibility on (a very strict) budget

One of the most important thing for an accessible site is simple and logical structure. Well, this is the 2nd most important, the most important is don’t use Flash or Silverlight, but then again, I do hope, you are not considering those obsolete technologies. People with disabilities often rely on (special) keyboard instead of the mouse (usually the TAB button, or the arrow keys). In case of a person with visual impairments or limited motor skills it is vital, that she or he can navigate the site using key presses. This does not need additional coding from the creator of the site, because there are quite a lot of software products engineered to do that. Most screen readers can switch between the areas of interest using buttons.

When I started creating accessible versions of websites (in 2008, when HTML5 was only in first public working draft stage) I moved the navigation/header part of the site below the content in code. To achieve this a padding-top was given to the main content, equal to the height of the area before the content.
Content before header
After conducting usability tests (with people suffering from various forms of visual impairment) I have found out that the usual behavior is jumping through the top part / navigation, so more often than not missed the first paragraph of the text. Moreover, it goes against good webdesign practices, so this was in fact quite a bad idea.

What works is a very clearly formulated site structure. A stereotypical accessible page has a header, with navigation and branding, followed by the main content. The main content should start with a heading.
Stereotypical accessible page
According to my tests the above structure makes the most sense and easiest to use for people living with disabilities. Let me tell you a secret: header first, then heading followed by content is the easiest to use for anyone, not just those with disabilities.

The myth of the high contrast view

There used to be a myth, that there are disabilities that require a so called “high contrast” view. There are quite a few sites which contain a so called “blind or poor eyesight friendly” view. There is even an icon for that: high contrast view icon

Until you stand next to people with disabilities, and watch them use the web, you might think that this is a neat feature. When I was leading the Elistaria CMS team, we automatically included the generation of accessible versions of the site, on the “a.” subdomain. Although the accessible version helped in case of screen readers (where the contrast is irrelevant), the high contrast was annoying to those with poor eyesight, very low vision, different types of color blindness, etc.
high contrast CSS
I have not found a single person who enjoyed yellow and/or white text on #000 black   background. Although white on black was “bearable”, even with yellow hyperlinks, but every test subject preferred the #333 dark gray   text on white or very light background. The reason is that those people set the contrast and font size for their own liking based on the average website. Now if you give them something that overrides that, or simply go too far from the majority of the websites they will need to change their settings. I don’t think that you would like to change monitor settings or do OS accessibility tweaks just for one site. The morale of the story: forget the high-contrast yellow-on-black, and make your site’s background very light or even white, and set the font color to a very dark gray, but not black. Users with or without disabilities prefer that.

I think the most well-known accessibility feature in HTML, is the alt attribute of the images ( elements). This should contain a meaningful description of what’s on the image. By all means, make it short, and to the point. Please do not add the keywords your SEO expert tries to target, hoping that Google would rank your site better. It will not, and the disabled users will hate you.

Climb into his skin and walk around in it

„You never really understand a person […] until you climb into his skin and walk around in it.” (To Kill a Mockingbird, by Harper Lee) I think the 2nd most important quote in UX is what Atticus Finch told his daughter. (I consider “Don’t make me think” by Steve Krug the most important quote, even if it’s the title of a book.) Anyways, if you don’t want to spend time, resources and/or money on finding people with disabilities try to experience your website as if you would have them. Although gouging your own eyes is not among the most popular UX techniques, you can blindfold yourself and use screen readers. Moreover, you can set the mouse aside and try to navigate the site only with keys (after installing the needed software).

The most popular screen reader worldwide is JAWS. It is for Windows, and works great in almost all software applications and shines while browsing the internet. On the down side, it costs a small fortune. Unless you have a friend who has the software and lets your try your site on it, this will be out of range of tight budget accessibility testing.
Jaws
If you are using a newer Apple operating system (OSX 10.4+ or iOS), you can use VoiceOver for free. It’s as simple as turning it on. On the screenshot below you can see that on an iPad.
VoiceOver
If you are on a Windows PC, and you are testing the accessibility of a web application, website or even intranet application, basically anything that runs in a Chrome browser, you should try ChromeVox by Google.
Chrome Vox
It is quite far from Jaws to be honest, but if a miscellaneous passerby can use your web application blindfolded, armed only with ChromeVox, then you did an extremely good job in making it blind friendly.

As with all usability tests, it is of vital importance, that you correct the obvious usability errors, user pitfalls and obviously bugs between testing sessions, otherwise you will find the same big usability flaws again, and again. This would mask the minor issues. So the kaizen way of doing usability test is: test → improve → test again.

Futuresight

A few days ago I got a great book recommendation from @jstan: The Future Of The Mind: The Scientific Quest to Understand, Enhance, and Empower the Mind by Michio Kaku. It is a great read, and quite eye opening. In the not so far future web accessibility might disappear, or totally change. Until that time, you should try the tips from this blogpost to make your website easier to use for those living with disabilities.

Leave a Reply