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…
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
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
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
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.
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.
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
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.
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).
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
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.
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
<abbr> tags. The full acronym or abbreviation can then be expanded upon within this tag.
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
Don’t change the tab order (unless you have a very good reason to do so)
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
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.