Web developers attempting to build accessible websites often make the same mistakes time and time again. Although they’re trying their hardest sometimes their overzealousness gets in the way and actually hinders the accessibility of their websites.
The below 10 guidelines tell you what not to do, so you too don’t fall foul to these same common accessibility errors…
1. Don’t use verbose ALT text
Accessible web developers often insert far too much ALT text on to images, in the hope that this will help screen reader users. ALT text for information-based images should be short and succinct, and contain no more and no less information than what’s in the image.
Decorative images should always be given null ALT text, or alt="", so that they’re ignored by screen readers. Assigning ALT text that adds no real value makes it harder for screen reader users to work through the page as so much unnecessary content is being sent in their direction.
2. Don’t use random characters to separate links
One of the more minor accessibility guidelines states that adjacent links should be separated with non-link text. The reason this guideline exists is that some very old web browsers had problems with adjacent links, whereby they ended up making all adjacent links point to the same page.
This guideline is no longer relevant but can often cause accessible web developers to insert invisible characters (usually vertical bars) in between links. Unfortunately, each vertical bar is announced to screen reader users as ‘vertical bar’, which is of course nonsensical and makes it harder for these users to work through the page.
3. Don’t insert text into empty form fields for the sake of it
Another old and outdated guideline states that any empty form field should have placeholding text inside of it. This guideline originally existed as very old screen readers weren’t always able to pick up empty form fields.
All major screen readers now pick up empty form fields (and have done so for some time now) so it’s safe to ignore this guideline and not insert pointless text into a form field. Indeed, screen readers often don’t announce this placeholding text so screen reader users may enter their text in addition to the placeholding text without realising it.
4. Don’t use access keys
You can assign access keys to any links or form items so as to provide keyboard shortcuts to them. In theory this sounds like a great idea as screen reader and keyboard-only users should easily be able to activate key links from anywhere on any page.
Access keys shouldn’t however be used as they can override keyboard shortcuts for screen readers, rendering key screen reader functionality useless. The other problem with access keys is there’s no convention so the few sites that use them do so in whichever way they choose. Site visitors are unlikely to spend the time getting accustomed to your website’s particular access keys.
5. Don’t use the table summary (unless it actually adds value)
The table summary can be inserted on to any HTML table and is essentially a summary of what the table is. Screen readers read aloud table summaries before reading through the table, providing them with a summary of the table content prior to listening to the whole table.
The table summary should always be omitted from a layout table. Websites using a tabular layout sometimes have table summaries of ‘layout table’ which of course add no value at all.
Even with data tables, a table summary is only needed if there’s insufficient information provided about the table on the page (which isn’t usually the case).
6. Don’t forget about the content
The way that content is structured on any website is an enormous part of accessibility. A website may be perfectly coded and conform to the highest coding standards. If its content is poorly structured though, the site will prove difficult to impossible for some special needs web users.
There are a number of important accessible content considerations, some of which include:
- Front-loading content so that each paragraph begins with the conclusion
- Ensuring content has been broken down into manageable chunks with descriptive sub-headings
- Using lists wherever appropriate
- Ensuring that plain and simple language is used
7. Don’t worry too much about accessibility statements
Many websites attempting to offer great accessibility create lengthy and what they believe to be helpful accessibility statements. Typically these pages contain information on the accessibility features of the website, how to resize the text etc.
In reality, disabled web users very rarely look at accessibility statements. As web users we don’t tend to consult ‘help’ guides on any site – rather, we stumble along attempting to complete our goals. Although there’s nothing wrong with making an accessibility statement page there’s no need to spend too much time on it as it won’t really be used.
8. Don’t agonise over acronyms and abbreviations
Declaring whether something is an acronym or abbreviation is easy to do in the HTML, simply by using the <acronym> or <abbr> tags. The full acronym or abbreviation can then be expanded upon within this tag.
Most screen readers don’t support these tags though so they don’t really offer much of a benefit to these users. The users they benefit are sighted, mouse-using web users – when they mouse over one of these items the full expansion of the acronym or abbreviation appears as a tooltip. This can certainly be viewed as a small usability enhancement but doesn’t really count as an accessibility benefit.
9. Don’t change the tab order (unless you have a very good reason to do so)
The tabindex attribute can be used to change the on-page tabbing order but is rarely necessary. The default tabbing order is usually perfectly logical so doesn’t need changing.
Screen reader and keyboard-only users tab through links and form items in the order in which they’re placed in the HTML source code. Provided that users tab within each section roughly from top-left to bottom-right (which they will) then the tab order is perfectly adequate.
10. Don’t forget to listen with a screen reader
Whilst you’re building your accessible website don’t forget to keep testing the pages as you build them. In particular, you’ll want to listen to them with a screen reader to check that accessibility features you’ve implemented do work as planned.
For example, if you’ve inserted invisible text to aid screen reader users using display: none; you’ll find that this won’t actually be read aloud. Screen readers ignore text with this CSS command assigned to it so position the text off screen instead.
This article was written by Trenton Moss. Trenton’s crazy about web usability and accessibility – so crazy that he founded Webcredible, an industry leading user experience consultancy, to help make the Internet a better place for everyone. He’s very good at running CSS training and spends much of his time working on the world’s most accessible CMS.
Post Your Comment