6 min read
Weekly Accessibility Reports for Your Site
Weekly accessibility reports for your site: what a good report contains, how to read it in ten minutes, and what to fix first each week.
- weekly accessibility report website
- weekly accessibility reports
- accessibility monitoring
- accessibility reports
- wcag 2.2 aa
- code fixes
A weekly accessibility report is useful only if someone reads it, understands it in ten minutes, and fixes something because of it. Most reports fail at the first step: they arrive as a long list of counts, nobody owns them, and the same items appear week after week until the report itself becomes background noise. A good weekly report has a small, fixed structure, a named owner, and a short list of actions. This article describes that structure, and a routine for using it.
What a good weekly report contains
A good report opens with what changed since last week, not with a total count. New problems first, fixed problems second, problems still open third. Each item names the page, the problem in plain words, the severity, and the fix step. A report that says "12 errors" and stops there tells an owner nothing to do. A report that says "contact form, missing label on the email field, fix by adding a label tied to the field" tells an owner exactly what to do, and who should do it.
The report should also name its scope: which pages were scanned, on what date, and against what standard. Axeazy's scan runs 98 automated checks against WCAG 2.2 AA, grouped into 14 categories, from alt text and form labels to heading structure and landmark structure. Every scan and fix is recorded with a date and time, and reports can be exported as a PDF. That dated history is what turns weekly reports into a record: last week's report beside this week's report shows what changed, and a run of reports shows whether a site is getting better or only getting new pages.
The ten minute weekly routine
Set one weekly slot, same day, same person. Open the report and read it in this order. First, new problems on the most visited templates: homepage, product or service pages, contact form, checkout or booking path. Fix those first, or assign them with a date. Second, fixed problems: confirm the fix is real by opening the page, not only by reading the report line. Third, open problems older than two weeks: either fix them, or write down why they wait, with a new date. A problem with no date and no owner is a problem that will appear in every report until someone deletes the report instead.
Fourth, check what changed on the site that week: a new plugin, a new theme setting, a new page template. New problems that arrived with a change usually trace back to that change, and fixing the change fixes the batch. Fifth, run a keyboard check of one top path: move through the contact form or checkout with a keyboard only, and note anything the scan could not see. The United States Department of Justice guidance says automated checkers can help, but a clean report does not mean everything is accessible, and a manual check paired with automated checks gives a better picture. That keyboard check is the manual half of the weekly routine.
What to fix first each week
Fix in this order. Severity first: items that block a keyboard user or hide a form label outrank items that only affect wording. Template second: a problem on a template used by a hundred pages outranks the same problem on one page. Path third: a problem on a checkout or booking path outranks the same problem on a blog post. This order keeps the weekly fix list short: three to five items, not thirty. A list of thirty items gets ignored. A list of four items gets done.
For sites with a GitHub repository, Axeazy sends fixes as a real pull request with a visible code diff that the owner or developer reviews and merges, and the next weekly scan can show the change in the code. For WordPress sites, the free plugin applies three render-time fixes, and paid plans add weekly scans and further fixes. For Shopify stores and other sites with no repo, Axeazy scans the site and gives a guided checklist with computed fix values to apply by hand, and the next weekly scan can show which checklist items were applied. Colour contrast is detected and a correct colour is calculated, but a visible colour change is never applied without owner approval, so a contrast item in a weekly report should carry an approval step, not only a fix step.
Reports for clients and teams
If you report to a client or a team, send the same structure, shortened: what changed, what was fixed, what is still open with dates, and what the client needs to approve. Clients read a one page summary. They do not read a raw scan dump. Axeazy's Agency plan covers up to ten client sites, with a white label portal, bulk scanning, and per client risk scoring, and the details sit on Axeazy's agency page. White label reports matter here, because a client should read the report as a report from their own site's work, with the fixes and dates in front of them, not as a vendor's sales page.
Keep old reports. A run of weekly reports is the record that shows effort over time: when problems appeared, when they were fixed, and when new ones arrived with a site change. That record is worth more than any single week's score, because it shows a pattern of work rather than a snapshot.
Related reading
For the monitoring plan behind weekly reports, read what to look for in accessibility monitoring, and for the ranked features in any tool, read accessibility tool features that matter most. For the buyer checklist, read accessibility tool buyer checklist.
- For the pull request workflow, read accessibility fixes as a GitHub pull request.
FAQ
How long should a weekly report take to read?
Ten minutes for a small site, if the report opens with what changed. If it takes longer, the report structure is wrong: ask for new problems first, fixed problems second, and open problems with dates third.
What if the same problems appear every week?
Either nobody owns the fix list, or the fix never landed in the code. Check one item by opening the page: if the code is unchanged, the fix was never applied, and the report is doing its job by repeating it. Assign it with a date and an owner.
Does a weekly report replace an audit?
No. A weekly report is a repeat scan with history. An audit is a person testing sampled pages and writing findings a developer can act on. Use the weekly report every week, and an audit when a template changes, when a path changes, or when a third party needs a report from a person.
Last checked: October 31, 2026 Sources: W3C WCAG 2.2; ADA.gov web guidance; Axeazy capabilities, pricing, and agency pages.
Start with Axeazy's free scan to see a dated report, then set one weekly slot and run the ten minute routine on the next report.