Website accessibility audit
Find the barriers automated tools miss.
CoderCorn reviews public-facing website experiences for accessibility issues across structure, keyboard use, forms, contrast, focus, content, interaction, and frontend implementation, then turns findings into prioritized remediation work.
What we review
- 01Document structure
- 02Keyboard access
- 03Forms
- 04Color + contrast
- 05Interactive components
- 06ARIA + semantics
Automated testing is not the audit
Automation finds signals. People find barriers.
Automated tools are useful for detecting certain technical issues, but they cannot reliably assess keyboard usability, 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.
What the audit reviews
Ten categories, reviewed as a system.
These categories are not a claim that every audit tests every WCAG success criterion — they describe the areas findings are organized around.
Headings, landmarks, semantic HTML, page title, language declaration, and reading structure.
Keyboard navigation, keyboard traps, focus order, visible focus, and interactive controls.
Labels, instructions, errors, required states, form-control relationships, and keyboard operation.
Alternative text, decorative images, meaningful images, and captions or transcripts where relevant.
Text contrast, interface contrast, color-only communication, and state visibility.
Link purpose, menus, skip mechanisms where relevant, predictable navigation, and focus behaviour.
Accordions, modals, tabs, dropdowns, carousels, custom controls, and state communication.
Reflow, zoom, mobile interaction, text resizing, and content clipping.
Autoplay, animation, flashing, moving content, and timeout-dependent interaction where relevant.
ARIA use, roles, names, states, relationships, and misuse of ARIA where native HTML would be better.
WCAG 2.2
WCAG gives the review a shared technical language.
WCAG 2.2 is a W3C Recommendation that organizes accessibility guidance around four broad principles: perceivable, operable, understandable, and robust. Audit findings can be mapped to relevant WCAG criteria where appropriate, but this is a technical reference, not a certification CoderCorn issues.
Beyond contrast
A passing color check does not make a website accessible.
Contrast is one visible signal among many. Structure, keyboard behaviour, focus, forms, labels, instructions, semantics, error handling, dynamic content, and assistive-technology compatibility all matter as much or more.
Overlays and widgets
An accessibility widget does not replace accessible code.
Third-party accessibility controls may offer particular user preferences or enhancements, but they do not automatically fix underlying semantic HTML, keyboard behaviour, form relationships, incorrect ARIA, focus management, or content structure.
Manual testing
Some failures only appear when you actually use the interface.
Manual review covers keyboard-only navigation, focus sequence, zoom and reflow, form completion, interaction-state review, responsive testing, and assistive-technology-informed review where appropriate to the engagement.
Prioritization
Not every issue has the same user impact.
Findings are organized by severity, frequency, the affected user journey, whether the underlying component repeats across the site, remediation complexity, and business-critical paths.
Critical
Blocks a core journey for users of assistive technology.
High
Significant barrier on an important or frequently used path.
Medium
A real issue with a workaround or limited reach.
Low
Minor or cosmetic, worth fixing when convenient.
What you receive
An audit should end with work someone can actually do.
Deliverables can include an issue inventory, the affected page or component, reproduction steps, the accessibility impact, a relevant WCAG reference where applicable, a remediation recommendation, severity and priority, evidence such as screenshots where useful, and an executive summary.
Many accessibility failures repeat across navigation, buttons, forms, modals, cards, accordions, CMS templates, and design-system components. Grouping findings by component, not just by page, means fixing the defect once instead of the same problem forty times.
Where remediation lands
Accessible does not have to mean visually generic.
Accessibility touches visual hierarchy, typography, contrast, focus design, interaction, motion, and forms — it is part of design quality, not a constraint on it. Most remediation work itself ends up 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.
Accessibility and technical SEO share some discipline — semantic structure, descriptive links, headings, image alternatives, and crawlable content all help both. That overlap does not mean accessibility is itself a ranking factor.
Existing site or new build
The right review depends on what already exists.
On an existing website, the audit focuses on high-traffic templates, critical conversion paths, repeated components, forms, navigation, and current accessibility debt. The cheapest time to fix a component is before it ships, so on a new build we review designs and components, frontend implementation, forms and interactions, and pre-launch QA rather than waiting until after launch.
Remediation
Finding the defect is only half of the work.
Depending on the stack and agreed scope, CoderCorn can remediate frontend issues, update templates, fix forms, improve semantics, adjust interaction behaviour, correct ARIA, improve keyboard behaviour, and revise component states.
Third-party limitations
Your website can depend on 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 behaviour. The audit can identify barriers inside these experiences, but remediation options may depend on the vendor rather than on CoderCorn.
Who needs an audit
Reasons an audit tends to get scheduled.
Not every business has a legal obligation driving this work — often it is simply time to know where the site stands. A PageScore diagnostic is a lighter starting point if a full audit isn’t the right first step yet.
- 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
A candid note
Some websites do not need a longer list of problems.
If the frontend is structurally outdated or inaccessible at the component level, a rebuild or component refactor may be more rational than individually patching dozens of repeated defects. A design-system review is sometimes the more useful starting point.
Audit process
Eight stages from scope to retest.
Retesting confirms that agreed remediation was implemented — it does not amount to a formal accessibility certification.
Identify the pages, templates, components, and user journeys that matter most.
Run appropriate automated checks as a first layer of detection.
Keyboard, structure, interaction, forms, responsive behaviour, and other applicable manual checks.
Document findings and reproduction context so issues can be understood without guesswork.
Separate high-impact issues from lower-priority improvements.
Translate findings into implementation work someone can actually do.
CoderCorn may fix issues directly within agreed scope.
Verify completed remediation where retesting is included in scope.
Accessibility statement
A statement is a communication tool, not a shortcut.
An accessibility statement can communicate a commitment to accessibility, the standards being targeted, known limitations, and a feedback or contact channel. Where CoderCorn provides implementation support for a statement, the policy and legal wording should still be reviewed by the client’s own advisers.
Accessibility requirements can vary by organization, jurisdiction, and context. CoderCorn provides technical accessibility review and implementation support, not legal advice or certification.
A website can look finished and still block the user.
Bring the site, the pages that matter most, and any known issues. We will help scope a review around what actually needs attention.
Request an accessibility auditCommon questions
Before the review begins.
01What is a website accessibility audit?+
A website accessibility audit is a structured technical review of a website’s structure, keyboard operation, forms, contrast, interaction, and code, combining automated checks with manual inspection to find barriers that affect real usage.
02What does an accessibility audit check?+
Document structure, keyboard access, forms, images and media, color and contrast, navigation, interactive components, responsive and zoom behaviour, motion and timing, and ARIA and semantic markup.
03What is WCAG 2.2?+
WCAG 2.2 is a W3C Recommendation that organizes accessibility guidance around four principles — perceivable, operable, understandable, and robust. CoderCorn uses it as a technical reference; it is not a certification CoderCorn issues.
04Is an automated accessibility test enough?+
No. Automated tools reliably catch certain technical issues, but they cannot fully assess keyboard usability, meaningful focus order, whether alternative text communicates the right information, confusing interactions, or content comprehension. Manual review is needed for those.
05Does CoderCorn provide ADA compliance certification?+
No. CoderCorn provides technical accessibility review and implementation support, not legal advice or certification. Accessibility requirements can vary by organization, jurisdiction, and context, and compliance determinations rest with the client and its legal advisers.
06Can you fix the accessibility issues you find?+
Often, yes, within an agreed scope — frontend issues, templates, forms, semantics, interaction behaviour, ARIA, and component states. Remediation options for third-party embedded tools may depend on the vendor.
07Can you audit a WordPress website?+
Yes. The stack follows the project — WordPress themes, templates, and plugin-driven components are all in scope for review.
08Can you audit an ecommerce website?+
Yes, including checkout flows, product pages, filtering and search interactions, and account areas.
09Can you test forms and interactive components?+
Yes. Forms, accordions, modals, tabs, dropdowns, carousels, and custom controls are part of the standard review scope.
10Can you review a website before launch?+
Yes. Reviewing designs, components, and frontend implementation before launch is usually less costly than remediating after the fact.
11Do accessibility widgets make a website compliant?+
No. A third-party accessibility widget may add useful preferences for some users, but it does not fix underlying semantic HTML, keyboard behaviour, incorrect ARIA, or content structure.
12Can you audit only our most important pages or templates?+
Yes. Scope is typically set 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.
We will help scope a technical accessibility review, explain what automated and manual testing can and cannot tell you, and outline a remediation path within your stack and constraints.
Request an accessibility audit