A scan with a logo on it is not an accessibility audit. An automated scan finds roughly a third of what is wrong, and almost none of what matters most: a keyboard trap in a mega menu, a modal that does not return focus, a data table nobody can navigate by column header. This engagement combines the scan with manual testing by keyboard and screen reader, on the templates and interactions your site actually uses, and hands back findings written against the specific WCAG success criterion each one fails. You get the report whether or not you hire us to fix anything in it.
- Who this is for
- Public-sector bodies and their suppliers who have to answer a Section 508 or WCAG question in procurement, universities and non-profits with a published accessibility commitment, and any Drupal team that has been told their site fails and does not yet know where.
WCAG 2.2 and Section 508: which one applies to you
They are not alternatives, and the difference trips up procurement more than it trips up engineering.
WCAG is the technical standard, published by the W3C. Version 2.2 is the current one, and it is organised as success criteria at three levels: A, AA and AAA. AA is what almost every policy in the world points at. WCAG 2.2 added criteria that matter on real interfaces: focus that is not obscured by a sticky header, targets big enough to hit, and not requiring someone to remember information across steps of a form.
Section 508 is United States federal procurement law. It does not define its own technical rules any more: since the 2017 refresh it incorporates WCAG by reference, so a Section 508 obligation is in practice a WCAG AA obligation plus documentation and procurement duties. If you are a US federal agency, or selling to one, this is the frame your buyer uses.
Elsewhere the same standard arrives under a different name: EN 301 549 in European public procurement, the UK public sector accessibility regulations, AODA in Ontario, and the Australian DTA guidance. The technical work is the same because all of them point at WCAG. What differs is who you owe the answer to and in what format.
How the audit is run
The audit runs as separate passes, because each one finds a different class of problem.
- Automated scan. Every template and a representative sample of pages, run through axe and Lighthouse. This catches contrast, missing alternative text, form fields with no label, landmark structure and ARIA that is malformed. It is cheap, repeatable, and nowhere near sufficient on its own.
- Manual keyboard testing. Every interactive component driven with the keyboard only: tab order, visible focus, escape from menus and modals, focus returned where it came from, skip links that actually skip. This is where the failures that stop somebody using the site tend to be.
- Assistive technology testing. The key journeys (search, a form submission, a document download, the main navigation) walked through with a screen reader, to check the page makes sense when it is read rather than looked at.
We agree the page sample and the journeys with you before we start, because a report on templates nobody uses is a report nobody uses.
What you get back
One document, written to be handed to a developer or to a procurement officer without translation:
- Every finding mapped to the WCAG 2.2 success criterion it fails, at level A or AA, with the conformance level stated.
- Severity, judged by what it blocks rather than by how the scanner scored it. A keyboard trap outranks a contrast failure on a footer.
- Where it occurs (the template or component, not a list of URLs), so that one fix closes every instance rather than one page.
- The recommended fix, specific enough to be estimated, and an estimate of the effort for each.
- A prioritised order of work, so that a limited budget buys the findings that matter first.
The report is yours. You can take it to your own developers, to another firm, or back to us.
Where Drupal sites usually fail
After years of building on Drupal, the same handful of components account for most findings. Knowing where to look is most of what makes a manual audit efficient.
- Mega menus. Multi-column navigation is the single most common source of keyboard traps and of submenus that open on hover and cannot be reached any other way. We maintain WE Mega Menu, so this is a component we know from the inside.
- Forms. Labels attached by proximity rather than by markup, error messages that appear visually but are never announced, required-field indicators that exist only as colour, and multi-step forms that lose focus on each step.
- Views tables and data listings. Sortable columns built from links with no state announced, filter sets with no grouping, and tables with no header association, which turns a data table into noise for a screen reader.
- Modals, slideshows and tabs. Focus that is never moved into the dialog, never trapped inside it, and never returned. Carousels that move on their own with no way to stop them.
- PDFs and uploaded documents. Frequently the largest untreated problem on a public-sector site, and the one most often left out of scope because it is not the website. We report it either way, so the decision is made deliberately.
- Editor-created content. Headings used for size, images with decorative alternative text pasted in, links labelled "click here". These are a training and content-model problem, not a code problem, and the report says so.
Fixing what the audit finds
An audit that cannot be acted on is an expense, not an investment. There is more than one route out of the report, and we are content with any of them:
- Your team fixes it. The findings are written to be actionable by a developer who was not in the audit. We will answer questions on them at no charge.
- We fix it. Quoted at a fixed price against the findings list, with the component-level fixes done once rather than page by page. Retest is included, so you get a written statement of what now passes.
- It becomes part of a build or upgrade. If the site is due a version upgrade or a front-end rebuild, the accessibility work is cheaper folded into that than done twice.
Whichever route you take, the durable fix is usually in the content model and the component library rather than in patches: a heading structure editors cannot break, form components that are correct by default, and a mega menu that is accessible because the module is. That is how we build in the first place, on web development and quality assurance engagements, where accessibility is a build requirement rather than a late fix.
What it costs
An accessibility audit is scoped from the number of distinct templates and interactive components, not from the number of pages: a thousand pages built from twelve templates is a twelve-template audit. We agree that sample with you, then quote a fixed price for the audit itself.
Remediation is quoted separately, after the findings exist, so you are never asked to commit to fixing something nobody has measured yet. Our published engagement bands are on the pricing page: audit-and-fix work sits in the maintenance and support band, and a front-end rebuild driven by accessibility sits in the project bands.
Public-sector work behind this
Accessibility has been a delivery requirement on our public-sector and education work rather than a separate product: platforms for government bodies, agencies and universities where a procurement answer on accessibility was a condition of the contract. The sector pages collect that work (government and public sector and education and e-learning), and the individual projects are in the portfolio.
We offer the audit as a standalone engagement because clients keep asking for the findings without the build attached. If you need a formal conformance statement signed by a third party for a regulator, say so at the start: that is a different deliverable from an engineering audit, and we will tell you plainly whether we are the right firm for it.
Questions we get asked
Is Section 508 different from WCAG?
In practice, no. Since the 2017 refresh, Section 508 incorporates WCAG by reference, so meeting WCAG 2.2 level AA is what satisfies the technical side of a Section 508 obligation. What Section 508 adds is procurement and documentation duties, which are about how you buy and record, not about how the page is built.
Can you just run a scanner for us?
We can, and we would rather tell you now that it will find roughly a third of your problems. Automated tools cannot judge whether alternative text is meaningful, whether focus order makes sense, or whether a modal returns focus. If budget only allows a scan, take the scan, but do not report it as an audit.
How many pages do you test?
We scope from templates and components rather than pages. A site with a thousand pages built from twelve templates is a twelve-template audit, plus the interactive components and the key user journeys. We agree that sample with you in writing before starting.
What conformance level should we target?
AA. Every public-sector regulation we have met points at WCAG level AA, and AAA contains criteria that are not achievable on most content. If someone is asking you for AAA across a whole site, that is worth questioning before it is worth budgeting for.
Do you fix the issues as well?
Yes, quoted separately after the findings exist, with a retest included so you have a written statement of what now passes. You are equally welcome to take the report to your own team or to another firm; it is written to be read by someone who was not in the audit.
Our PDFs are the problem. Is that in scope?
We report on them, and we will tell you how large the problem is. Remediating a back catalogue of PDFs is a document production exercise rather than a Drupal one, and it is usually cheaper to publish the content as HTML than to fix the PDF. We would rather say that than quote for the wrong work.
Will you produce a VPAT or an accessibility conformance report?
Our deliverable is an engineering audit: findings against WCAG criteria with severity and fix estimates. A formal conformance statement intended to be relied on by a regulator is a different document, often expected from an independent third party. Tell us which one your buyer is actually asking for and we will be straight with you about whether we are the right firm for it.
How long does an audit take?
It is driven by the number of templates, components and journeys in the agreed sample. We give you that figure with the quote, before you commit, rather than a generic number here that would be wrong for your site either way.
We are about to rebuild. Should we audit first?
Audit the current site only if you need the findings for a procurement answer or a complaint. Otherwise put the money into the rebuild and make accessibility a build requirement, then audit the result. Fixing a site you are about to replace is the one case where this work does not pay for itself.
Migrate & Audit
Related services
Find out where you actually stand
Tell us the site and who is asking for the answer. We will scope the audit from your templates, not from a page count.