foreword
This article is based on a presentation by Rachel Appel titled: Be an A11Y! Build better software by building accessible software, which was presented at the Johannesburg-leg of DevConf 2020. It is co-authored by Stefan Olivier and Charl Meyers who were inspired by this talk.
introduction
As a person with a physical disability, I can truly say technology has opened a lot of doors in my life. The mere facts that I could graduate from university and pursue a career as a software engineer would have been next to impossible for a person with a physical disability 50 years ago. The widespread use of the internet, computers smartphones has made the lives easier for everyone, more so people with disabilities.
Any engineer should celebrate the impact of their craft on society, but like any engineer, we should not stop here – but rather identify ways in which we can improve the accessibility of technology even further.
Why is it important to consider disabilities when developing technology?
Worldwide there are about 1 billion people who have a disability. These range from physical disabilities, to loss of vision, hearing- and cognitive disabilities.
Furthermore, as of 2016, the ageing population in the USA equates to more than 49 million people and continues to grow. You may not have a physical disability at this point in your life, but you may be affected by age in the future.
Supporting all of these accessibility needs would require about $8 trillion. There is a big, booming market for the development of accessible technologies.
So where could you start and learn how to develop technologies for this market? In this article, we discuss some basic strategies that one can follow to make your web applications accessible for people with disabilities. It takes a look at the accommodation of various types of disabilities, from visual and auditory, to motor/dexterity and cognitive disabilities.
visual impairments
Today many people make use of technology to aid with visual impairments. You may be reading this article using such an aid. Reading glasses and contact lenses did not exist several hundred years ago. Perhaps you have taken this technology for granted?
Consider for a moment how much modern technology has been developed around man’s ability to see. Netflix, YouTube, Apple, Microsoft Windows… Most technologies are tailored around visual interactions. Imagine navigating an IDE and building software without having the ability to see!
It can be done. People with visual impairments make use of screen-readers to navigate computers and the web. A screen-reader essentially looks for text-elements and read them back to the user. The user then selects the menu-options and sends commands back to the computer to navigate there.
Screen readers have to read everything that is on a webpage. Imagine how difficult it must be to use websites that have pop-ups and ads everywhere. For a user with full vision, those pop-ups and ads are a mere annoyance, but for people with low to no vision, it can be impossible to use a website.
Since screen readers read everything, it will even read all of the links in a menu bar. This happens every time a page has loaded. At times it can take minutes to read out the contents of a menu bar. Now picture having to wait almost 5 minutes for the screen reader to finish reading a menu bar every time before it gets to the main content. That can surely be frustrating.
One workaround that we can include in our systems are skip links. They are essentially a hidden anchor tag that links to the main content when clicked on. They are hidden so that it is not visible to a user with perfect vision, but still on the DOM so that a screen reader can pick it up and enable people with low to no vision to ‘click’ on it to skip to the main content.
Below is an example:
(Note: it is the first thing under the body)
Make the skip link tiny and out of the way.
It cannot be hidden or 0px high, because it still needs to be ‘visible’ on the page because screen readers skip over hidden elements.
Other solutions include:
sr-only and sr-only-readable classes if you are using the Bootstrap accessibility plugin or any CSS library that has accessibility features built in.
Something else can be kept in mind is making use of semantic HTML when designing websites for people with visual impairments. Screen-readers can gather a lot of useful information about a web page semantically from semantic HTML elements.
Some of these include:
<nav>
<article>
<header>
<footer>
<main>
<legend>
In .NET you can use the Data Annotations namespace and any HTML code being generated will automatically include semantic HTML. Grouping together form elements using <fieldset> and <legend> can help screen readers get more information about a form that they would normally get from the DOM.
HTML5 Has built-in support for assistive technology. Should you be developing for a browser that does not have full HTML5 support, can use the ariarequired=”true” attribute. Aria attributes give metadata about a tag for screen readers. Aria attributes enable assistive technologies to work better.
If a field is required, mark it as such using the required keyword. People with low vision find it difficult to see an Asterix and people who are colour-blind interpret it as a speck of dust.
colour blindness
Colour-blindness is the inability to distinguish between particular colours. This could become a problem if a site relies on the use of colour to highlight certain important elements.
There are tools available that one can use to see how your website would be perceived by someone who is colour-blind.
These include:
- color-blindness.com
- colororacle.org
General tips that help people with colour-blindness are to have dark foregrounds over bright backgrounds. One can never go wrong with black on white or white on black.
Here are some examples of good/bad contrasts:
There is a tool called the Color Accessibility Wheel that helps you pick out the foreground and background colours with good contrast that works for everyone, including those who are colour blind.
auditory
Auditory disabilities are faced by those with mild hearing loss to complete deafness. It is however still applicable to anyone who may be using a system and forgetting to plug in their earphones or to turn up their system volume.
When using sound in your systems consider that some may not hear it and make use of alternative methods to provide feedback to users.
Where videos and audio clips are used the system can be made more accessible to a wider audience through the use of transcripts or closed captions.
I would definitely say it is worth looking into for personal projects or small projects that require an Android and iOS app. However, it would be difficult to convince clients to trade more stable and reliable cross-platform frameworks for fancy, fast-paced development
A lot of the issues mentioned can be picked early with proper testing and releases to Alpha and Beta channels.
I have used Flutter to create an app that is live on Google Play and the Apple App Store. I may be biased, but I am pleased that I didn’t have to learn Objective-C/Swift or have 2 different code bases doing the same thing just to have an iOS app.
motor/dexterity
When it comes to motor/dexterity disabilities we tend to think of people who are wheelchair-bound, who struggle to move. The reality is that anyone at any given time can injure a limb. The growing, ageing population tend to fall in this category where conditions like Arthritis and Tremors cause deuteriation in fine-motor abilities.
It is important to realise that not everyone will navigate a website using a mouse. Some limitations constrain people to only make use of a keyboard or pursue alternative technologies such as trackballs. We need to ensure our websites can be navigated using these alternative methods.
A good UX principle is to avoid pop-ups and modal-dialogues. Even people who are not disabled find these frustrating to use.
cognitive
Cognitive disabilities vary in their nature – from dyslexia and ADHD to down-syndrome. These disabilities affect how users may perceive your system. As people age, their cognitive functions are also affected.
The best way to accommodate cognitive disabilities when developing systems is to keep UX simple and clear and to perform UX testing using a wide range of users.
tools
There are some developer tools out there to help with designing accessible software:
WebAIM WAVE scanner (https://wave.webaim.org/)
Can be integrated into CI process and scan websites to find any accessibility issues
Web Content Accessibility Guidelines (https://webaim.org/standards/wcag/checklist)
Can also be integrated into CI process
Section 508 Checklist (https://webaim.org/standards/508/checklist)
CONCLUSION
An advantage of developing for the accessibility of disabled users is that you are also making your systems more accessible for users in general. Similarly to how we uphold clean-code and minimise technical debt we should advocate and promote the development of accessible software.