Implementing accessibility: 10 mistakes to avoid
Web accessibility isn't as difficult as it may first seem. And many of the common accessibility mistakes have easy fixes.
Here we highlight 10 of the most common accessibility mistakes (and how to avoid them!).
1. Using verbose ALT text
Accessible web developers often insert far too much ALT text onto 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. Using 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 makes it harder for these users to work through the page.
3. Putting text into empty form fields
Another old and outdated guideline states that any empty form field should have place-holding 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 place-holding text, so screen reader users may enter their text in addition to the place-holding text without realising.
4. Using 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 since screen reader and keyboard-only users should easily be able to activate key links from anywhere on any page.
But access keys shouldn't be used as they can override keyboard shortcuts for screen readers, rendering key screen reader functionality useless.
The other problem with access keys is that 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. Using the table summary
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. Forgetting 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. But if its content is poorly structured, the site will prove difficult to impossible for web users with digital access needs.
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. Unhelpful 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.
An accessibility statement can be a useful way to set out your commitment to improving accessibility, as well as highlighting known issues on your site that you're working to improve. But be mindful that it won't necessarily be used in the way you assume by users with real digital access needs.
8. 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.
But most screen readers don't support these tags, so they don't really offer much of a benefit to these users.
The users they benefit are full-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. Changing the tab order
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. Failing to test 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.
Start your accessibility journey
We hope you found this post useful! For more information on how to kickstart your digital accessibility journey, do check out our web accessibility checklist.