Build Accessibility Into the Product Before It Becomes Rework

Accessibility is often treated as a final audit. A team builds the product, runs an automated scan and tries to repair the visible failures before launch.

That approach misses the decisions that are hardest to fix later. A flow may require a mouse. A form may rely on colour. A component may have no meaningful keyboard order. A video may have no plan for captions.

An accessibility framework places accessibility inside requirements, design, development, content and testing.

TL;DR — Read this first

What it is

An accessibility framework defines how a digital product will support people with different visual, hearing, motor, cognitive and speech needs.

Why it matters

It reduces exclusion, improves product quality and prevents expensive fixes after patterns and components are already established.

Use it when

Use it while defining flows and components, not only before launch.

What you receive

Accessibility goals, applicable standards, component requirements, content rules, test methods, ownership and issue handling.

Important limit

A checklist or automated scan cannot prove that the full experience is accessible.

What is an accessibility framework?

An accessibility framework is the product's operating approach for preventing and finding barriers. It explains which standards apply, how requirements enter the backlog, who owns them and how the experience is tested.

For web products, WCAG 2.2 is an important reference. It organises requirements around four principles: perceivable, operable, understandable and robust.

Accessibility is about complete tasks

A page can pass several automated checks while a person still cannot complete the task.

The framework should focus on journeys such as creating an account, paying, booking, searching, recovering access and contacting support. Each journey should work with relevant assistive technologies and alternative modes of interaction.

The four practical areas

Perceivable

Information must be available in forms users can perceive. This includes text alternatives, captions, sufficient contrast and content that adapts when zoomed or reformatted.

Operable

Users must be able to navigate and act without being trapped by a device or interaction method. Keyboard use, focus order, target size and time limits matter.

Understandable

Language, navigation, labels, instructions and errors should be clear and predictable.

Robust

The product should expose correct structure, names, roles and states so browsers and assistive technologies can interpret it reliably.

Accessibility begins in the requirements

• Define keyboard behaviour for interactive components.
• Require visible and logical focus.
• Specify labels, instructions and error messages.
• Plan text alternatives for meaningful images.
• Include captions and transcripts where media is used.
• Avoid relying on colour, shape or position alone.
• Support zoom, reflow and responsive text.
• Provide enough time or a way to extend it.

These requirements are easier to implement when they exist before design and code are complete.

Design systems can prevent repeated barriers

Shared components such as buttons, dialogs, forms, navigation and notifications appear throughout the product. When these components are accessible, the benefit scales. When they are flawed, the barrier also scales.

The framework should define accessible states, keyboard interaction, labels, errors and test evidence for each reusable component.

Content is part of accessibility

Accessible technology can still carry confusing content.

• Use descriptive headings and link text.
• Write labels that match the user's task.
• Explain errors and how to fix them.
• Avoid unnecessary jargon.
• Structure long pages so they can be scanned.
• Provide alternatives for visual or audio-only meaning.
• Keep instructions close to the relevant control.

Automated and manual testing

Automated tools can find issues such as missing labels, some contrast failures and invalid markup. They cannot judge the full meaning, reading order, clarity or usability of a journey.

• Keyboard-only testing.
• Screen reader testing on priority journeys.
• Zoom and reflow testing.
• Colour and contrast review.
• Focus order and visible focus.
• Form labels, errors and recovery.
• Touch target and mobile interaction.
• Content and cognitive clarity review.

Testing with people who use assistive technology provides evidence that tools and internal reviewers cannot replace.

Legal requirements vary

Accessibility laws and standards differ by country, sector and product. The framework can identify questions and relevant standards, but it should not present itself as legal advice.

For a global product, the team may choose a strong common baseline and then confirm local obligations with qualified advisers.

What information should go into IdeaClarify?

• Product format, platforms and target markets.
• User groups and priority journeys.
• Content types, media and complex interactions.
• Current design system and components.
• Known accessibility requirements or contracts.
• Development stack and testing tools.
• Team roles and release process.
• Existing barriers, audits or user feedback.

The report should prioritise requirements by journey and component instead of producing a detached standards list.

Worked example: a public appointment booking service

A local service lets residents book appointments, upload documents and receive reminders. Many users access it on mobile devices, and some use screen readers or keyboard navigation.

Priority journeys

Searching for a service, selecting a time, completing the form, uploading a document and changing a booking are treated as complete accessibility journeys.

Component requirements

The date picker must work by keyboard and expose the selected date. Errors must be announced and linked to the relevant field. Status cannot rely only on colour.

Testing

Automated checks run in development. Each release receives keyboard and screen-reader testing on critical flows. Periodic user testing is planned. The report does not claim legal conformity without a proper assessment.

What an Accessibility Framework report should produce

• Accessibility goals and target baseline.
• Priority user journeys.
• Requirements by design, content and component.
• Keyboard and assistive technology behaviour.
• Automated and manual test plan.
• Issue severity and remediation workflow.
• Ownership across product, design, engineering and content.
• Release evidence and known limitations.
• User testing and feedback plan.
• Legal questions requiring confirmation.

What an accessibility framework cannot prove

Accessibility is experienced by people in context. A document cannot prove that every user can complete every task.

The framework should lead to implementation, testing and user feedback. Conformance claims require careful evidence and, where appropriate, specialist assessment.

Common accessibility mistakes

Relying on an automated score

The score misses many interaction, meaning and usability barriers.

Adding accessibility after visual design is final

The team repairs symptoms instead of choosing accessible interaction patterns.

Testing one page instead of a journey

Users may navigate the page but fail at a dialog, error or external step.

Treating accessibility as one person's job

Product, design, content, engineering and QA all make decisions that affect access.

Using overlays as the main solution

An added layer cannot reliably repair inaccessible structure and interaction logic.

How this phase connects with other IdeaClarify phases

Personas and research can identify user needs, but should avoid stereotypes. UX Flow shows the journeys that require access. PRD and design requirements make accessibility buildable.

QA Framework includes manual and automated checks. Launch Readiness records unresolved barriers and release decisions. Customer Service Playbook should provide accessible support alternatives.

Creating an accessibility checklist in a chat window vs IdeaClarify

A chat tool can list WCAG topics. The result may not connect them to the product's actual journeys, components and team workflow.

IdeaClarify should ask how people use the product, which interactions are complex and how releases work. The report should translate accessibility into requirements, owners and evidence.

Frequently asked questions

Does accessibility only concern screen readers?

No. It includes visual, hearing, motor, cognitive and speech needs, and many situational limitations.

Is WCAG AA always the legal requirement?

Not in every context. WCAG is widely used, but legal obligations depend on geography, sector and product. Confirm them separately.

Can accessibility improve usability for everyone?

Often yes. Clear labels, keyboard support, captions and understandable errors benefit many users beyond those with a recognised disability.

When should user testing happen?

Early prototypes can be tested, and key journeys should be tested again as implementation changes. It should not be postponed until the final release.

Can students use this framework?

Yes. They can use it to explain how inclusive requirements and testing would be built into a case-study product.