Digital Accessibility: Essential for some, useful for all

Accessible digital content can be used by the widest possible audience, including folks living with a disability.

All users and business stakeholders benefit from accessibility. There’s a multitude of use cases where folks can take advantage of an accessible application. People may find themselves in situations where accessibility helps even if they don’t live with a disability. Things like temporary illness and situational impairment are very common. Below are some examples of situational impairment where accessibility really shines.

• Sam is using older technology with poor performance compared to top-of-the-market offerings.
• Jordan is in a library and is attempting to watch a video without headphones.
• Jess doesn't own a computer and relies on responsive design needs for mobile devices.
• Cory often loses cell phone reception so he depends on offline access.
• Karla is attending a loud event without headphones and is attempting to watch a video.
• Terry’s dominant arm is in a sling due to a temporary injury.

Accessibility benefits are not limited to the users of an application. Now, more than ever, there’s tremendous business incentive for involving all possible software users. Such incentives include the capture of more market share, reputational elevation, avoidance of costly litigation and better search engine optimization via semantic markup, transcripts, etc.

There’s a large scope of digital content but let’s narrow our focus and explore what goes into making an accessible web application. Accessible web content complies with the four characteristics below which are defined by the W3C Web Content Accessibility Guidelines (WCAG).

1. Perceivable - Information can be presented in different ways without losing meaning; for example, in braille, different text sizes, text-to-speech, symbols, etc.
   • Provide text alternatives for non-text content.
   • Provide captions and other alternatives for multimedia.
   • Make it easier for users to see and hear content.
2. Operable - All functionality can be used in different modalities; for example, keyboard, mouse, sip-and-puff, speech input, touch, etc.
   • Do not use content that causes seizures or physical reactions.
   • Give users enough time to read and use content.
3. Understandable - Information and functionality is understandable; for example, consistent navigation, simple language, etc.
   • Help users navigate and find content.
   • Make text readable and understandable.
   • Make content appear and operate in predictable ways.
   • Help users avoid and correct mistakes.
4. Robust - Content can be interpreted reliably by a wide variety of browsers, media players, and assistive technologies.
   • Maximize compatibility with current and future user tools.

The whole is greater than the sum of its parts

A system trends toward being inaccessible without a cohesive team of informed members. Since awareness is the greatest agent for change, establishing awareness in an organization is the first step to building an informed team.

Accessibility is procured when the software we build predictably interfaces with assistive technologies and adaptive strategies.

On the Web, our applications should always support adaptive strategies such as adjusting browser or system settings like calibrating text size, zoom and color contrast. An adjustment like window resizing is also considered to be an adaptive strategy.

Some assistive technologies are screen readers, button switches, sip-and-puff switches, camera switches, eye tracking devices, braille displays, head pointers and speech recognition software. Assistive technology isn’t mapped to one type of disability and can be used in conjunction with adaptive strategies. Keyboards are the most prevalent digital assistive technology; however, assistive technology does not have to be digital. Eyeglasses are considered assistive technology used globally.

Design

Our applications should implement common patterns for website design, layout and user experience.

We should build intuitive applications. They should use consistent navigation, icons and elements which have an accepted connotation. If an application allows custom keyboard shortcuts, it should allow users to customize, save and share those shortcuts. This functionality is also beneficial for speech recognition software to be able to re-assign voice commands.

Accomplishing tasks should also be made as easy as possible. Processes can be divided into logical, essential steps with progress indicators where necessary. Additionally, it’s important to have multiple ways to accomplish a task. People who struggle with speech, for example, will have issues using voice-based services (Alexa, Siri, Google Assistant, Cortana, etc.).

There are a number of principles to keep in mind in terms of font accessibility. It’s preferable to use a limited number of simple and easily-readable fonts while being sure to avoid small font sizes. Also, we can’t rely only on the appearance of the font (color, shape, font variation, placement, etc.) to convey meaning. For example, some people with low vision will have an issue differentiating links from text if color is the only differentiator. Instead we can combine underlining and/or a different font weight along with focus and hover styling.

Where possible, try to use real text content rather than copy within graphics. This will facilitate screen reader discoverability, size enlargement clarity, lower bandwidth requirements, easier translation to other languages and better search engine optimization.

There are also some design choices to consider carefully when conditionally rendering content. Be weary of displaying important content only when hovering over an element. It can be a challenge to use assistive technology like zooming in if users need to rely on hover state to display content and screen reader users might miss it completely. It's usually good practice to have the same hover and focus element presentation.

Clear feedback is essential and screen changes need to be obvious to all users. For example, everybody should know when they submit a form successfully. Our users should also know why a form submission was unsuccessful and how they can correct the issue(s) through clear error messaging.

Our design considerations shouldn’t be limited to the desktop experience of our application. We need to ensure that our mobile interactive elements have adequate touch screen target sizes and that we’re offering responsive applications for devices with smaller screens and varying resolutions.

We should think of all possible users when designing software. Having an aesthetically pleasing website to a sighted user should not compromise the accessibility of the site.

Development

When implementing a design, it should be second nature for a web developer to write semantic HTML. If native HTML elements won’t suffice, we should reach for resources like the WAI-ARIA authoring practices (a reference published by the ARIA Working Group to help web application developers create accessible rich internet applications) to ensure we’re building accessible widgets.

