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.

Why Accessibility?

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.

Same applies to web apps when the clickable area of a button, checkbox or radio button is very small making it difficult for users to use amongst other difficulties users of inaccessible web applications experience.

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 an 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.

Common Antipatterns

• Not using semantic elements where necessary

• Using CSS outline: none. By doing this, a keyboard user cannot differentiate focused elements from others. You can however style the outline to be visually appealing and fit your design system.

• 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

• Preventing users from scaling the web page

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
• ChromeVox
• Color contrast checker
• Color contrast analyzer
• Pa11y
• No Cofee
• Screen readers - VoiceOver on a mac, Non Visual Desktop Access (NVDA) on Windows and Orca on Linux
• Tenon
• WAVE

Using Screen readers

Using NVDA

• Launch using Insert key (the default key also called NVDA key) 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.

• Don't prevent users from scaling the web page. Instead of

<meta
  content="initial-scale=1, width=device-width, height=device-height, maximum-scale=1, minimum-scale=1, user-scalable=no"
/>

use

<meta content="initial-scale=1, width=device-width" />

• Add skip link. This helps visually impaired users to go to the main content without spending much time going through the navigation.

<main id="#main-content" className="main-content"></main>

.main-content {
  background: #bf1722;
  color: #fff;
  font-size: 14px;
  left: 0;
  padding: 5px;
  position: absolute;
  top: -50px;
  z-index: 3;
  -webkit-transition: top 1s ease-out;
  transition: top 1s ease-out;
}

• Add invisible content just for screen reader users

<span className="sr-only">
  Share article on Twitter
</span>

.sr-only {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
}

• Use descriptive links

<!-- anti-pattern -->
To know more about accessibility, <a href="/documentation"> click here</a>

<!-- standard -->
<a href="/documentation">Read the documentation</a> for more information about accessibility.

• Avoid using title attribute to show more information about a link. Devices using touch to function and assistive technologies will not be able to access this information.

• Ensure that text elements on a page have sufficient contrast ratios

• Test your app using screen readers

Conclusion

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.

Read WebAim article on using VoiceOver and using NVDA to evaluate web accessibility to understand more on how to use screen readers. An accessible world is an inclusive world. Embrace empathy and leave no one behind.