Guide to web accessibility: part three
As outlined in the first part of our guide to web accessibility, ease of access for people with disabilities is an essential part of modern web services. In part two of our web accessibility guide, we showcased some of the best standards, guidelines and tools for making your projects as accessible as possible for all users.
But like a lot of things, the hardest part of web accessibility is putting it into practice. In this final section of the guide, we’re looking at the specific actions that designers, developers and content creators can take to provide the best possible experience for users affected by disabilities.
Optimising for screen readers
When it comes to screen reader optimisation, one of the most common and easily fixable issues is missing alt text on images. Without alt text, screen reading software has no way of knowing what an image represents, making them meaningless for users with visual disabilities. But appropriate alt text is easy to implement, and can even be automated – a great example of a very simple change that makes a big difference.
Similarly, elements like purely visual graphs without accompanying data and unlabelled form fields can cause issues. To provide the best possible experience for people with visual disabilities, it’s always a good idea to provide as much content as possible in text form – this includes things like transcripts of video/audio content.
Another thing that can mess with screen readers is capital letters – be careful using all-caps for emphasis, as they can be incorrectly interpreted as an initialism.
Finally, non-descriptive link text such as “click here” should be avoided. Screen readers are often used to quickly scan a page for links, so the link text needs to make sense out of context. For example, instead of “click here to book a table now”, a far better option would be “book a table now”.
Building accessibility into text and links
Text in general should be as clear as possible to maximise accessibility for users affected by different levels of visual impairment. This means large text in a readable font, and contrasting colours for the text and background.
For users with colour blindness, a site that relies on colour to convey meaning can be difficult to navigate. This applies to design elements, and also hyperlinks. Links in a different colour are often not distinct enough, while links that are also underlined or bolded can be easier to recognise.
Accessibility via navigation and functionality
Ease of navigation is important for people with physical disabilities that prevent them from using a mouse or keyboard easily.
For people who have difficulty operating a mouse, large, easily clickable navigation buttons go a long way. For users that can’t use a mouse at all, having as much functionality as possible available via keyboard commands is invaluable.
Touchscreen technology has increased accessibility for some users with physical disabilities, but designers need to think carefully to take full advantage of touchscreen devices. Large touch points go hand in hand with responsive design – these should be a minimum of 44x48 pixels (the size of the average thumb).
And autocomplete functionality for online forms – a welcome convenience for all users – can be a huge help for people with physical disabilities.
Creating accessible content: format and style
As well as the benefits mentioned for screen readers, providing text transcripts for your video and audio content also provides accessibility for users affected by hearing disabilities. Subtitled videos can be beneficial for a wide range of users, but for people that can’t hear well or at all, they’re essential.
To make websites accessible for people with cognitive disabilities, web accessibility needs to go beyond the technical and design elements.
For users with learning difficulties, short sentences, clear language, and where possible, avoiding complex vocabulary, can help to make content easier to follow and understand. This approach to content also covers things like error messages, which should be written as straightforward explanations, not confusing codes.
Animation and photosensitive epilepsy
While animations and visual effects can be key elements of a dynamic website, special care must be taken to ensure that people who suffer from epileptic seizures are not adversely affected.
WCAG 2.0 recommends that web pages do not include visual content that flashes more than three times per second. Flashing, flickering and blinking effects should all be avoided, and the user should have the option to disable animation. Further information on designing with photosensitive epilepsy in mind can be found in the guidelines mentioned in our previous article.
Implementing web accessibility: an overview
As a quick summary, the primary elements of web accessibility can be broken down into the different needs of users:
- People with visual disabilities: alt text on images, descriptive link text, transcripts of video/audio content, underlined/bold links, contrasting colours, readable text size and fonts
- People with auditory disabilities: subtitled video content, transcripts of audio content
- People with physical disabilities: ease of navigation, e.g. larger icons, keyboard functionality, auto-completing forms
- People with cognitive disabilities: clear explanations of functionality, content using simplified language and shorter sentences where possible
- People affected by photosensitive epilepsy: avoid flashing/flickering/blinking animations and effects
This is just an overview of the primary elements of web accessibility; you’ll find more extensive and in-depth information in the guidelines mentioned previously. But implementing web accessibility doesn’t have to be complex or expensive – and often yields a wide range of benefits for businesses and organisations looking to optimise their online presence.
By taking some time to get familiar with the main principles of web accessibility, web designers and developers can quickly build a good understanding of the concept as a whole – as many of them already have. Then it’s a case of implementing web accessibility as just another normal part of web development.