Website accessibility audits that find the barriers automated tools miss.

We review your public-facing website for accessibility issues across structure, keyboard use, forms, contrast, focus, content, interaction and frontend implementation, then turn the findings into prioritized remediation work.

Start a project Check your site free with PageScore
A website can look finished and still block the user.

Since June 28, 2025, the European Accessibility Act (Directive (EU) 2019/882) has applied to in-scope products and services offered to consumers in the EU, including consumer banking services and ecommerce. Businesses based outside the EU can be in scope when they serve EU consumers, and microenterprises providing services are exempt. Each member state sets the detail through national law. We review the website against WCAG as a technical reference; whether your business is in scope is a question for your legal advisers.

Accessibility requirements can vary by organization, jurisdiction and context. We provide technical accessibility review and implementation support, not legal advice or certification.

Not every business has a legal obligation driving this work. Often it is simply time to know where the site stands.

WCAG 2.2, our technical reference

WCAG 2.2 is a W3C Recommendation that organizes accessibility guidance around four broad principles. We map findings to the relevant WCAG criteria where appropriate. It is a reference, not a certification we issue.

  • Perceivable
  • Operable
  • Understandable
  • Robust

Accessibility statements

A statement can set out your commitment to accessibility, the standards you target, known limitations and a way to send feedback. If we help implement one, your own advisers should still review the policy and legal wording.

Reasons an audit tends to get scheduled

  • Redesigning a website

  • Preparing for a major launch

  • Running an ecommerce business

  • Operating in financial services

  • Building a SaaS product

  • Receiving accessibility complaints

  • Needing an independent technical review as an agency

  • Inheriting an old frontend system

  • Running high-value forms or user journeys

Do accessibility widgets make a website compliant?

No. An accessibility widget does not replace accessible code. It may add useful preferences for some users, but it does not fix what sits underneath: semantic HTML, keyboard behavior, form relationships, incorrect ARIA, focus management or content structure.

In April 2025 the US Federal Trade Commission finalized an order requiring accessiBe to pay $1 million over claims that its widget could make any website WCAG-compliant.

The widget sits on top. The code underneath stays the same.

What does the audit actually check?

Ten areas, reviewed by hand as well as with automated tools. Automated tools are useful for detecting certain technical issues, but they cannot reliably judge keyboard usability, a meaningful focus order, whether alternative text communicates the right information, confusing form interaction, content comprehension, logical reading order, or whether a component is practically usable with assistive technology. Automation is one layer of the review, not the whole audit.

Manual review covers keyboard-only navigation, focus sequence, zoom and reflow, form completion, interaction states, responsive testing and assistive-technology-informed review where it suits the engagement. Contrast is one visible signal among many: a passing color check does not make a website accessible.

The ten areas describe how findings are organized. They are not a claim that every audit tests every WCAG success criterion.

  • Document structure

    Headings, landmarks, semantic HTML, the page title, the language declaration and reading structure.

  • Keyboard access

    Keyboard navigation, keyboard traps, focus order, visible focus and interactive controls.

  • Forms

    Labels, instructions, errors, required states, form-control relationships and keyboard operation.

  • Images and media

    Alternative text, decorative and meaningful images, and captions or transcripts where relevant.

  • Color and contrast

    Text contrast, interface contrast, color-only communication and state visibility.

  • Navigation

    Link purpose, menus, skip mechanisms where relevant, predictable navigation and focus behavior.

  • Interactive components

    Accordions, modals, tabs, dropdowns, carousels and custom controls, and how their states are communicated.

  • Responsive behavior and zoom

    Reflow, zoom, mobile interaction, text resizing and content clipping.

  • Motion and timing

    Autoplay, animation, flashing, moving content and timeout-dependent interaction where relevant.

  • ARIA and the accessibility API

    ARIA use, roles, names, states and relationships, and ARIA used where native HTML would be better.

Not every issue has the same user impact.

Findings are organized by severity, how often they occur, the user journey they affect, whether the underlying component repeats across the site, how complex the fix is, and business-critical paths.

  1. Critical

    Blocks a core journey for people using assistive technology.

  2. High

    A significant barrier on an important or frequently used path.

  3. Medium

    A real issue, with a workaround or limited reach.

  4. Low

    Minor or cosmetic, worth fixing when convenient.

Code you do not control

Embedded booking tools, payment systems, chat widgets, third-party forms, video players, maps and vendor portals all carry their own accessibility behavior. The audit can identify barriers inside them, but the fix may depend on the vendor rather than on us.

Where accessibility and SEO overlap

Semantic structure, descriptive links, headings, image alternatives and crawlable content help both accessibility and technical SEO. That overlap does not mean accessibility is itself a ranking factor.

Technical SEO services

Can you fix what the audit finds?

