Building Accessible Web Apps
The web plays a big role in our lives; the home of great resources. But, you contribute towards making these resources unreachable to certain users if you do not build with accessibility in mind. Accessibility should be an integral part of any design process, not an after-thought. An accessible app equals good user experience (UX).
"The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." - Tim Berners-Lee
In this article, I'll cover basic accessibility principles and tips to help you build usable web applications.
What is Accessibility?
Accessibility can be defined as making sure that the content on the website we create is usable to people with various abilities or impairments. It means building with inclusion in mind to improve the user experience for everyone.
The word "a11y" is often used to mean "accessibility" because there are 11 letters between the "a" and "y" in the word "accessibility". This concept is known as Numeronym.
An accessible app is one that:
- Users can navigate with a keyboard or screen reader
- Is marked up using the right element for the right role
- Displays well on both desktop and mobile devices
- Is usable by people with poor network connection
- Can be used by everyone irrespective of the geographical area
- Has a good contrast ratio.
We are affected by inaccessible design in different aspects of our lives. It is not restricted to web apps. It has to do with much more. Imagine a scenario where someone cannot gain access to a building as a result of no alternative way of entry asides the staircase. Buildings constructed with accessibility in mind provide an alternative method to using the staircase. Someone using a wheelchair or a parent with a baby in a stroller needs to be able to access the building with ease.
Statistics on disability in the US postulate that a high proportion of the society is situationally, temporarily or permanently disabled. Diverse users of the web application you build suffer from different impairments and we need to build with these people in mind. These are categorized as motor, visual, hearing, cognitive impairments.
Motor Impairment: These users experience partial or total loss of function of a body part resulting in muscle weakness. A scenario whereby a user uses a site while holding a baby is categorized under situational motor impairment. A broken wrist is a temporal impairment while someone with no arm is categorized under permanent impairment.
Visual Impairment: Users with no vision, severe or minor visual issues are categorized under this. They use braille, screen readers or magnifying glasses to access contents on a website. Users who suffer from color blindness or find it difficult using the computer under the sun falls into this category.
Hearing Impairment: The deaf, or users listening to music at a high volume cannot decipher when a notification is received if it is identified by sound alone without accompanying visual information.
Cognitive Impairment: Users in this category suffer from dyslexia, autism etc. They experience difficulty remembering, concentrating, or making decisions.
Sequel to these, a set of guidelines (WCAG) was put together to help developers build accessible web apps.
The WCAG Criteria (POUR Principles)
The Web Content Accessibility Guidelines (WCAG) 2.0 is based on the POUR principles.
Perceivable: Building contents perceivable by all users of the app using all senses, impaired users inclusive. You should provide captions for videos and text alternative for non-decorative images. Do not use color alone to convey information.
Operable: Users should be able to use your web app irrespective of the device they use to access it. It should be easy to navigate using the keyboard.
Understandable: Applications should be intuitive enough to the users. You should not let them experience difficulties trying to use the app. Consistency should be maintained in the user interface and user flow.
Robust: Applications should be well-structured to ensure that it is accessible to user agents and assistive technologies.
Not using semantic elements where necessary
outline: none. By doing this, a keyboard user cannot differentiate focused elements from others.
Controls with a
tabindex> 0. This gives higher precedence to the elements and overrides every other thing in the tab order.
Using tabindex for non-interactive elements
Using low contrast colors
Non-text content without text equivalent (with the exception of decorative contents)
Not associating labels to form input fields
Not indicating the meaning of * in form labelling
Using a link text whose purpose is not clear e.g. read more or click here
Auditing a Web App
Different tools exist to help you identify accessibility bottlenecks. Screen readers come in handy. They read out the role, name, value and state of the element in focus.
The tools below can be used to determine if a web page is properly marked up:
- The Audits panel on DevTools
- Accessibility Insights
- Axe extension
- Color contrast checker
- Screen readers - VoiceOver on a mac, NVDA on Windows and Orca on Linux
Using Screen readers
- Launch using Insert key (the default) or set it to use the Capslock key
- NVDA + N key to activate the NVDA menu
- NVDA + Down arrow key to read everything from your current reading position
- Down arrow key to read the next line
- Up arrow key to read the previous line
- Use the CTRL key to terminate the application
- NVDA + F7 to view all the element list (links, headings and landmarks on a page)
- Arrow keys: To navigate in browse mode
- Tab: Move focus to the next control
- Shift + Tab: Move focus to the previous control
- Spacebar: To focus for control
- ESC: Exit focus mode
Quick Keys: H: Headings K: Links B: Buttons L: Lists D: Landmarks
Using Voice Over
- CMD+F5 to turn VoiceOver on or off on OS X
- Normal keyboard operation (TAB, Shift+TAB, arrow keys etc.) work as normal with VoiceOver running
- CMD+L to jump to address bar
- CTRL+Option+U to open Web Rotor
- Type search term with Web Rotor open to search within Web Rotor
- Enter to move VoiceOver focus to an item from Web Rotor
- CTRL + Option + Spacebar to activate link/button/other element
- CTRL + Option + ← ↑ ↓ → to explore content
- CTRL + Option + CMD + H to move forward by heading
- CTRL + Option + CMD + Shift + H to move backward by heading
- CTRL + Option + W to have a word spelt out
Tips to Build Accessible Web Applications
To build accessible web applications;
A logical tab order and html sequence should be used. Tab order should be equal to the DOM order
To manipulate the page in response to user action, use tabindex of -1 to remove it from tab order and make it focusable programmatically. The term is known as managing focus
Provide visual hints (affordances). Interactive elements, like links and buttons, should be visually distinguishable from non-interactive elements. Relying on the hover state to do this is not advisable as it leaves users of keyboard and hand-held devices behind.
Write standards-compliant markup. Make adequate use of h1-h6 hierarchy. You shouldn't place h4 before h2 on a webpage. Use the right elements needed to achieve a particular design.
Web crawlers use alt text to understand image content. So, they are important for Search Engine Optimization (SEO). Put the full stop (.) at the end of the alt tag to improve accessibility.
Add skip link. This helps visually impaired users to go to the main content without spending much time going through the navigation.
Ensure that text elements on a page have sufficient contrast ratios
Test your app using screen readers
Building accesible web applications entail much more than what is covered in this article. To gain a wider user base and help build a better web, accessibility needs to be at the fore-front. Feel free to check out Web Content Accessibility Guidelines 2.0 (WCAG), Web Aim Checklist for WCAG 2.0, Web Accessibility Initiative standards and WAI-ARIA specification to learn more.