Academics mimic life: building site accessibility in the real world

This is a good topic to be analyzing while on the cusp of building a new set of list-based horizontal and vertical navigation schemes. I made sure to do my research on accessibility before starting the nav menus that are on my deliverables list, and that is turning out to be ideal, because now I can easily build even better accessibility into my deliverables than is required. They will have a much higher value with very little sweat on my part.

The nav menus I initially had in mind would have been structured with semantic list-based HTML, and that’s half the battle right there, but there are other techniques that increase the level of accessibility of menus — and pages — beyond that minimal level. They are techniques that do not affect the look of the page for sighted users, but they definitely enhance the user experience for visually impaired visitors of the site.

Some of the more thoughtful techniques are:

• Using the off-left technique to hide text useful for screen readers, but too cluttered for the visual page — text such as “Main Navigation”
• Making rollovers work for both mouse users and keyboard (tab-key) users
• Skip Navigation Links — elements that allow users to better navigate the linearized Web page that is imposed on many people with vision or motor challenges

Accessibility relies first on good markup

Reading through a list of headings to get a sense of the structure and content of a page is the most basic task of a visually impaired person. Similarly, using a keyboard-only to quickly tab through headings and links is central for someone who can’t use a mouse due to physical limitations. Both of these basic tasks rely on good semantic markup. So even before a developer or designer might need to think of enhancing accessibility, they should nail the basics of page structure. That’s not accessibility best practices, that’s just plain best practices.

Even the content of the page needs to be taken into consideration. The usefulness of descriptive heading text and link text can’t be ignored. Think about these things as they are being written or edited. No one wants to go back and edit the content of archived articles for poorly written headings and links.

Some of the more basic guidelines that affect markup as well as page content are:

• Using semantic heading markup so that a list of only headings makes sense of the page
• Writing heading text that is descriptive of the content following the heading and thus useful for someone who can’t do a quick visual scan of the text
• Writing link text that clearly explains what the link is pointing to — imagine the frustration of reading a link list that consists of 20 links that read “click here”

Having this strategizing experience now, I can more easily explain to reluctant clients why it is better to build accessibility into a site during construction than to retrofit a site after the fact.

The clear argument for cost-effectiveness

Yet nailing the basic page structure often goes overlooked. It goes overlooked because the focus so often is on the visual presentation of the page, which doesn’t necessarily have to be backed by semantic markup. However, all of the presentational workings of the site — the CSS — is based on the markup regardless of whether the markup adheres to standards or to whim.

So, now think about doing an accessibility retrofit of a site with whimsical markup. You must approach the biggest problem first — the semantic markup of the headings and navigation elements. But wait. All of the presentational CSS relies on the way the content is tagged with HTML.

“You mean I have to rethink what content is tagged h1, h2, etc? I have to change those tags? No way. That would completely whack the way the way the headings look. It would make the current presentation look like a jumbled jigsaw puzzle. Things would suddenly be the wrong size, the wrong color. I would have to go into the CSS and practically rewrite it all because the CSS relies on the choices I made in doing the HTML markup. By fixing one problem CSS rule, I would create a new problem in a different rule. It could be never ending.”

Realizing that problem is the clearest reason to put accessibility at the beginning of the project. Doing an accessibility retrofit does not mean adding new features. It means cleaning up code that in the bigger picture could be like replacing a building’s foundation. Better to get the foundation right when it’s easy to work on. Once it has a multi-story building resting on it, a relatively small fix can become a monumental task.