Building Accessible Web Apps | Chiamaka Ikeanyi

The web plays a central role in our daily lives—it is home to information, services, and opportunities. However, when accessibility is overlooked, many of these resources become unusable to a significant portion of users. Accessibility should be an integral part of the design and development process, not an afterthought. An accessible application is, quite simply, a better 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, we’ll explore the fundamentals of web accessibility, common pitfalls, and practical tips to help you build inclusive and usable web applications.

What Is Accessibility?

Web accessibility means ensuring that the content and functionality of a website or application can be used by people with a wide range of abilities and impairments. At its core, accessibility is about inclusion—designing and building experiences that work for everyone.

The term a11y is a common shorthand for accessibility. It’s a numeronym, meaning there are 11 letters between the “a” and the “y” in the word.

An accessible web application is one that:

Can be navigated using a keyboard or screen reader
Uses the correct HTML elements for their intended purpose
Works well across desktop and mobile devices
Remains usable on slow or unreliable network connections
Is accessible regardless of geographic location
Maintains sufficient color contrast for readability

Why Accessibility Matters

Inaccessibility affects people far beyond the web. Consider a building that only has stairs and no ramp or elevator. Individuals using wheelchairs, parents with strollers, or someone temporarily injured are effectively excluded. Buildings designed with accessibility in mind remove these barriers.

The same principle applies to web applications. Small clickable areas, poor contrast, missing labels, or keyboard traps can make an app frustrating—or impossible—to use for many people.

Statistics consistently show that a large portion of the population experiences disability at some point in their lives—whether permanently, temporarily, or situationally. Users of your application may experience one or more of the following types of impairments:

Types of Impairments

Motor impairments These involve limited or lost movement or muscle control. Examples include permanent conditions (e.g., limb loss), temporary injuries (e.g., a broken wrist), or situational limitations (e.g., using a device while holding a baby).
Visual impairments This includes blindness, low vision, and color blindness. Users may rely on screen readers, braille displays, magnification tools, or high-contrast modes. Even bright sunlight can create a situational visual impairment.
Hearing impairments Deaf or hard-of-hearing users may miss information conveyed solely through sound. Similarly, users in noisy environments or wearing headphones may not hear audio-only cues.
Cognitive impairments These include conditions such as dyslexia, ADHD, and autism, which can affect memory, concentration, comprehension, and decision-making.

To address these needs, the Web Content Accessibility Guidelines (WCAG) were created.

WCAG and the POUR Principles

The Web Content Accessibility Guidelines (WCAG) are built around four foundational principles, often summarized as POUR:

Perceivable Information must be presented in ways users can perceive. Provide text alternatives for non-decorative images, captions for videos, and avoid using color alone to convey meaning.
Operable Users must be able to navigate and interact with the interface using various input methods, including keyboards. Navigation should be predictable and free of traps.
Understandable Content and interactions should be clear and intuitive. Maintain consistent layouts, labels, and behavior throughout the application.
Robust Content should be well-structured and compatible with a wide range of user agents and assistive technologies, both current and future.

Common Accessibility Antipatterns

Avoid these frequent mistakes:

Using non-semantic elements where semantic HTML is appropriate
Removing focus styles with outline: none without providing a visible alternative
Assigning tabindex values greater than 0, which disrupt natural tab order
Using tabindex on non-interactive elements unnecessarily
Low color contrast between text and background
Icons or images without accessible text alternatives (unless decorative)
Form inputs without associated <label> elements
Using symbols (e.g. *) in forms without explaining their meaning
Vague link text like “click here” or “read more”.

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

Preventing users from zooming or scaling the page.

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

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

Building Accessible Web Applications: Practical Tips

Follow a logical DOM order and ensure tab order matches it
Manage focus intentionally when updating content dynamically (e.g., using tabindex="-1")
Provide clear visual affordances for interactive elements—don’t rely on hover alone
Use proper heading hierarchy (h1–h6) and semantic HTML
Write meaningful alt text for images; this also benefits SEO
Allow users to zoom and scale content freely
Include a “skip to main content” link for keyboard and screen reader users. This gives them access to the main content without spending much time going through the navigation.

<body>
  <a href="#main-content" className="skipToMain">Skip to main content </a>
  <header>Header</header>
  <main id="main-content"></main>
  <footer>Footer</footer>
</body>

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

.skipToMain:focus {
  top: 0;
}

Write descriptive, purpose-driven link text
Avoid relying on the title attribute for critical information
Ensure sufficient color contrast throughout the interface
Use visually hidden text (sr-only) to provide context for assistive technologies

<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;
}

Test regularly with screen readers and keyboard-only navigation

Auditing a Web Application

Accessibility testing should be part of your regular workflow. Screen readers are especially valuable, as they expose how assistive technologies interpret your UI by announcing element roles, names, states, and values.

Helpful tools include:

Screen readers: VoiceOver (macOS), NVDA (Windows), Orca (Linux)
Accessibility Insights
Axe browser extension
ChromeVox
Color contrast checker and analyzer
Pa11y
NoCoffee (vision simulation)
Tenon
WAVE

Using Screen readers to Evaluate Web Accessibility

Non Visual Desktop Access (NVDA)

Quick Keys: H: Headings, K: Links, B: Buttons, L: Lists, D: Landmarks

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

Voice Over

Command + F5 to activate VoiceOver
Normal keyboard operation (TAB, Shift+TAB, ESC, arrow keys etc.) work as normal with VoiceOver running
Command + L to jump to address bar
Control + Option + Spacebar to activate link, button or other element
Control + Option + A to start reading the entire web page from the current position. You can pause the reading by pressing the Control key.
Control + Option + ← ↑ ↓ → to explore content
Control + Option + Command + H to move forward by heading
Control + Option + Command + Shift + H to move backward by heading
Control + Option + W to have a word spelt out
Control + Option + U to open Web Rotor which helps you quickly jump to different types of content such as headings, links, tables, form controls, and landmarks. Type search term with Web Rotor open to search within Web Rotor. Enter to move VoiceOver focus to an item from Web Rotor

Conclusion

Building accessible web applications goes far beyond what can be covered in a single article. However, every improvement—no matter how small—helps create a more inclusive web. Accessibility expands your audience, improves usability, and reflects empathy in design.

To continue learning, explore these resources:

Web Content Accessibility Guidelines (WCAG)
WebAIM WCAG Checklist
W3C Web Accessibility Initiative (WAI)
WAI-ARIA Specification
WebAIM guides on using VoiceOver and NVDA

An accessible web is an inclusive web. Design with empathy—and leave no one behind.