Often, yes, within an agreed scope. Depending on the stack, we can fix frontend issues, update templates, fix forms, improve semantics, adjust interaction behavior, correct ARIA, improve keyboard behavior and revise component states.

An audit should end with work someone can actually do. What you receive can include an inventory of issues with the affected page or component, steps to reproduce, the accessibility impact, the relevant WCAG reference where it applies, a recommended fix, severity and priority, evidence such as screenshots where useful, and an executive summary. Many failures repeat across navigation, buttons, forms, modals, cards, accordions, CMS templates and design-system components, so we group findings by component, not just by page. That way the defect is fixed once instead of the same problem forty times.

Most of that work lands in the frontend: semantic HTML, native controls, JavaScript interaction, ARIA, focus management and CSS states, which is development work more than a design-only fix. Accessible does not have to mean visually generic either. Accessibility touches visual hierarchy, typography, contrast, focus design, interaction, motion and forms, so it is part of design quality, not a constraint on it.

Custom web development

  1. Scope

    We identify the pages, templates, components and user journeys that matter most.

  2. Automated review

    Appropriate automated checks run first, as one layer of detection.

  3. Manual review

    Keyboard, structure, interaction, forms, responsive behavior and the other manual checks that apply.

  4. Evidence

    Each finding is documented with its reproduction context, so it can be understood without guesswork.

  5. Prioritization

    High-impact issues are separated from lower-priority improvements.

  6. Remediation plan

    The findings become implementation work someone can actually do.

  7. Optional remediation

    We can fix issues directly, within an agreed scope.

  8. Retest

    Where retesting is in scope, we verify the completed fixes. A retest confirms the agreed fixes were made; it is not a formal accessibility certification.

  • On an existing website

    The audit focuses on high-traffic templates, critical conversion paths, repeated components, forms, navigation and current accessibility debt.

  • On a new build

    The cheapest time to fix a component is before it ships. We review designs and components before the build, the frontend implementation, forms and interactions, and pre-launch QA, rather than waiting until after launch.

  • When a rebuild makes more sense

    If the frontend is structurally outdated or inaccessible at the component level, a rebuild or component refactor may be more rational than patching dozens of repeated defects. A design-system review is sometimes the more useful starting point.

    Web design services

Questions people ask before the review begins

What is a website accessibility audit?

A structured technical review of your website’s structure, keyboard operation, forms, contrast, interaction and code. It combines automated checks with manual inspection to find the barriers that affect real use.

What does an accessibility audit check?

Ten areas: document structure, keyboard access, forms, images and media, color and contrast, navigation, interactive components, responsive and zoom behavior, motion and timing, and ARIA and semantic markup.

What is WCAG 2.2?

A W3C Recommendation that organizes accessibility guidance around four principles: perceivable, operable, understandable and robust. We use it as a technical reference. It is not a certification CoderCorn issues.

Is an automated accessibility test enough?

No. Automated tools reliably catch certain technical issues, but they cannot fully judge keyboard usability, a meaningful focus order, whether alternative text communicates the right information, confusing interactions or whether the content can be understood. Those need manual review.

Does CoderCorn provide ADA compliance certification?

No. We provide technical accessibility review and implementation support, not legal advice or certification. Accessibility requirements can vary by organization, jurisdiction and context, and compliance decisions rest with you and your legal advisers.

Can you fix the accessibility issues you find?

Often, yes, within an agreed scope: frontend issues, templates, forms, semantics, interaction behavior, ARIA and component states. For third-party embedded tools, what can be fixed may depend on the vendor.

Can you audit a WordPress website?

Yes. The stack follows the project: WordPress themes, templates and plugin-driven components are all in scope for review.

Can you audit an ecommerce website?

Yes, including checkout flows, product pages, filtering and search, and account areas.

Can you test forms and interactive components?

Yes. Forms, accordions, modals, tabs, dropdowns, carousels and custom controls are part of the standard review.

Can you review a website before launch?

Yes. Reviewing designs, components and the frontend before launch usually costs less than fixing them afterward.

Do accessibility widgets make a website compliant?

No. A third-party widget may add useful preferences for some users, but it does not fix the underlying semantic HTML, keyboard behavior, incorrect ARIA or content structure. In April 2025 the US Federal Trade Commission finalized an order requiring accessiBe to pay $1 million over claims that its widget could make any website WCAG-compliant.

Can you audit only our most important pages or templates?

Yes. We usually set the scope around high-traffic templates, critical conversion paths and repeated components rather than every individual page.

Bring us the site. We'll find the barriers that deserve attention first.

Bring the pages that matter most and any known issues. We will scope the review around what actually needs attention, explain what automated and manual testing can and cannot tell you, and outline a remediation path within your stack and constraints.

Start a project Custom web development