Anikto LLC

Web Accessibility Overkill

No one should question the importance of implementing good accessibility practices in web-based media. Sometimes, though, development teams go too far in applying accessibility features to their designs. Here are some tips to translate those good intentions into something of tangible benefit for users with disabilities:

Don’t overdo the ALT attribute with too much text.

Textual equivalents are used to provide some context for screen readers to interpret images on the page. Sometimes, project teams are asked to include more text than is actually necessary to accurately describe the image, whether for SEO or other purposes. Don’t do this — it confuses the screen reader and renders the page excessively verbose. Be accurate, get to the point, and avoid using the phrase “picture of …”

Don’t provide alt text for graphics that have no meaning.

There’s no need to specify such items as “upper left corner of frame” or “bullet” for images with no context. A simple null value (alt=”") will do just fine. Screen readers will know to skip over those assets.

Don’t insert non-linked punctuation between links.

You see this in a footer sometimes, where links are separated with a pipe (vertical line) character. This is disorienting for users with screen readers, since the software will read those characters back with little context. A much better option is to use cascading style sheets to add a small border to the right of each link. For the last link in the series, simply provide a pseudo-class element to remove the pipe from that selector.

Be careful when considering the implementation of access keys.

The use of access keys can be very tempting; it’s a way to provide quick keyboard shortcuts to navigation items. The problem is that there is no standardized convention for using access keys across all web pages. Furthermore, the keystrokes can interfere with keyboard functionality built into the screen reader software. There are compelling reasons to disregard access keys completely. That said … if a decision is made to employ access keys, then keep in mind the following standard still in practice in the UK:

• S – Skip navigation
• 1 – Home page
• 2 – What’s new
• 3 – Site map
• 4 – Search
• 5 – Frequently Asked Questions (FAQ)
• 6 – Help
• 7 – Complaints procedure
• 8 – Terms and conditions
• 9 – Feedback form
• 0 – Access key details

Don’t provide a redundant table summary.

If the contents of a table are explained in the body text of the page preceding or following the table, then the summary just adds to the clutter translated by a screen reader. Let the content do its job.

Don’t overdo “Skip” links.

Providing more than one “skip” link creates cognitive overload. One visible link that says, “Skip to main content” will suffice in most instances. (Note how the link is worded. We want to provide some idea of where the user will end up once the link is clicked.)

Don’t rely on the title attribute.

The title attribute can be used with some caution to provide tooltip information for users, but there is little evidence that it offers any benefit for users with disabilities. It’s much better to write a link simply and plainly that describes where it will take the user; duplicating this text in the title attribute is unnecessary and irritating for users of screen readers. Nor should it be used as a replacement for alternative text or form labels. The only HTML selector where the title attribute is read by screen readers is the frame element.

Don’t assume that tableless design automatically makes your page accessible.

Although not an optimal tactic, it is possible to design accessible web pages using HTML tables. A standards-based approach with compliant XHTML and CSS is, of course, always a much better route. However, it’s not a guarantee when designers get crazy with their div tags and complex float positioning. Make the content and context top priority; what’s most important is the order and expediency in which the markup is read back by a screen reader.

Don’t assume that compliance automatically equals user-centric accessibility.

Note my emphasis in the previous sentence. Have you ever listened to a government website with a screen reader? Try it sometime. It’s amazing how poorly many Section 508-compliant sites render during user testing. Keep in mind that Section 508 is a broad guideline, and that compliance does not guarantee that a site will be easily interpreted by a blind user.

Don’t assume that users with disabilities will read your accessibility statement.

People who use screen readers are just as impatient as any other user — sometimes more so. Project teams who make accessibility a priority are justifiably proud of their work and certainly deserving of acclaim. Just remember that users with disabilities are on your site to execute a task, just like anyone else, so don’t be offended if they skip the page intended to describe the site’s many wonderful features.

Update – Jeff Louella brought to my attention that this post should have been broken out with header tags. Doing this allows screen readers to tab through each item. In such instances I consider it a case of either/or, but it’s a good idea so I’ve made the adjustment. Thanks Jeff!