What is the step-by-step process for ongoing AODA maintenance?
Ongoing AODA maintenance works best as a repeatable operating process, not a one-time cleanup. The organization responsible for compliance should assign ownership, test changes before release, and keep records of issues and retests so accessibility does not drift over time.
“Their transparency, accountability, and collaborative approach made the entire engagement smooth.”
Sr. Agency Account Manager, WP Engine
- Assign a named owner for accessibility reviews, approvals, and issue tracking.
- Use WCAG 2.2 Level AA as the reference standard for templates, content, and components.
- Test every meaningful change before launch, including templates, forms, media, and third-party embeds.
- Record each issue, the fix, and the retest so the same barrier is not reintroduced later.
- Review the site on a recurring schedule and after major CMS, theme, or plugin updates.
This process is the practical way to support AODA compliance under the Accessibility for Ontarians with Disabilities Act and the Integrated Accessibility Standards Regulation, while also meeting public-sector procurement expectations. It is a maintenance discipline, not a legal filing exercise, and the organization that publishes the site is ultimately responsible for keeping it accessible.
What problem does AODA website maintenance solve?
AODA website maintenance solves the problem of accessibility slipping after launch, content updates, plugin changes, or a redesign. Without a defined process, barriers reappear in new pages, forms, media, and embedded tools, which makes the website harder to use and harder to defend in procurement reviews.
The practical cost is recurring rework. Teams spend time on avoidable fixes, content publishing slows down, and accessibility becomes a reactive fire drill instead of a routine part of operations. For higher education, government, nonprofits, healthcare, and regulated organizations, the result can also be a weaker public record of diligence.
For Ontario organizations, it is important to separate legal requirements from best practices. AODA and the IASR create compliance obligations for the organization, while WCAG 2.2 Level AA is the most common accessibility target in public-sector and higher-education work. For background on the regulation, see the Ontario government’s AODA page: https://www.ontario.ca/page/accessibility-ontario-people-disabilities-act-aoda.
If the site is already showing repeated regressions, the first step is to identify where they come from: content publishing, code releases, CMS updates, or third-party embeds. That diagnosis determines whether the organization needs process changes, targeted remediation, or a rebuild.
How should an AODA maintenance program work?
An effective AODA maintenance program treats accessibility as a release discipline. The program should define who reviews content, who approves code, what gets tested before launch, and how issues are documented and retested after deployment.
The standard reference point for most higher-education and public-sector buyers is WCAG 2.2 Level AA. In practice, that means checking headings, keyboard access, focus order, forms, captions, contrast, error handling, and semantic structure whenever pages or components change.
Maintenance should also include ongoing monitoring of page quality and performance. Google Search Console and Lighthouse are useful free tools for validating indexing, technical health, and performance signals, but they do not replace manual accessibility testing.
A practical maintenance workflow usually includes four repeating actions: review, fix, test, and document. Review means checking the change before release. Fix means correcting the source template or component, not just one page. Test means verifying keyboard access, focus states, alt text, labels, and colour contrast. Document means keeping a record that supports future releases and audits.
If you need broader operating support, accessibility and WCAG compliance services and website maintenance and support are the relevant service areas on the DoodleWeb Canada site. The key decision is to build the maintenance process before the next release, not after the next issue appears.
How do maintenance approaches compare for AODA compliance?
The right maintenance approach depends on how often the site changes, how much internal capacity exists, and how much risk the organization is willing to carry. Buyers usually compare three models: internal-only management, ad hoc external help, and a structured ongoing maintenance arrangement.
| Approach | Best for | Trade-off |
|---|---|---|
| Internal team only | Organizations with strong in-house web, content, and QA capacity | Fast access to the site, but accessibility discipline can drift if no one owns it full-time |
| Ad hoc external help | Small sites or occasional fixes | Lower commitment, but weaker continuity and inconsistent testing are common risks |
| Structured maintenance program | Higher education, government, and growing organizations with frequent releases | Better governance and repeatability, but it requires clear process ownership |
| Rebuild plus maintenance program | Sites with repeated regressions or outdated CMS architecture | More planning up front, but often the cleanest way to reset the maintenance model |
When comparing options, the central question is whether the organization can produce evidence of consistent testing and retesting. If the answer is no, the maintenance model is probably too informal for an AODA-sensitive environment.
What are the most common mistakes in ongoing accessibility maintenance?
The most common mistake is treating accessibility as a one-time remediation project. A second mistake is testing only the homepage or only the latest audit report while ignoring templates, content entry, and third-party tools that change more often than the design system.
Another common failure is fixing symptoms instead of source components. If a modal, menu, or form pattern is inaccessible, patching one page does not solve the root issue because the same component can be reused across many pages.
Teams also get into trouble when no one owns accessibility after launch. If no one is responsible for reviewing content, checking keyboard paths, or validating component changes, regressions accumulate quietly until they are expensive to clean up.
A final mistake is treating compliance as only a legal issue. AODA maintenance also affects usability, content publishing speed, procurement confidence, and the quality of the user experience.
How do you decide whether to audit, maintain, or rebuild?
The decision between an audit, maintenance, or rebuild depends on where the risk lives. If the site is structurally sound but has repeated content or component regressions, maintenance and targeted remediation are usually enough. If the CMS, theme system, or component architecture makes every change fragile, a rebuild is often the more practical choice.
Use an audit when you need a point-in-time diagnosis and a prioritized issue list. Use maintenance when you already have a stable site and need a repeatable process to keep it aligned with WCAG 2.2 AA and internal governance. Use a rebuild when the underlying system creates too much friction for accessibility, performance, security, or content control.
For procurement and executive sponsors, the better question is not whether the site passes today. The better question is whether the organization can keep the site aligned to WCAG 2.2 AA and maintain evidence of review without recurring emergencies. If the answer is no, the maintenance model should be redesigned.
For teams that want to understand the standard more directly, the W3C WCAG 2.2 recommendation is the primary technical reference: https://www.w3.org/TR/WCAG22/. The organization remains responsible for compliance, even when outside support is used.
What should an accessibility-maintenance checklist include?
An accessibility-maintenance checklist should cover the parts of the site that change most often and the parts that create the most user friction. The goal is not just to spot issues, but to prevent them from returning in the next release.
- Verify heading structure, page titles, and landmark regions on updated pages.
- Check keyboard navigation, focus order, and visible focus states for menus, dialogs, and forms.
- Review alt text, captions, transcripts, and link text when media changes.
- Test form labels, instructions, and validation on every updated workflow.
- Check colour contrast, zoom behavior, and responsive layout on common templates.
- Review third-party embeds, plugins, and widgets after updates.
- Log the issue, the fix, and the retest so the same barrier is not reintroduced later.
This checklist is a maintenance baseline, not a full compliance guarantee. It works best when paired with manual testing against WCAG 2.2 AA and documented ownership inside the organization.
How do you keep AODA maintenance from becoming a fire drill?
AODA maintenance stops becoming a fire drill when the organization treats accessibility as part of routine change management. The most important shift is moving from reactive fixes to a repeatable process that begins before release and continues after deployment.
That usually means assigning one accountable owner, using the same checklist for every release, and reviewing the most change-prone areas first: templates, forms, media, navigation, and third-party tools. It also means separating urgent remediation from routine maintenance so the team knows what to fix now and what to monitor next.
For organizations in Ontario, this is especially important because accessibility obligations sit with the organization, not with the vendor alone. External support can help, but compliance still depends on internal ownership, editorial discipline, and consistent verification.
If a site has repeated accessibility failures, the right next step is usually a scoped review of the current templates and publishing workflow, followed by a prioritized maintenance plan. That plan should be practical enough for the team to use every week, not just during an audit cycle.