Accessibility is the work of making a product usable by people with different ways of seeing, hearing, moving, reading, and interacting. For a web application, that work reaches beyond color contrast. It includes navigation, forms, focus, error recovery, dynamic updates, documents, and the third-party tools embedded in important journeys.
WCAG 2.2 provides testable accessibility criteria, and W3C recommends it for current accessibility efforts. The criteria are a technical reference, not a universal legal conclusion. A product’s applicable legal and contractual obligations need separate assessment for its context.
Consider an illustrative customer portal where people sign in, review invoices, update details, and contact support. A barrier in authentication can prevent access to every otherwise well-designed screen. This guide therefore organizes accessibility around complete tasks, with practical design, engineering, testing, and maintenance decisions rather than a last-minute list of cosmetic fixes.
Key takeaways
- Evaluate complete user journeys, including authentication, errors, and third-party widgets.
- Prefer semantic native controls and verify keyboard, focus, and screen-reader behavior.
- Use automated checks as one part of testing, with manual and user testing for gaps.
- Treat accessibility findings as product defects with owners, evidence, and regression checks.
Set a clear scope and an accountable owner
Identify the product areas, user journeys, platforms, and content types included in the work. A public website, authenticated application, downloadable report, and embedded payment flow can each introduce barriers. A narrow audit should say what it covers rather than imply that every part of the service has been assessed.
Agree on the technical target with the responsible stakeholders. WCAG levels and criteria provide a shared reference, but the team also needs practical acceptance criteria for the product’s interactions. Keep legal interpretation with qualified advisers where it is relevant.
Assign ownership across design, engineering, content, quality assurance, and procurement. Accessibility cannot be delegated entirely to the person who runs a scanning tool. Each role controls decisions that affect the experience.
Prioritize by impact and reach. An inaccessible sign-in form or checkout can block a core task, while a minor issue in rarely used content may have a different urgency. Use severity to sequence work without treating lower-priority barriers as permanently acceptable.
Start with semantic structure and useful content
Use headings to express the page’s organization, landmarks for major regions, and links or buttons according to the action they perform. A clickable visual element should have the appropriate semantics and interaction behavior rather than relying on a mouse event attached to a generic container.
Write labels that explain purpose. Repeated links named learn more may be ambiguous when encountered out of context. Form labels should remain available when a user enters data, and instructions should not depend only on position, shape, or color.
Provide text alternatives according to an image’s role. A decorative mascot may need to be ignored by assistive technology, while a chart needs an explanation of the information it conveys. Repeating nearby text in every image label can create unnecessary noise.
Review content as part of usability. Clear language, meaningful headings, and concise instructions help people navigate complex tasks. Accessibility is not achieved by adding hidden labels while leaving visible explanations confusing or incomplete.
Make keyboard navigation a normal test path
Complete the core task without a mouse. Move through navigation, forms, dialogs, menus, and custom controls. Check that focus is visible, order follows the task, and every required action can be reached and performed.
Pay attention to components that capture or move focus. A dialog should provide an understandable entry and exit path. Closing it should return the user to a sensible location. A menu or autocomplete should not leave keyboard users trapped or uncertain about the active option.
Avoid removing focus outlines without a clear replacement. Test focus against both light and dark themes and over different surfaces. Sticky headers, cookie banners, and floating controls should not hide the active element while the user navigates.
Document keyboard behavior for custom components and verify it against an appropriate interaction pattern. The W3C ARIA Authoring Practices Guide is a useful reference, but examples still need testing in the actual application and supported browser-assistive-technology combinations.
Design forms that help users recover
Associate labels and instructions with their controls. Explain required information, expected formats, and unusual constraints before submission where that helps. Do not rely on placeholder text as the only label because it disappears when the user enters a value.
When validation fails, identify the problem in language the user can act on. Preserve valid input, connect field errors to the relevant controls, and provide an overview when several issues need attention. Avoid a generic error at the top of a long form with no indication of where to go next.
Test asynchronous validation and submission states. A user should know when work is in progress, when it completes, and when a retry is needed. Disable duplicate consequential actions appropriately without making the interface appear permanently unresponsive.
Review authentication and account recovery as forms, not special exceptions. Support the tools people use to manage credentials and avoid unnecessary memory or transcription demands. A person who cannot sign in cannot benefit from accessibility improvements elsewhere in the product.
Support zoom, reflow, and adaptable layouts
Test enlarged text and browser zoom with realistic content. Check whether labels overlap, controls disappear, or fixed-height containers cut off instructions. A layout that works at its original screenshot dimensions may fail when the user changes how content is displayed.
Allow content to reflow in a sensible order on narrower viewports. Complex data tables may need a deliberate responsive approach, but ordinary paragraphs, forms, and actions should not require unnecessary horizontal movement. Verify the complete task rather than only the page header.
Use flexible spacing and dimensions where possible. Long names, translated labels, and user-generated content expose the same rigid layout assumptions that affect zoom. Shared components should be tested with these cases before being adopted across the product.
Keep important actions associated with their context. A sticky control can help, but it can also cover content or consume much of a small viewport. Test its behavior at zoom and with the on-screen keyboard so the convenience does not become a barrier.
Use color, motion, and media deliberately
Check text and interface contrast in actual states and themes. Disabled controls, placeholder text, borders, charts, and focus indicators can be overlooked when teams test only the main body text. Use labels or patterns alongside color where users need to distinguish status or meaning.
Give motion a purpose and respect user preferences. Decorative animation should not make reading or completing a task difficult. Provide appropriate control over moving content and avoid effects that create unnecessary discomfort or distraction.
For media, plan captions, transcripts, and other alternatives according to the content and technical requirements. An automated caption file may need review for terminology, speaker changes, and meaning. The media player itself also needs usable controls.
Design data visualizations with an accessible explanation or alternative representation. A chart’s color palette is only one part of the problem. Users need to understand the trend, compare values, and access the information required for the task without depending on one visual presentation.
Make dynamic interfaces communicate their state
Single-page applications can change content without a full document navigation. Ensure that users understand when a view changes and where they are. Update titles and manage focus deliberately when the interaction requires it rather than leaving the user at an unrelated point in the page.
Communicate important status changes in a way assistive technology can perceive without announcing every minor update. A completed upload or validation error matters; a rapidly changing decorative counter may not. Excessive announcements can be as disruptive as missing ones.
Test loading, empty, error, and partial-result states. These states often receive less design attention than the successful screen, yet they are where users most need clear guidance. A spinner without an understandable status or recovery path can leave someone waiting indefinitely.
For chat and AI features, consider how streamed text is presented. Constantly announcing each fragment can make the response difficult to follow. Provide a stable reading experience, clear completion, and accessible controls for stopping, copying, or reviewing the result.
Combine automated, manual, and user testing
Automated tools can identify certain structural and contrast problems efficiently. Integrate useful checks into development and release workflows, and make failures actionable. Do not treat a clean scan as proof that the application is accessible.
Manual testing should include keyboard navigation, screen-reader use, zoom, content review, and complete journeys. Use a defined set of supported environments and document what was tested. A component can behave differently when combined with a particular browser and assistive technology.
Involve people with relevant access needs where feasible, particularly for important or unfamiliar workflows. Their experience can reveal barriers that a checklist misses. Plan sessions respectfully, compensate participants appropriately, and avoid expecting one person to represent every disability or interaction preference.
Record findings with reproduction steps, expected behavior, impact, and evidence. This helps teams fix the underlying problem and verify the result. A vague issue named improve accessibility is difficult to prioritize and easy to close without resolving the actual barrier.
Include third-party tools and documents
The customer experiences the entire journey, including embedded payment forms, authentication, maps, chat widgets, and downloadable reports. Review these components during procurement and integration rather than assuming a vendor’s general claim covers your configuration.
Test transitions into and out of embedded content. Focus, labels, error handling, and return navigation can fail at the boundary even when each component appears usable in isolation. Have a fallback or support path for essential tasks where a dependency has an unresolved barrier.
Review generated documents and emails. A web portal may be accessible while its invoices or exported reports are difficult to read with assistive technology. Preserve structure and meaningful content in the formats users actually receive.
Keep vendor limitations visible with an owner and a plan. If the team cannot fix a component directly, it still needs to manage its impact on customers. Accessibility responsibility does not disappear at the edge of the repository.
Build accessibility into ongoing delivery
Add accessibility behavior to design acceptance criteria and component documentation. Review important changes in context, and keep regression checks for defects that have already affected users. Shared components can distribute improvements widely when their behavior is well maintained.
Train teams through the actual product rather than abstract rules alone. Demonstrating a blocked checkout or confusing focus transition can make the impact clear. Give developers and designers practical ways to test their work during implementation.
Review accessibility after major features, redesigns, and third-party changes. Keep an accessible feedback route so users can report barriers and receive help. The durable goal is a product that continues to support complete tasks as it evolves, with evidence and ownership behind accessibility claims instead of relying on a one-time audit or a badge.
Keep the support team involved. A report from someone unable to complete a task should include a practical assistance path while the defect is investigated. Record the barrier without requiring the person to disclose more personal information than is needed to understand and resolve it.
Frequently asked questions
Does passing an automated scan mean WCAG conformance?
No. Automated tools cover only part of the evaluation. Manual assessment of interactions, content, and complete processes is necessary, and the scope of any conformance claim must be understood. Use scans to catch useful classes of defects without treating them as a complete verdict.
Should we add ARIA to every component?
No. Prefer native semantics where they provide the needed behavior. Use ARIA deliberately for cases that require it, and implement the corresponding interaction pattern. Incorrect ARIA can make a component more confusing rather than more accessible.
Is dark mode an accessibility solution?
It can be a useful preference, but it does not replace contrast, keyboard, semantics, reflow, or other accessibility work. Test each theme independently, including focus and error states. Users should have a coherent experience in the mode that works for them.
How should a team start fixing an existing application?
Audit the highest-value complete journeys, identify barriers that block completion, and fix shared causes where possible. Establish a technical target, owners, and verification process. Combine immediate repairs with component and workflow improvements that prevent the same problems from recurring.
Working through this in your product?
We can help you turn these decisions into a practical plan and working software.
Accessible product design and developmentTalk to the team