Inclusive Design and Accessibility in Modern Product Development

Inclusive design means building products that work across abilities, ages, and contexts by design, not by retrofit. 

The European Accessibility Act took effect on June 28, 2025, and in the U.S., nearly a quarter of 2025's accessibility lawsuits hit sites that already had an accessibility widget installed. This proves that compliance can't be bolted on after the fact. 

Accessibility is the disability-focused, legally measurable slice of that work: the part scored against WCAG and cited in a lawsuit. Inclusive design is the wider practice it sits inside, extending past disability to age, language, connectivity, and situational limits like glare or a broken wrist. 

The two hold together only when accessibility lives in the design system, with automated checks running in CI as a required gate.

Why Inclusive Design and Accessibility Matter in Product Design

The European Accessibility Act is now in force, and WCAG 2.1 AA is the legal accessibility baseline for any digital product sold into the EU.

The path from a gap to a court filing isn't instant. Undocumented legacy UI fails an automated scan and manual audits. That documented failure surfaces in a demand letter, and the demand letter becomes a lawsuit or results in lost access to the EU market.

If a US business fails to make itself accessible and gets caught for the first time, the government can fine it up to $118,225. Compliance work done inside the design system is what keeps that chain from starting.

If you're not sure which approach your product needs, Monterail's product design team can help you map it out before those gaps turn into legal risk.

How Does Accessible Design Create Business Value?

The specific approach worth naming is semantic-HTML-first, shift-left accessibility.

This means building with native HTML elements from the first sprint. It's also testing for accessibility before code reaches QA. This is far better than retrofitting ARIA and remediation work after launch.

The chain runs in one direction: semantic HTML and early accessibility QA reduce post-launch remediation cycles, which widens the usable audience. This lifts conversion and retention while lowering legal exposure, protecting and expanding revenue.

For this to work, you need these non-negotiables:

• WCAG 2.1 AA as the floor,

• automated CI checks such as axe-core as a required gate,

• and a manual keyboard and screen-reader pass before every release.

How Does Accessibility-First Development Reduce Compliance Risk?

Accessibility-first development starts with semantic HTML and native elements instead of ARIA patches. It also means assistive-technology testing as a required pass before every release. Write accessibility criteria into each story's own completion checklist.

Once accessibility is scoped there, teams can catch barriers at design handoff. That shows up as a WCAG conformance rate tracked per release in CI.

It also determines litigation exposure on one end and access to the EU market on the other. Building accessibility into your design system components once is what turns it from a per-project decision into a standing default.

Compliance holds only when these are treated as non-negotiables, not best practices:

• Automated accessibility checks running in CI, using axe-core or Lighthouse

• A manual keyboard and screen-reader pass before every release

• A VPAT or EU accessibility statement maintained for procurement

• Accessibility acceptance criteria defined per story

How Do You Apply Inclusive Design in Practice?

Inclusive design is built on three interconnected principles: recognizing exclusion, designing for specific needs to benefit many, and offering multiple ways to engage.

Together, they shape how teams understand the diversity of real-world usage.

1. Recognize exclusion before it becomes a barrier

Every interface has the potential to exclude users through auto-advancing content, small tap targets, visual complexity, or interaction models that assume perfect dexterity or eyesight. When teams make exclusion visible in early conversations, they prevent expensive rework and avoid patterns that unintentionally block entire user groups.

2. Solve for one, extend to many

Designing for specific constraints reliably improves the experience for everyone. Take dark mode, originally introduced to reduce eye strain for users with light sensitivity. Today, most smartphone users prefer it for comfort, battery life, and readability.

3. Provide more than one way to engage

Users don't all interact the same way. Some rely on keyboards or screen readers, some use touch or styluses, some prefer voice commands, and many switch between methods depending on context. Designing for a single interaction method makes a product brittle; supporting multiple methods makes it robust.

How Do Teams Build Accessibility Into Product Development?

Support Flexible Interaction

Flexible interaction means that you support keyboard, voice, and touch, so no single input method is required to complete a task.

You test it across every input method in interaction design and QA before launch. On client builds, automated accessibility checks run on every pull request, so issues surface before code reaches manual QA. We built this for GiveDirectly, where keyboard navigation, screen-reader compatibility, and ARIA landmarks became core requirements of the donation flow.

A good example of flexible interaction is GitHub's mega menu. It’s operable by keyboard alone, letting power users navigate nested menus without touching a mouse.

Source: GitHub

Apple's VoiceOver makes iPhone apps operable without sight, with no separate "accessible mode" to maintain. Target's search and scan buttons measure roughly 2cm × 2cm, cutting the mis-taps that drive cart abandonment.

Source: Target Australia App

Nielsen Norman Group's touch-target research points back to a 2006 study recommending a minimum of 9.2mm for one-off taps, 9.6mm for repeated taps.

Just remember that every input method needs its own testing pass; passing keyboard tests says nothing about voice or touch.

Prioritize Readability and Visual Clarity

Readability and visual clarity come from high-contrast colors, a consistent type scale, and a clear visual hierarchy.

Check this at the visual design stage against WCAG contrast ratios before a single line of code ships.

A good reference is Harvard's site, which holds the WCAG contrast minimum throughout (4.5:1 contrast ratio), keeping text readable for users with low vision and for anyone reading outdoors in direct sunlight.

Source: Harvard.edu

Remember to check the contrast again once code renders it, as it may turn out different than the design file. 

Create Clear, Predictable Structure

Clear, predictable structure is achieved through plain language, predictable navigation, and simplified flows.

