What does a website accessibility audit actually test?
A website accessibility audit tests whether people with disabilities can perceive, operate and understand your site and complete its tasks, measured against the success criteria in the Web Content Accessibility Guidelines. In practice it answers one question per journey: can someone who cannot use a mouse, cannot see the screen, or cannot hear the video still book, enquire or buy?
WCAG organises its criteria under four principles: perceivable, operable, understandable, and a fourth that asks for code assistive technology can reliably read. Each criterion has a level. Level A covers the most basic barriers, AA adds the requirements most laws and procurement policies reference, and AAA is a stricter set that few whole sites meet. A normal website accessibility audit targets A and AA together.
The output is not a score. It is a list: this button has no accessible name on the product template; focus disappears behind the sticky header on the booking page; the error message on the contact form is shown in red only. Each item names the criterion, where it happens, who it affects and how to fix it.
Perceivable
Text alternatives, captions, contrast, content that survives zoom and reflow.
Operable
Keyboard access, visible focus, enough time, no traps, target size, no reliance on dragging.
Understandable
Clear labels and errors, predictable navigation, consistent help.
Compatible with assistive technology
Correct names, roles and states so assistive technology can read the page.
What changed in WCAG 2.2, and why audit against it now?
WCAG 2.2 became a W3C Recommendation on 5 October 2023 and was updated in December 2024; it adds nine success criteria and removes one, 4.1.1 Parsing. Content that meets 2.2 also meets 2.1 and 2.0 for the criteria they share, so auditing to the newest version is the sensible default.
The additions reflect how people actually struggle with modern sites. Focus Not Obscured (Minimum) catches sticky headers and cookie bars that hide the element a keyboard user is on. Dragging Movements asks for a single-pointer alternative to sliders and drag-to-reorder. Target Size (Minimum) sets 24 by 24 CSS pixels as the floor for clickable targets, with exceptions for spacing and inline links. Accessible Authentication (Minimum) stops logins that depend on memorising or transcribing codes without help such as paste or a password manager.
At level A, Consistent Help asks that help options appear in the same place across pages, and Redundant Entry says users should not have to type the same information twice in one process. Both matter directly for Indian sites with long enquiry and admission forms.
The W3C's own summary of these changes is at What's New in WCAG 2.2.
Does Indian law require an accessible website? RPwD Act and GIGW explained
India's Rights of Persons with Disabilities Act, 2016 and the Rights of Persons with Disabilities Rules, 2017 set the accessibility framework, and the Department of Empowerment of Persons with Disabilities lists accessibility standards for ICT products and services notified in May 2023 under that framework. Whether and how those duties reach your particular private business is a question for your lawyer, not your developer.
For government bodies the position is clearer. GIGW, the Guidelines for Indian Government Websites and Apps, is mandated by the Government of India for its websites and apps, with version 3.0 current. STQC runs a Certified Quality Website scheme against it. If you supply websites to a ministry, PSU, state department or government-funded institution, the tender will usually name GIGW, and your website accessibility audit should be structured to match its checklist.
What we do: test against WCAG 2.2 AA, map findings to GIGW items where a government client needs that, and build fixes. What we do not do: issue certificates, represent you to STQC or any regulator, or tell you whether you are legally compliant.
The Department's list of acts, rules and notified standards is published at depwd.gov.in.
ADA exposure for Indian businesses with US customers
If your business sells to or serves the public in the United States, the US Department of Justice's position is that the Americans with Disabilities Act applies to goods and services offered on the web. Its March 2022 guidance says it has no regulation with detailed technical standards for businesses and points to WCAG and the Section 508 Standards as helpful references.
That combination (a legal duty without a fixed technical checklist) is why US-facing companies usually adopt WCAG AA as their working target. Indian exporters, SaaS products and D2C brands shipping to the US inherit that expectation through their customers, their resellers and sometimes their contracts. Procurement teams increasingly ask for an accessibility statement or a conformance report before signing.
A website accessibility audit gives you the factual base for those conversations: what was tested, what failed, what was fixed and when. It does not make you “ADA compliant” by declaration, and nobody honest will sell you a certificate that does. Take the audit and your fix log to your US counsel if a demand letter or contract clause is involved.
The DOJ guidance is at ada.gov. If you are building for US buyers from scratch, see our work for USA clients.
How to scope a website accessibility audit without testing every page
Audit one representative page per template, plus every step of your key journeys, plus any page that is unusual. Most sites have far fewer templates than pages, so this covers the code that matters without paying to repeat the same finding a thousand times.
A 300-page SEO site might have six templates: home, service, location, blog post, contact and a comparison table page. A store has home, category, product, search results, cart, checkout and account. Journeys are the paths that make you money or serve people: book an appointment, submit an admission enquiry, pay a fee, track an order.
We also sample content that authors create, not only templates. A CMS may output an accessible structure, and then an editor pastes an image of a price table with no text, or bold paragraphs pretending to be headings. Two or three recent posts show whether content habits are part of the problem.
- Every distinct template, at desktop and at a 320-pixel-wide mobile view
- Every step of two to four priority journeys
- Global parts: header, menu, footer, cookie banner, chat widget
- A small sample of editor-made content and downloadable documents
Keyboard testing: the fastest way to find serious barriers
Put the mouse away and press Tab. If you cannot reach, see and operate every link, button, menu and form field in a sensible order, the page fails for keyboard users, and very often for screen reader and switch users too.
Our keyboard pass checks five things on every sampled page. Can each control be reached? Is focus always visible, with a clear outline rather than a faint change? Does the order follow the visual layout? Can menus, modals and carousels be opened and closed with Enter, Space and Escape? And, new in WCAG 2.2, is the focused element ever hidden behind a sticky header, chat bubble or cookie bar?
Common failures on Indian business sites are predictable: mega menus that open only on hover, image sliders that trap focus, a “book now” control built from a div with a click handler, and popups that steal focus and give no way back. Each one is usually a component fix, which is why remediation cost is often lower than owners fear.
How is screen reader testing done in an accessibility audit?
A tester completes each priority journey using a real screen reader and listens for what is announced: headings, landmarks, link and button names, form labels, errors and status messages. We use NVDA with a browser on Windows, VoiceOver on iPhone, and TalkBack on Android, because Indian audiences are mostly on Android phones while US buyers skew toward iPhone.
The issues a screen reader exposes are ones scanners cannot judge. Five links all read as “Read more”. An icon button announces as “button” with no name. A price updates on the product page but nothing tells the user. The heading outline jumps from H1 to H4, so navigating by headings is useless. A form error appears visually but the screen reader never mentions it.
We record each finding with what was heard, what should be heard and the code change. Screen reader testing is also where regional-language pages need care: the page's lang attribute must match the text, or a Hindi paragraph will be read with English pronunciation rules.
NVDA
Free, open-source screen reader for Windows, used for desktop journeys.
VoiceOver
Built into iPhone and Mac; used for iOS Safari checks.
TalkBack
Built into Android; used for the phones most Indian visitors carry.
Automated tools such as Lighthouse, axe and WAVE catch rule-based failures quickly, including missing alternative text, empty links, duplicate IDs and low contrast between text and background. They cannot tell whether alt text is meaningful, whether the focus order makes sense, or whether an error message helps anyone, so a clean automated score does not mean an accessible site.
We use scanners at two points. First, as a sweep across every sampled page, which gives a quick list of mechanical failures. Every flagged item is then checked by hand, because scanners also raise false positives, for instance contrast warnings on text that sits over a solid colour the tool could not detect. Second, after remediation, as a regression guard that can run in your build so new mechanical errors are caught before they go live.
A 100 in Lighthouse's accessibility category is a nice number to have. It says very little about whether a blind user can finish your checkout.
Colour, contrast, text and media checks
WCAG AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text and for meaningful parts of interface components, such as input borders and focus indicators. Brand palettes often fail on light grey body text, white text on saffron or yellow buttons, and placeholder text used as a label.
We measure contrast on real rendered colours, including hover and focus states, and propose the nearest passing shade from your palette rather than a new colour scheme. Content checks run alongside: information conveyed by colour alone, images of text, videos without captions, and pages that break when zoomed to 400% or when text spacing is increased.
Media is often forgotten. A promotional video with speech needs captions; a podcast needs a transcript; an auto-playing background video needs a way to pause. For many small businesses the fix is simply turning off autoplay and uploading a caption file.
Forms are where inaccessible sites lose the most people, because a barrier at step three of a checkout loses a sale, not a page view. Every field needs a visible, programmatically linked label, instructions before input, and errors that are described in text, linked to the field and announced to screen readers.
WCAG 2.2 adds two form-focused criteria at level A and AA. Redundant Entry means information already given in a process should be filled in or selectable, not typed again. Accessible Authentication (Minimum) means a login should not demand a cognitive test, such as memorising or retyping a code, without an alternative; allowing paste into OTP and password fields is often enough.
Captchas deserve their own line in any audit report. Image puzzles block screen reader users outright. Where spam protection is needed, invisible checks or honeypot fields cause fewer problems. Better forms convert better for everyone, which is why this part of an audit often overlaps with conversion rate optimisation.
What should a website accessibility audit report contain?
A usable report lists each issue with the page or component, the WCAG criterion, what a user experiences, the fix in code terms, a priority and a status. It groups repeated issues by component so one fix clears many pages.
Priority is judged by impact on a journey, not by the criterion's level. A missing label on the only field of a newsletter signup is minor; the same fault on the phone field of an admission form is urgent. We use three bands. Blockers stop a user completing a key task. Serious issues make a task very hard. Moderate issues cause friction or confusion.
The report ends with a short summary for decision-makers: how many blockers, which components cause most failures, what fixes cost in time, and what should wait. Owners rarely read a 200-row spreadsheet, and they should not have to.
- Summary: scope, standard, dates, tools and assistive technology used
- Issue log: component, page, criterion, impact, fix, priority, status
- Component fix plan grouped for developers
- Retest results after remediation
- A draft accessibility statement for your site, for your review
Remediation cost depends on how many components fail and how the site is built, not on how many pages exist. Fixing a shared header, menu, form component and colour tokens on a custom-coded site can clear most failures in days; the same fixes on a page builder theme that generates tangled markup can take far longer.
Three situations cover most sites. A custom site with component-based code is usually cheapest to fix, because each change happens once. A WordPress site with a mainstream theme sits in the middle: some fixes go in a child theme, some need a different plugin. A heavily customised page-builder site, or one built on an abandoned theme, is where a rebuild often costs less than patching, and a new accessible static site starts at ₹10,000.
Across the market, audit and remediation quotes vary a great deal because some cover only automated scanning, some include a certification-style report, and some include no fixes at all. Compare what is tested, with which assistive technology, and whether retesting after fixes is included. Ongoing checks can sit in maintenance from ₹8,000/mo.
How long does a website accessibility audit take?
For a typical small business site with five to eight templates and two journeys, testing and the written report take roughly one to two weeks. Stores, portals and sites with logins take longer because every step of every journey is tested with assistive technology.
Remediation runs on its own clock. Blockers are fixed first, often within the first week after the report, so the key journeys work as early as possible. Serious and moderate issues follow in batches grouped by component. Each batch is retested by a different person on our team than the one who fixed it, which catches the fixes that look right in code but still misbehave in a screen reader.
Accessibility is not a one-time event. New pages, new plugins and new campaign banners can reintroduce old faults. A light quarterly recheck of key journeys, plus automated checks on every deploy, is what keeps a site from drifting back.
Accessibility for mobile apps, PDFs and third-party widgets
Apps, documents and embedded widgets need checking too, because users do not care which vendor made the inaccessible part. A website accessibility audit should list them even when the fix belongs to someone else.
For Flutter and React Native apps we check that every control has a semantic label, that focus order works with TalkBack and VoiceOver, that touch targets are large enough and that text scales with the phone's font setting. PDFs such as brochures, fee structures and menus are often scanned images; the best fix is usually an HTML page, with an accessible PDF only where a document must be downloadable.
Third-party parts include chat widgets, payment pages, map embeds, booking engines and cookie banners. We test them, record what fails, and tell you whether it can be configured, replaced or needs a request to the vendor. Your Tag Manager container is a common source of injected widgets worth reviewing at the same time.
Does website accessibility help SEO and AI search?
Accessibility is not a direct ranking signal you can count on, but much of the work overlaps with what search engines and AI answer tools read: meaningful headings, descriptive link text, text alternatives, clean HTML and fast, stable pages.
A page with a proper heading outline is easier for a screen reader user to navigate and easier for a crawler or language model to divide into answerable sections. Descriptive link text tells both a blind user and a search engine what the destination is about. Captions and transcripts turn video content into indexable text. Accessible forms reduce abandonment, which is where the business value shows up.
We will not claim that an accessibility audit raises rankings; nobody can guarantee that. We will say that fixing structure, text alternatives and markup is work that rarely hurts and often helps. If search visibility is your main concern, our AI Overview optimisation page covers that angle.
Worked example: website accessibility audit for a US-facing skincare store
Suppose a small skincare brand in Bengaluru (a hypothetical case) sells in India and ships to the US, and a US retail partner asks for an accessibility statement before listing the products. The store has seven templates and a checkout.
Week one: an automated sweep flags missing alt text on product images and low contrast on grey price text. The keyboard pass finds that the size selector cannot be operated without a mouse and focus hides behind a sticky “add to cart” bar. NVDA reveals that cart updates are silent and the OTP field blocks paste. TalkBack on an Android phone shows unlabelled icon buttons in the header.
Week two: fixes go in by component. The size selector becomes native radio buttons, the sticky bar gets scroll padding, cart changes use a live region, OTP accepts paste, icon buttons gain names and grey text darkens to the nearest passing shade. A second team member retests with NVDA and VoiceOver.
The brand now has a dated issue log, a retest record and a draft statement to review with its own counsel before sending it to the partner. What it does not have is a certificate, because none was promised.