Twenty-six percent of the US adult population lives with some form of disability. Designing and building software without taking this fact into account therefore shrinks the potential audience for the end product — and that often takes more awareness and planning than standard UI/UX design demands.

Accessible software can boost market reach, but it has another vital benefit: legal compliance. The landmark Americans with Disabilities Act of 1990 mandates accommodations for disabilities and opens noncompliant software up to litigation. What engineers once took for granted is now a necessary step in the software development lifecycle, but what does compliance mean on the engineering side? It means adhering to Web Content Accessibility Guidelines (WCAG). Most accessibility regulations around the world follow WCAG, an international standard for grading software conformance between Level A (the legal minimum) and Level AAA (optimal).

But basic legality should be considered the minimum. If you look in the right places, there’s no shortage of examples of how to get accessibility right . . . and of how to get it wrong.

According to the W3C Web Accessibility Initiative, a global project launched in 1997, accessibility is simply usability applied in a broader context. It includes built-in features that make it easier for everyone to “perceive, understand, navigate, and interact with” a piece of software.

Universal software design isn’t one-size-fits-all. It means building with a range of user experiences in mind, ensuring performance remains strong through flexible software solutions. Disabilities that accessible software seeks to accommodate include:

• Visual disabilities, including blindness, low vision, and sensitivity to color and brightness, as well as color blindness, may necessitate tools such as screen readers to navigate software.
• Auditory disabilities, including hearing loss and deafness, may make it harder to use an app or other software that relies on audio prompts.
• Speech disabilities such as muteness, dysarthria (a speech disorder caused by weakened muscles), and stuttering can make it challenging for software to recognize speech.
• Physical or motor disabilities may affect how a user physically interacts with software, such as on a touchscreen or keyboard.
• Dyslexia, dyscalculia, ADHD, and other cognitive and learning disabilities may affect how a user comprehends or interacts with a piece of software.

As the above demonstrates, software accessibility doesn’t — and shouldn’t — conform to a single, uniform set of parameters. It’s less a strict guide and more a roadmap that starts with identifying what doesn’t work in order to build a product that does.

Planning for maximum app accessibility starts with identifying flaws that are common in existing less-than-perfect software and apps.

• Insufficient color contrast: Colors with low levels of contrast are among the most common accessibility errors impeding users with visual needs.
• Lack of text resizing: Text resizing is usually determined by the user in their hardware’s settings — in Apple’s system preferences, for instance, rather than in individual apps. But some apps override a user’s preferences, leaving them to grapple with the app’s predetermined text size.
• Lack of alt-texts for images: Alt-texts (short descriptions coupled with an image) aren’t just useful for slow connections. By describing the content of images and videos, they offer a second avenue for experiencing a product.

Accessible features such as support for screen readers and deep user customizations are sometimes equated with features that make software bloated, unsleek, and (ironically) harder to navigate. But this is arguably a consequence of technical debt related to accessibility — that is, reams of inefficient code utilized to speed up the development cycle — rather than a consequence of accessibility itself. By considering universal design from the beginning, you can avoid the headache of future adjustments that will take outsized resources to correct.

Accounting for accessibility when building software can tighten the entire operation, resulting in stronger products. When planning for accessibility is baked into the process, a number of concerns that are traditionally top-of-mind during software development, including improving usability, widening an app’s potential user base, and ensuring legal and industry compliance, actually become better executed.

Start by aiming to build a product that is accessible to all users, no matter what their challenges might be, and weaving that commitment into every phase of the build.

If you’re working with a software developer or consultant, they should use the discovery phase to help give you a sense of the web accessibility requirements your app should adhere to, and provide a roadmap for achieving compliance. For example, you should consider what aspects of your app might need additional accessibility features.

In the process of mapping out the look, feel, and navigation of your software, accessibility should be a top-of-mind concern. Consider features such as color contrast, text size, and the alt-text of images at this stage.

Development platforms, tech stacks, and programming languages all have different accessibility requirements and standards. React, Vue, and Svelte, for example, all take accessibility into account from the get-go. According to CTO Michael Fouquet, a thought leader on extensibility, accessibility, and design systems, developers should mix and match the tools they use in development in order to ensure they’re building an inclusive, accessible end product. “If your framework leans more towards visual navigation,” he writes, “pair it with Google’s accessibility tree or Firefox’s Accessibility Inspector, which helps developers understand how content is exposed to assistive technology. If your requirements are predominantly for people with audial impairments, try Orca’s screen reader for desktops like MATE, GNOME, and Unity.”

While testing is something that every piece of software undergoes, it’s important to conduct specialized tests around accessibility features. Tools such Lighthouse, Wave , and ANDI can be used to verify general accessibility, while NVDA, JAWs, and VoiceOver are strong options for checking software performance with screen readers.

As any developer or software professional knows, the end product is never truly complete; continuous optimization is key to keeping solutions performing at top capacity. Fold assessment of how an app is performing in terms of accessibility into your usual optimization processes.

Building accessible software requires work to understand both how an app functions in the real world and the roadblocks users may encounter while using it, but the benefits of universal design stretch beyond users with disabilities: people in loud rooms who appreciate subtitles, people who can make out an app’s sharp contrast despite the sun’s glare, people with their hands full who can still hit touch targets. By keeping universal design and web accessibility front and center throughout the development cycle, you improve the user experience for all users. You’ll increase your user base, achieve compliance, and develop a product that’s sleek, efficient, and built for everyone.