You need to test it at the content and IA (Information Architecture) design stage against real task flows. This comes before designing and coding. 

An example of good content structure is NHS England, which builds to WCAG 2.2 AA as stated policy. Its accessibility statement publicly lists its current non-compliances.

Source: NHS.uk

For this to work well, remember to apply clear structure to each page template carefully.

Adapt to Context, Device, Environment

An example of adapting your product to context or environment is building a UI that shifts depending on the situation. It can be a dark theme that follows time of day and reduces glare at night.

You need to test these features in post-launch monitoring and listen to user feedback.  

The same glare-reduction benefit that works for night driving applies to any low-light environment. Google Maps' dark theme, shipped and widely used across Android and iOS, proves this works at scale.

An adaptable interface needs continuous monitoring after release. A one-time check doesn't inform you how the UI performs across a variety of conditions over time.

Why Accessibility Is Key in HealthTech and Regulated Products

In HealthTech and other regulated products, accessibility and compliance arrive as the same requirement, not two separate checklists. Monterail's HealthTech portfolio spans this range:

• Camino, a senior mobility app built for older users managing a physical device and a screen at once

• Elvie, with FDA and MDR compliance built into a wearable medical device from the start

• Convatec, supporting patients managing chronic conditions who need the interface to work reliably regardless of their physical state that day

Our HealthTech software development team handles this: products that have to answer to both a regulator and a real user. If this is what you’re building and need a development partner, reach out to us.

How to Build Accessibility Into Your Development Process?

What Does Accessible Code Look Like?

Accessible engineering is about consistently applying three core habits: use semantic HTML, add ARIA only when it genuinely helps, and test with the same tools real users rely on.

When teams get these three things right, most accessibility work becomes straightforward.

How to Implement Accessibility with Semantic HTML 

Semantic HTML is the easiest way to make an interface accessible because it gives you keyboard support, focus management, and screen reader interpretation "for free."

• Use native elements instead of impersonating them: a real <button> automatically supports keyboard activation, focus states, and screen reader announcements. A <div class="button"> supports none of that unless you rebuild it manually. The same rule applies to links, lists, forms, and navigation elements: if HTML has a native tag for it, use it.

• Structure content with real headings, not styled text: screen reader users navigate pages by jumping between headings. A page with a clear <h1> followed by logical <h2> and <h3> levels becomes instantly more navigable. The heading level should reflect structure, not visual style (CSS handles that).

• Use semantic landmarks to help users jump around: elements like <main>, <nav>, <header>, and <footer> act as "map markers" for assistive technology. Users can skip straight to the main content, jump to the navigation, or find a form without scanning the entire page.

Semantic HTML is the foundation of everything else. If this layer is solid, ARIA becomes supplemental.

When To Use ARIA To Extend Accessibility

ARIA fills the gaps that HTML can't. But it's easy to misuse, and misused ARIA can break an interface for assistive technology users. The general rule is simple: if a native HTML element can do the job, use it instead of ARIA.

• Use <button> instead of <div role="button">

• Use <nav> instead of <div role="navigation">

• Use real lists instead of ARIA-labeled fake ones

Use ARIA only when native HTML isn't enough, specifically to announce states, handle dynamic content updates, or support complex interactive widgets:

• Announce whether an accordion is open (aria-expanded)

• Alert users to dynamically updated content (aria-live)

• Label icon-only controls (aria-label)

• Link inputs to helper text (aria-describedby)

Should You Test Accessibility Manually, or With Tools? 

Automated tools are a fast way to catch predictable code-level mistakes, things like missing alt text, low-contrast colors, or invalid ARIA. They surface only 57% of real accessibility problems, though.

To understand how your product behaves for users, you need to interact with it the same way they do. A simple keyboard-only pass (Tab, Shift+Tab, Enter, Space, Arrow keys) immediately reveals issues like missing focus states or components that aren't operable without a mouse.

Turning on a screen reader such as NVDA or VoiceOver shows if your headings form a clear outline or icons have meaningful labels. It can also detect whether form errors are announced or dynamic content is conveyed.

When you combine this hands-on testing with automated checks and validate it with periodic sessions with real assistive-technology users, you get a far more accurate picture of whether your product is accessible.

Who Owns Accessibility Compliance After Handover?

Drift sets in fast without a named owner: a content editor swaps an icon and drops the label, or a redesign breaks contrast ratios.

A handover that holds up needs three things specified upfront:

• Named ownership for accessible components. Someone is responsible for the design system's patterns staying accessible as they evolve.

• A handover package specified before the engagement ends. Documented patterns and testing procedures.

• Role-level onboarding. Designers inherit the standards that apply to their decisions (contrast, hierarchy, focus states); developers inherit theirs (semantic markup, ARIA usage, testing), so the standard survives a team change.

Without this, the cost shows up later: the same regressions get reintroduced and re-fixed on repeat.

What Compliant Product Development Requires in 2026

Compliant product development in 2026 means treating accessibility as a maintained system. One-off audits fail over time, since the standard itself keeps moving.

Operationally, that means accessibility checks live inside the tools teams already use: automated scans in CI, contrast and focus checks in the design process

Organizationally, it means:

• A named owner for accessibility

• A retesting cadence tied to releases

• Documentation that survives a team change

Teams that maintain this stop re-solving problems. They also absorb standard updates without issues.

If you're not sure where your product currently stands, our product design team offers an accessibility gap assessment to show you exactly where the gaps are and what it would take to fix them.