Develop Accessible Implementations

This intervention focuses on the actual building of accessible technology, ensuring that products are implemented in ways that support inclusive use. It involves choosing the right tools, frameworks, markup, and logic to ensure the product's backend and frontend are functionally accessible.

Role in the ENABLE Model

In the ENABLE model, Develop Accessible Implementations represents the fourth stage of pre-launch care. It transforms accessible designs and requirements into functional code that respects accessibility standards and best practices. Without accessible implementation, even the best designs remain inert.

Why Development Matters

If accessibility is neglected during implementation, it becomes baked into the product in ways that are difficult, expensive, or even impossible to fix later. Accessible development practices ensure that software is compatible with assistive technologies, supports keyboard navigation, respects user settings, and avoids creating barriers for people with disabilities.

Examples

• Use semantic HTML to reflect content structure.
• Label all form inputs with proper label elements or aria-label.
• Ensure focus management for keyboard users (e.g., modal dialogs, dynamic content).
• Use accessible component libraries or build from accessible patterns (e.g., WAI-ARIA authoring practices).
• Avoid implementing drag-and-drop, infinite scroll, or custom UI components without accessible fallbacks.

Care sounds like

“We must develop our product in a way that screen readers can understand.”
“All interactive elements must be reachable and operable by keyboard.”
“We're using semantic markup, ARIA where necessary, and testing against accessibility linting rules.”
“We're avoiding div soup and building on components that are tested for a11y.”

Neglect sounds like

“It works with a mouse -- good enough.”
“We'll fix accessibility later.”
“The screen reader can't read it? Maybe they just need a newer one.”
“Keyboard support isn't part of MVP.”
“We used a UI library that doesn't support accessibility, but it looks great.”

Real-world Scenario

A team builds a dashboard for hospital data monitoring using a modern JavaScript framework. They rely heavily on custom components and visual indicators, using <div>s for everything without semantic markup. Keyboard users can't access many controls, and screen readers don't understand the interface. Despite good design intentions, the implementation locks out users who rely on assistive technology.

Had the team developed with accessibility in mind -- using semantic HTML, accessible components, and tested markup -- they could have ensured broader access from the start, reducing the need for compensatory tools or legal complaints post-launch.

Manifestations

• Google follows its Products for All guidance to embed accessible APIs during design, not after launch, showing a commitment to accessible code from early stages.