A customer has used the same application with a keyboard and screen reader for two years.
Then a frequently used workflow is redesigned.
The new version looks cleaner. Instead of opening a separate page, the task now happens inside a modal. Functional testing confirms that the modal opens, the form submits and the correct data is saved.
For the customer, however, the workflow has effectively stopped working.
Keyboard focus remains on the page behind the dialog. The screen reader does not announce what opened, and Tab eventually reaches controls that are visually hidden underneath the modal.
The business functionality is still there. The application has simply become harder to operate for someone who does not interact with it in the way the development team normally does.
This is how accessibility often deteriorates: not because accessibility was deliberately removed, but because the product changed without accessibility behavior being rechecked.
Accessibility maintenance is the ongoing work of making sure that new features, interface changes, content and shared components do not introduce barriers that prevent people from continuing to use an application effectively.
An accessibility review at launch cannot guarantee that the product will remain accessible a year later. Applications evolve continuously, and accessibility needs to be maintained alongside that evolution.
The current Web Content Accessibility Guidelines (WCAG) 2.2 organize accessibility around four principles: content and interfaces should remain perceivable, operable, understandable and robust. Those qualities have to survive product change, not merely exist when the first version ships.
For Levelworks, accessibility maintenance primarily supports User Friendly & Delightful, Compatible and Tested App Health.
Major redesigns are obvious moments to reconsider accessibility.
Smaller changes are often more dangerous because teams do not think of them as accessibility changes.
A regression can appear when someone:
Consider a standard HTML button.
The browser already understands what it is, exposes appropriate semantics to assistive technologies and provides expected keyboard behavior.
Replace it with a styled <div> that responds to a mouse click and the visible result may look identical, while keyboard users and assistive technologies receive something very different.
The WAI-ARIA Authoring Practices Guide exists partly because custom controls such as dialogs, menus, tabs and grids require deliberate accessibility behavior. If teams build custom interaction without preserving those behaviors, the interface can become less accessible even though the new component looks better.
Accessibility maintenance therefore starts with recognizing which product changes can alter the way users perceive or operate the interface.
A defect in one screen affects one workflow.
A defect in a shared component can affect dozens.
Suppose the application's form component originally connects each visible label correctly to its input. During a redesign, the component is rewritten and the visible label remains, but the programmatic association disappears.
Every form using the new version inherits the defect.
The same risk applies to:
Shared components should therefore carry accessibility requirements just as clearly as visual specifications.
For example:
Component
Accessibility behavior to preserve
Button
Accessible name, keyboard activation, visible focus
Input
Programmatic label and understandable errors
Dialog
Focus movement, keyboard containment, close behavior
Tabs
Roles, selected state and keyboard navigation
Alert
Important updates announced appropriately
Menu
Logical keyboard interaction and meaningful labels
When a shared component changes, accessibility regression testing should happen at the component level before the change spreads through the application.
This is one area where a maintained design system can substantially reduce accessibility risk: teams can solve common behavior once and reuse it rather than recreating it independently throughout the product.
[Internal Link: “UX Maintenance: Why User Experience Needs Maintenance Too”]
A large number of accessibility problems become obvious when you try to use the application without a mouse.
W3C recommends keyboard evaluation because some users rely entirely on keyboards or keyboard-equivalent assistive technology. Important functionality should remain reachable and operable, with a logical focus order and a focus indicator users can actually see.
See: W3C Easy Checks – Keyboard Access and Visual Focus
After an interface change, test whether a user can:
This type of testing is particularly important after adding custom interactive controls.
A modal, for example, should not merely open visually. Keyboard focus should move somewhere appropriate inside it, users should be able to operate its controls, and focus should return sensibly after the dialog closes.
The WAI-ARIA dialog pattern documents expected behavior for this kind of component.
A screenshot test will never detect that focus remained behind the modal.
Keyboard regression testing can.
Accessibility can break even when the visual interface barely changes.
A refactor might preserve exactly the same layout while altering the underlying structure exposed to assistive technology.
For example:
That is why screen-reader checks remain necessary for important workflows and significant interface changes.
Apple recommends testing applications with VoiceOver and checking whether important elements are reachable, correctly described and encountered in a useful order. Apple: Supporting VoiceOver in Your App
Android's accessibility guidance similarly recommends manual testing with TalkBack alongside automated accessibility checks. Android Developers: Test Your App's Accessibility
The objective is not to test every release exhaustively with every assistive technology.
Instead, identify the workflows and components whose behavior changed, then test those changes with the interaction methods most likely to reveal regression.
Modern web applications frequently update the interface without navigating to a new page.
A drawer opens. A form appears. An item is deleted. Validation errors arrive after submission. A background operation finishes and displays a success message.
Sighted mouse users may immediately notice these changes.
Keyboard and screen-reader users may not.
Suppose someone selects Edit billing address and a new panel appears elsewhere on the page.
If focus remains on the trigger and nothing announces the new content, the user may have no clear indication of what changed or where to go next.
Accessibility maintenance should therefore review what happens when interface state changes:
ARIA roles, states and live regions can help communicate dynamic behavior, but they should be used to implement an understood interaction pattern rather than added mechanically.
An application can become less accessible even when engineering ships nothing.
A content editor might upload an important image without a meaningful text alternative. A video might be published without captions. Instructions might suddenly rely on color alone.
This is especially relevant for applications where non-developers can publish or change content.
Accessibility maintenance therefore needs to account for:
W3C's WCAG 2 Overview provides the broader requirements these practices support.
Where a CMS is involved, useful maintenance may include accessible authoring guidance or validation that prevents common mistakes rather than expecting every content contributor to remember the entire standard.
Accessibility automation is valuable because it can repeatedly inspect the application every time the interface changes.
Depending on the testing tools used, automated checks can identify problems such as:
That makes automation well suited to CI pipelines and component tests.
The important limitation is that automated testing cannot determine whether the overall experience is accessible.
W3C explicitly notes that evaluation tools cannot determine accessibility on their own and that human judgment remains necessary. W3C: Evaluating Web Accessibility Overview
A tool might confirm that an image contains alternative text without knowing whether the text is useful.
It might verify that a button has a name while being unable to determine whether that name explains the action clearly in context.
It cannot reliably judge whether completing a complicated workflow with a keyboard is understandable.
Use automation to catch predictable regressions quickly, then use targeted manual testing for interaction quality.
Running a complete accessibility audit after every minor product release is rarely practical.
Ignoring accessibility between annual audits is not effective either.
A better approach is proportional testing.
Change
Appropriate accessibility check
Text or copy change
Structure, meaning, links
New form
Labels, errors, keyboard flow
New modal
Focus, keyboard behavior, announcement
New shared component
Full component accessibility regression
Navigation redesign
Keyboard order, landmarks, screen-reader structure
Major workflow change
End-to-end assistive-technology testing
Visual-system change
Contrast, focus visibility, resizing
Major release
Broader representative accessibility review
This gives teams a sustainable rule:
The greater the potential accessibility impact of the change, the deeper the accessibility regression testing should be.
That model is more useful than treating every ticket identically.
An application can contain individually accessible controls and still have an inaccessible task.
Imagine a long form where every field has a correct label.
Submission fails because three fields contain errors.
The error messages appear correctly beside those fields, but focus remains on the Submit button at the bottom of the page. A screen-reader user receives no clear indication that errors appeared much earlier in the form.
The controls technically pass several accessibility checks.
The workflow remains difficult.
That is why important accessibility testing should follow real tasks.
For a B2B application, these may include:
Apple's accessibility-testing guidance recommends starting with the important tasks users perform and evaluating those tasks using relevant accessibility features. Apple: Performing Accessibility Testing for Your App
The same principle applies more broadly.
Users experience journeys, not isolated DOM elements.
[Internal Link: “Regression Testing: How to Update an App Without Breaking Existing Features”]
Change-based regression catches many problems.
It can still miss accumulated drift.
Perhaps one navigation inconsistency was introduced in January, another in March and a third in June. Individually, each release appeared acceptable. Together, the product has become difficult to navigate with a screen reader.
Periodic broader evaluation helps identify this accumulated accessibility debt.
W3C's WCAG Evaluation Methodology (WCAG-EM) provides a structured approach for evaluating a representative sample rather than necessarily testing every possible page.
A periodic review might include:
The purpose is not simply producing another audit document.
It is checking whether the accessibility level the organization believes it has is still reflected in the live product.
Standards and specialist testing are essential, but they cannot completely reproduce real usage.
W3C recommends involving people with disabilities in accessibility evaluation because actual users can reveal practical problems that technical conformance checks may miss. W3C: Involving Users in Evaluating Web Accessibility
This can be especially valuable when:
The aim is not to ask one participant to certify the entire application.
Different people use different assistive technologies and strategies.
User evaluation instead provides another kind of evidence: whether real people can accomplish important tasks using the experience the team has built.
Older applications can contain large accessibility backlogs.
A sensible remediation strategy should distinguish between minor defects and barriers that stop users from completing essential work.
For example:
Problem
User impact
Priority
Checkout cannot be completed with keyboard
Task blocked
Critical
Dialog cannot be navigated with screen reader
Major workflow blocked
Critical
Important button has unclear accessible name
Action difficult to understand
High
Focus indicator difficult to see
Navigation difficult
High
Minor heading inconsistency
Structure less clear
Medium
This does not mean lower-priority WCAG problems can simply be ignored.
It means remediation should begin where users experience the most serious barriers while the wider backlog continues to be addressed systematically.
A useful question is:
What important task becomes difficult or impossible because of this issue?
That keeps accessibility maintenance connected to real usability rather than reducing it to a count of violations.
If missing labels repeatedly appear throughout the application, fixing them individually may not be enough.
The real problem might be the shared form component.
If every newly introduced dialog has keyboard problems, the organization may need a standard dialog pattern rather than another local patch.
Recurring accessibility defects are often signals that maintenance needs to move upstream.
Possible structural fixes include:
The strongest accessibility fix is often the one that prevents the next occurrence.
Accessibility becomes difficult to maintain when it belongs only to a specialist audit performed after development is complete.
A healthier model makes the team changing the application responsible for preserving accessible behavior.
For relevant interface work, completion criteria might include questions such as:
Not every question applies to every change.
The principle is simply that accessibility should be checked where it can be broken.
That keeps the feedback loop short and prevents defects from spreading through subsequent releases.
Accessibility is not a property an application permanently earns at launch.
Every meaningful interface change has the potential to alter how somebody navigates, understands or operates the product.
A new modal can disrupt focus.
A refactored component can lose semantics.
A content change can remove an alternative description.
A design-system update can either eliminate the same accessibility problem across the product or distribute it everywhere.
For Levelworks, this is why accessibility maintenance supports User Friendly & Delightful, Compatible and Tested App Health.
The application should remain usable not only for the interaction methods assumed during development, but also for people who depend on keyboards, screen readers, zoom, system accessibility settings or other assistive technologies.
Maintaining that condition does not require turning every release into a full accessibility audit.
It requires something more practical: identify changes that can affect accessibility, test those risks close to development, maintain shared components carefully, periodically assess the wider application, and fix recurring issues at their source.
The useful maintenance question is therefore not:
“Was this application accessible when we launched it?”
It is:
“After everything we have changed since then, can the people who could use it before still use it now?”
