Website Accessibility Audit Services (WCAG)

WCAG is the widely used technical standard for web accessibility. WCAG 2.2 (opens in a new tab) organizes its requirements under four principles: content must be perceivable, operable, understandable and able to work reliably with different browsers and assistive technologies. Each requirement is a testable success criterion with a conformance level of A, AA or AAA.

Level AA is the usual target in laws, procurement and contracts. Level A is the minimum, and AAA is rarely required for a whole site because some criteria cannot be met for all content. The WCAG overview (opens in a new tab) explains the structure, and the Techniques for WCAG (opens in a new tab) describe how developers can meet each criterion.

WCAG 2.2 adds criteria on topics such as focus visibility, target size and accessible authentication, which matter for modern interfaces. If a contract names an older version, confirm which version is expected.

Accessibility is both a legal and a practical concern. The W3C sets out the business case for digital accessibility (opens in a new tab), including wider audience, better usability for everyone, improved search and brand benefits, and reduced legal risk.

• You have received a complaint, demand letter or procurement question about accessibility.
• You are preparing a redesign or replatform and want to avoid building in barriers.
• A customer, government client or partner requires a conformance report.
• You want a baseline before committing to remediation work.

The W3C’s WCAG-EM evaluation methodology (opens in a new tab) describes a repeatable way to scope, sample and report an evaluation. Reputable auditors follow something similar:

1. Define scope. Which sites, apps and domains, target level (usually AA) and version of WCAG.
2. Choose a sample. A site with thousands of pages cannot be fully tested, so the auditor selects representative templates and key journeys, such as sign-up, checkout and forms, plus any page types unique to your site.
3. Run automated checks. Tools quickly find missing text alternatives, contrast failures and markup errors.
4. Test manually. A person navigates by keyboard only, uses a screen reader, zooms in, checks focus order, form errors, dynamic content and media captions.
5. Record findings. Each issue is tied to a success criterion, shown with a screenshot or code snippet, and rated.
6. Report and brief. A written report and a walkthrough for designers, developers and content owners.

For a quick self-check before engaging an auditor, the W3C’s Easy Checks (opens in a new tab) describe simple first reviews you can run yourself.

• Text and contrast: low-contrast text and controls, and text that cannot be resized without losing content.
• Keyboard access: menus, carousels or modals that cannot be reached or closed without a mouse, and missing or hidden focus indicators.
• Forms: inputs without programmatic labels, unclear error messages, errors identified by color alone.
• Images and media: missing or unhelpful alternative text, videos without captions or transcripts.
• Structure: skipped headings, missing landmarks, and custom widgets without correct roles. The ARIA Authoring Practices Guide (opens in a new tab) describes the expected behavior for patterns such as tabs and dialogs.
• Third-party content: chat widgets, cookie banners and embedded players that bring their own barriers.

An audit only helps if findings are fixed. Good reports rate each issue by severity and suggest the fix, so teams can start with barriers that block core tasks. Remediation usually runs in layers: fix shared components and templates first, because one change repairs many pages; then individual page content; then documents such as PDFs.

After fixes, ask for a re-test of the failed items and a confirmation of what now passes. Where appropriate the auditor can help draft an accessibility statement that honestly lists remaining gaps and a contact route for users. Build accessibility into future releases through design systems and automated checks in your pipeline, and consider design system development so the fixes persist. For ongoing quality, software testing and QA can include accessibility checks in each release.

• Retail and e-commerce: testing checkout and account flows by keyboard and screen reader, where a single inaccessible payment step blocks a sale.
• Banking and insurance: auditing online forms, calculators and document uploads for labeling and error handling.
• Education: reviewing course platforms, video content and downloadable materials for captions and structure.
• Government suppliers: producing evidence for procurement questionnaires that ask for conformance details.

These are illustrative examples of where audits typically apply, not Kramate client results.

Accessibility law differs by country and sector, and a WCAG audit is evidence, not legal advice. The W3C maintains an overview of web accessibility laws and policies (opens in a new tab) around the world. Confirm obligations with legal counsel.

• USA: the Americans with Disabilities Act is applied to websites, and the Department of Justice publishes guidance on web accessibility and the ADA (opens in a new tab). Federal agencies and their contractors follow Section 508, and many state laws add requirements.
• UK: the Equality Act 2010 applies to service providers, and public sector bodies must also meet specific regulations, explained in GOV.UK’s accessibility requirements (opens in a new tab), including publishing an accessibility statement.
• Australia: the Disability Discrimination Act 1992 is the main law under which inaccessible websites may be challenged.
• Singapore: government digital services follow national accessibility guidance; private businesses should check sector expectations and customer requirements.

Kramate provides four to six hours of overlap with US Eastern time and a full working day with the UK, Australia and Singapore, which helps when developers and auditors need to discuss findings live.

Pricing for website accessibility audit services depends on the size and complexity of what is tested, not on page count alone. The main drivers are:

• Number of templates, journeys and components in the sample.
• Platforms: responsive web, native mobile apps, PDFs and other documents.
• Target level and WCAG version.
• Amount of interactive or custom functionality.
• Assistive technology combinations tested.
• Whether remediation support, re-testing and an accessibility statement are included.

Remediation is usually the larger investment, and it depends on how the site was built. Fixed-price suits a defined audit, while a dedicated team can fix issues in parallel. Budget for re-testing and for accessibility checks in future releases.

1. Method named. They scope and sample in line with WCAG-EM or an equivalent.
2. Manual testing included, with assistive technology, not only an automated scan.
3. Findings mapped to WCAG success criteria with reproducible detail.
4. Actionable fixes written for developers and designers.
5. Re-testing offered after remediation.
6. Plain honesty. Be wary of anyone who promises guaranteed legal protection or a one-click overlay fix.

For website accessibility audit services, a dedicated project manager coordinates your audit, with daily updates on Slack or Teams and a progress review at the end of each two-week round. We sign an NDA before detailed discussions, and you own every deliverable. Kramate can lead remediation or work alongside your developers, and the process is described in our approach to accessibility audits.

Audit findings often feed UX audit services and redesigns delivered through website design services.

• Web Content Accessibility Guidelines (WCAG) 2.2 (opens in a new tab)W3C
• Web Content Accessibility Guidelines (WCAG) overview (opens in a new tab)W3C
• Techniques for WCAG 2 (opens in a new tab)W3C WAI
• The Business Case for Digital Accessibility (opens in a new tab)W3C WAI
• Website Accessibility Conformance Evaluation Methodology (WCAG-EM) (opens in a new tab)W3C WAI
• Easy Checks - A First Review of Web Accessibility (opens in a new tab)W3C WAI
• ARIA Authoring Practices Guide (opens in a new tab)W3C WAI
• Web Accessibility Laws & Policies (opens in a new tab)W3C WAI
• Guidance on Web Accessibility and the ADA (opens in a new tab)US DOJ ADA.gov
• Understanding accessibility requirements for public sector bodies (opens in a new tab)GOV.UK