Keep accessibility in the maintenance routine

Adopt a practical review schedule

The schedule below is a recommendation for BuildLACCD to approve and resource. These intervals are not WCAG requirements. Increase review frequency for deadline-sensitive notices, frequently changing content or repeated failures.

Treat plugin and template updates as releases

Before changing Elementor templates, a gallery, Gravity Forms or another shared component, identify the pages and tasks it affects. Use a staging environment and preserve a recoverable version. Test representative content, not just an empty component.

• Check menus, keyboard focus, mobile reflow and any sticky content.
• For forms, test required fields, invalid input, correction and successful submission in an approved test environment.
• For galleries and media, test every control and the way focus enters and leaves the viewer.
• Run automated checks, investigate flagged items and record manual test results.

Repeat the relevant checks after deployment. A staging pass does not establish that the production configuration, cached page or embedded service works the same way.

Keep evidence that can be compared

Save the date, environment, page URLs, file versions, test method and scope. For automated scans, retain the tool and version, ruleset, raw output and any exclusions. For manual tests, record the browser, assistive technology where used, steps and observed result.

Track each confirmed issue from discovery through assignment, repair and retest. Report open barriers and affected user tasks, not only a score or percentage. A decrease in scan findings can reflect a smaller sample rather than a better website.

Use analytics to help prioritize heavily used pages, but do not exclude low-traffic content that supports important services. Review feedback and accommodation requests as additional evidence.

Maintain the guide as well as the website

Assign an owner to review this guide when WCAG guidance, authoring tools or site components change. Keep a short revision history describing substantive changes. Replace obsolete screenshots and verify source links. Record the next scheduled review in the team’s tracker.

Check the public accessibility statement against actual evidence. It should describe the scope, known limitations and a usable feedback route without claiming that a clean automated scan proves complete conformance.