But in fact they can, thanks to screen reader software that will read the text available on the website to them, and also the interactions that are possible, if your site is configured properly. This type of website configuration, for people with disabilities, is known as “web accessibility”. Let’s take a look at what’s involved.
Web Content Accessibility Guidelines (WCAG)
The WCAG contain a bunch of standards and guidelines developed through the W3C (international standards for building a website) process to help you create websites for people with disabilities. This involves a wide range of disabilities; visual, auditory, physical, speech, cognitive, language, learning and neurological.
Disabilities are sometimes formed when people grow older and when brands adjust their website to address this group of people, the usability for users in general will automatically improve. For example the alt-tag on images is useful for people who are using screen reader software, but it is also very convenient when an image is missing from the website, as it describes what the image was representing!
Consequently, being aware of the accessibility of your website will result in a larger range of target audience. If you take into account that this only takes a minimal cost to handle (the digital medium is the cheapest one to reach people with disabilities), you should consider doing it by default. Also in terms of SEO, you will benefit from an accessible website, as google uses this parameter as a metric to rank search results!
So what exactly do you have do to be more accessible?
WCAG is based on four principles: PERCEIVABLE, OPERABLE, UNDERSTANDABLE, ROBUST. In this article, I will address the most important things to take into account for each of these principles. Keep in mind that there is no such thing as “perfect accessibility” or a site being “100% accessible”. Companies or services shouldn’t make those promises but they can take actions to improve accessibility.
Web Accessibility - Principle 1: Perceivable
The perceivable principle means that information and user interface components must be presentable to users in ways they can perceive. When a user needs assistive technology to browse a website (for example blind people use screen reader software to guide them through a website), they should be able to recognise the interactive components on a website (a button that leads to a contact page for example).
All non-text content that is presented to the user should have a text alternative that serves the equivalent purpose.
To achieve this, we can use different techniques when building our html code.
Aria tags on buttons – for example “this button sends an email”
Alt tags on images – for example “this is an image of a dog”
Name tags on input fields – for example “Date of Birth”
Use of color for example high contrast colors for people who are color blind
Web Accessibility - Principle 2: Operable
This principle means that all components and navigation should be operable. You should be able to access every part of the content not only with a mouse, but as some people are unable to use a mouse, they should also be able to access the content with a keyboard.
You also need to provide users enough time to read and use the content. Any moving or scrolling animation should be taken into consideration carefully as it could hurt the operability of the website. The general rule is that for every animation that starts automatically it should:
- Last more than 5 seconds
- Be presented in parallel with the content
- Ensure the user can pause, stop or hide it
In terms of unnecessary animations, we should also proceed with caution, as there are a lot of people who suffer from seizures and physical reactions to flashing content. The general rule here is that you don’t apply animations when it’s not essentially needed. This could however damage the aesthetics of your website greatly, so in order to fix this, you can consider writing animations only for devices that allow them! In your CSS (Cascading Style Sheets) you can actually target user agents and operating systems that have the reduced motion feature turned on! Reduce you motion in CSS.
Some examples of how to think about accessible animations:
Use a site-wide setting to turn off all animations (parallax scrolling, hover animations, page flip animations,...)
Take advantage of the CSS reduce motion media query in order to disable animations on devices that have this feature turned on.
The navigation of the website should be completely navigable by using tabs, so the focus order and visibility are of the utmost importance here! Be sure that there is a logical way that users can get to certain parts of the navigation and that they can actually see which item they are focussed on. As they are using a keyboard to navigate, they don’t see a mouse cursor to indicate where they are. Also make sure you test your forms by trying to access and submit them via a keyboard.
Web Accessibility - Principle 3: Understandable
You should make sure that you use user agents in a proper way when it comes to multilingual parts of your website. You can define the ‘lang’ tag in the html to show exactly what language you are on, but besides this, there is a lot more you can do.
When you for example have a piece of content in a different language (like a quote in German), you should tell the user agent that this piece of content is actually written in ‘German’, so screen readers can change their pronunciation!
For your forms, you should provide decent labels and error identification/suggestions, so the user is assisted in a correct way when trying to submit a form.
Web Accessibility - Principle 4: Robust
The fourth and last principle means that your website should be robust enough so that it can be interpreted by a wide variety of user agents, including assistive technologies! You should have a valid html document without errors, and your website should be tested across browsers/devices! This is a thing that really sounds logical and easy, but in many cases gets pushed back in the project because there ‘isn’t enough time’. Actually, this part of the process should happen on the fly when you are finishing tickets, and every ticket should be tested separately on every browser/device.
Why would you care about web accessibility?
If you are asking yourself this question, then you should also be questioning wheelchair ramps in malls, books written in braille or even sign language… It’s just common courtesy to do so. So really think this through the next time you’re building a website because if you fail to do so, people with accessibility issues will go to the website that provides that “wheelchair ramp.”
To help you achieve this, here is a very handy checklist.