Don’t sacrifice semantics for style. A common problem on too many websites is the misuse of heading elements in order to satisfy styling requirements. Many people utilizing assistive technology use headings to get an outline of the page. It’s important to use a hierarchical heading structure that makes sense in relation to the content we’re presenting. Don't skip heading levels or use unintuitive heading tags just for the font size or styling. Instead, use CSS to restyle heading elements where desired.

It’s important for us as developers to understand the minimum support needed to accommodate the spectrum of disability. That’s why we have the WCAG standards to adhere to. If we can code our applications in a way that meets the Web Content Accessibility Guidelines, then we can gain confidence in the usability of our application when interfacing with assistive technology.

As an example, let’s explore some considerations we need to make when offering video content in the applications we build. According to the World Health Organization's Deafness and hearing loss fact sheet, "Around 466 million people worldwide have disabling hearing loss." Videos should have closed captions, subtitles and transcripts to support people who can't hear well.

• Closed captions are written in the same language as the spoken audio.
• Subtitles are used for spoken audio translated into another language.
• Transcripts are a text version of the speech and non-speech audio information needed to understand the content in the video.

Video accessibility doesn't stop there. Someone with no hearing impairment and low vision has a different set of needs for properly accessing video content. Video captions make video more accessible for people with low vision. Also referred to as audio description, a video caption is a voice that will narrate what’s happening in video so the person doesn’t have to only rely on the audio.

Content authoring

Too often, the quality of text on a page gets overlooked as an accessibility issue.

Complex sentences that are difficult to read and unusual words that are difficult to understand can prevent users comprehending content and context. Additionally, the use of metaphors and slang can be difficult for some people who do not understand their meaning.

Walls of text can also be equally difficult to understand. Ideally, long passages of text should make good use of headings, sub headings, lists, images, graphs, as well as other illustrations to help explain and reinforce information contained within the text.

In relation to being cognizant of the copy we present to our users, we need to always use descriptive link text. Let’s be sure to avoid ambiguous link text like “Click here” as well as presenting crude URLs that are hard to understand when read aloud. Also, screen readers will not distinguish styling via CSS font variations such as bold and italics. These variations shouldn’t be used as the only means for conveying information. However, screen readers can discern the HTML elements associated with bold and italics.

Quality assurance

Having automated continuous integration tests for the quality of accessibility in our applications is very important but it’s also essential that we do not rely on those tests alone. While there are a wealth of great automated testing tools such as pa11y and Deque Systems' axe DevTools, there are also plenty of issues that can be missed with static analysis tooling.

We need to test our software with assistive technology. For starters, let’s put the mouse away and use the application with just the keyboard. Additionally, try to navigate the site and accomplish tasks with only a screen reader. We should all try to put ourselves in the shoes of our users.

When possible, it’s best to have a diverse group of people living with disabilities test our applications using the assistive technology they’re comfortable with. These folks should be involved as early as possible and should definitely be in the room when it comes to usability testing.

Business and product leadership

Teams tend to overlook accessibility when building a minimum viable product and it eventually becomes a line item of technical debt. It’s crucial to start focusing on accessibility as early as possible in the process of building an application.

It’s important for business leaders and project managers to establish an accessibility plan by defining objectives, establishing policies and budgeting. In addition, we all should be thinking about what’s needed to set up our teams for success by considering helpful measures like recruitment, staff training, evaluations and tooling acquisition.

Organizations should put together an accessibility policy. Make sure the accessibility policy has a well-defined scope and references specific standards with an expected conformance level. It’s also beneficial to include milestones you’ve set as an organization which are backed by a comprehensive monitoring and review process.

Moreover, it’s very important to understand the relevant local and national accessibility laws and policies. In the United States, federal agency leadership should be aware of Section 508 of the Rehabilitation Act of 1973 which states that agencies must give all employees and members of the public comparable access to information. State and local government leadership should become familiar with Title II of the Americans with Disabilities Act (ADA) and public business leaders should read up on Title III of the ADA.

According to UsableNet's 2019 ADA Website and App Accessibility Lawsuit Recap Report there were 2,235 federal ADA website lawsuits filed in 2019 and these numbers are rising. On average, there is one ADA website lawsuit filed per hour.

In some situations, an organization may be required to provide an accessibility statement, such as public bodies in countries that implement the EU Web Accessibility Directive. Accessibility statements should at least contain a commitment to accessibility for people with disabilities, the applied standard (such as WCAG 2.1) and contact information in case users encounter difficulties. In addition, it’s also advisable to include any known limitations to avoid user frustration, technical prerequisites (such as supported browsers), the environment in which the content has been successfully tested as well as references to relevant laws and policies. W3C offers a tool to help organizations generate an accessibility statement.

Move forward with purpose

Luckily for those of us who build web content we have the Web Content Accessibility Guidelines to follow. However, digital accessibility is by no means a solved problem.

Even within areas where accessibility standards are available, let’s continue to conduct and observe research like saliency-driven injection of ARIA landmarks where, in order to provide improved user experience with assistive technology, SaIL injects ARIA landmarks for important sections of the page into HTML markup using a deep learning model trained from gaze-tracking data. Let’s be on the lookout for new advancements in the space and keep accessibility in mind when building web applications.

Outside the scope of the web browser it’s important to pay careful attention to the accessibility implications in the software we build for mediums like the internet of things, wearables, ubiquitous mobile devices and "tap on glass" technologies like kiosks, ATMs, etc.

Developing accessible applications requires a multi-faceted approach. Business leaders, product owners, developers, designers, content authors and QA specialists all have a responsibility to work together, hold each other accountable and ensure the products they build are accessible.