A website accessibility audit checks whether people can understand, navigate and complete important tasks on your website, including visitors who use keyboards, screen readers, magnification or alternative input devices. In 2026, a practical audit should use WCAG 2.2 Level AA as a useful technical benchmark, test real customer journeys and produce a prioritized list of fixes. Automated scanners are helpful, but they cannot replace manual testing.
For businesses in Delhi, Noida, Gurugram and Ghaziabad, accessibility is also a usability issue: a confusing enquiry form, an invisible keyboard focus indicator or an unreadable mobile menu can prevent a potential customer from contacting you. The aim is not to claim that every accessibility fix automatically increases conversions. It is to remove avoidable barriers and measure whether more people can complete their tasks.
What is a website accessibility audit?
A website accessibility audit is a structured review of pages, components and user journeys against recognized accessibility requirements. It examines perceivable content, operable controls, understandable interactions and robust markup. The widely used W3C Web Content Accessibility Guidelines (WCAG) 2.2 organize these principles into testable success criteria.
A complete audit goes beyond a home-page scan. Review navigation, service pages, search, forms, account flows, popups, product cards, checkout and error states. Sample different templates and test with keyboard-only navigation, screen-reader checks and common mobile viewports.
WCAG 2.2 audit checklist: 12 checks that matter
1. Test keyboard navigation from start to finish
Unplug the mouse and use Tab, Shift+Tab, Enter, Space and arrow keys where appropriate. Can you reach every interactive control in a sensible order? Can you open and close the menu, select options and submit a form? Avoid keyboard traps in modals, carousels and chat widgets. A skip-to-content link helps users bypass repeated navigation.
2. Make keyboard focus visible and unobscured
Every focused link, button and input needs a clear visual indicator. Sticky headers, fixed WhatsApp buttons and cookie notices must not completely hide a focused element. WCAG 2.2 adds Focus Not Obscured (Minimum), criterion 2.4.11 at Level AA. Test pages while scrolling and tabbing, especially on mobile.
3. Check text and interface contrast
Ordinary text generally needs at least a 4.5:1 contrast ratio against its background; large text has a 3:1 threshold under WCAG Level AA. Relevant non-text interface components and graphical objects also have contrast requirements. Do not rely on pale placeholder text as the only way to identify a field. Verify real colors, including hover, disabled and error states where applicable.
4. Add meaningful alternative text
Informative images need alt text that conveys their purpose in context. Decorative images should normally have an empty alt attribute. Avoid stuffing keywords into alt text or writing “image of” unnecessarily. Charts may need a concise alt description plus a nearby data table or explanation.
5. Use logical headings and descriptive links
A clear H1 and well-nested H2/H3 headings help visitors scan the page and help assistive technology users navigate by structure. Link labels such as “View WordPress development options” communicate more than repeated “click here” links. Buttons should describe the action, for example “Request an accessibility review.”
6. Label every form field and explain errors
Use programmatically associated labels, not placeholders alone. Identify required fields and provide useful, specific error messages. When a form fails, tell the visitor which field needs attention and how to fix it. Test validation, confirmation messages and submission with a keyboard and screen reader. This is particularly important on lead-generation pages.
7. Review mobile touch targets and spacing
WCAG 2.2 criterion 2.5.8 Target Size (Minimum), Level AA, generally calls for pointer targets of at least 24 × 24 CSS pixels, with defined exceptions including adequate spacing. Larger controls may be easier to use. Check close icons, carousel arrows, dropdown triggers, product variants and contact buttons on narrow screens. Read the W3C explanation of target size before treating 24 pixels as a universal design target.
8. Offer alternatives to dragging gestures
If a slider, map or reorderable list requires dragging, provide an alternative that can be completed with a single pointer action, unless dragging is essential. For example, use explicit Previous/Next buttons alongside a draggable carousel. This is a new Level AA criterion in WCAG 2.2.
9. Avoid asking users to re-enter information
Multi-step forms and checkout flows should reuse information already supplied when the same data is needed again, subject to WCAG 2.2 exceptions. A business enquiry form that repeatedly requests the same contact details adds friction for everyone and can be especially difficult for people with cognitive disabilities.
10. Keep help options consistent
When help appears across multiple pages, keep repeated contact or support mechanisms in a consistent relative order. If the header shows phone, email and chat, avoid rearranging these options unpredictably on the next page. Consistency helps people find assistance without relearning the interface.
11. Test authentication and verification
Do not make remembering a password, solving a puzzle or transcribing characters the only way to authenticate when the applicable WCAG 2.2 requirement calls for an accessible alternative or support mechanism. Test password managers, copy/paste, one-time codes and passkeys where relevant. Consider how visitors recover from expired sessions and failed verification.
12. Check zoom, reflow, motion and media
At 200% text resize and high page zoom, important content must remain usable. Check narrow viewport reflow, horizontal scrolling, captions for prerecorded video where required, pause controls for moving content and respect for reduced-motion preferences. Do not assume that a responsive layout automatically satisfies accessibility requirements.
Quick WCAG 2.2 audit table for business owners
| Area | What to test | Typical fix |
|---|---|---|
| Keyboard | All controls reachable without a mouse | Semantic buttons and correct focus handling |
| Contrast | Readable text and controls | Adjust foreground and background colors |
| Forms | Labels, errors and confirmations announced | Labels, validation text and live-region review |
| Mobile | Targets and spacing at small widths | Larger interactive hit areas and simpler layout |
| Content | Heading order, link names and image meaning | Semantic structure and contextual alt text |
| Navigation | Focus visible beneath sticky elements | Scroll padding, layout and focus adjustments |
How to audit WordPress, React and Next.js websites
WordPress: Test the actual rendered theme and page-builder components, not just the editor preview. Common trouble spots include plugin popups, inaccessible sliders, poorly labeled contact forms and third-party widgets. Fix the component or template where possible instead of applying one-off patches to dozens of pages. If your site needs structural changes, explore WordPress development services in Delhi.
React and Next.js: Pay attention to client-side navigation, focus after route changes, custom controls, modal focus management and hydration states. A visually attractive custom dropdown is not automatically equivalent to a native select. Use semantic HTML first, then accessible patterns for genuinely complex interactions. Accessibility checks should be part of the component library and pull-request testing.
Both stacks: Audit the complete journey, not just isolated components. A page may pass many automated checks while still making it impossible to complete a booking or enquiry. Good UI/UX design and accessibility testing should inform each other, while remaining separate disciplines.
Which tools should you use for an accessibility audit?
Start with browser developer tools and an automated scanner such as axe DevTools or Lighthouse to flag detectable problems. Then manually test keyboard order, screen-reader announcements, zoom, forms, touch controls and task completion. Use contrast-checking tools and the browser accessibility tree to investigate specific issues. Keep a record of the browser, device, page URL, problem, expected behavior, severity and retest result.
Automated tools are not certification. They can identify some code-level problems, but they cannot reliably decide whether every image description is meaningful or whether a complex flow is understandable. Avoid vendors that promise a one-click accessibility overlay will solve every issue.
How to prioritize accessibility fixes for lead generation
Start with blockers that prevent core actions: navigation menus, enquiry forms, appointment requests, checkout, login and payment. Next address recurring component problems affecting many pages, followed by content issues and polish. For a Delhi NCR service business, prioritize the paths from a service page to the enquiry confirmation. For an ecommerce store, prioritize product selection, cart, address entry, payment and order confirmation.
Illustrative example: A clinic website may have a “Book Appointment” button that is visually obvious but unreachable by keyboard, while its date picker traps focus. The appropriate solution is not simply to increase button size. The team must repair the interaction, test the complete booking flow and verify the confirmation. Any resulting improvement in completed bookings should be measured rather than assumed.
A practical 30-day accessibility improvement plan
- Week 1 — Inventory and baseline: Identify key templates and journeys, run automated scans, and document keyboard, screen-reader and mobile findings.
- Week 2 — Critical blockers: Fix inaccessible navigation, forms, focus traps, missing labels and unusable touch controls.
- Week 3 — Systemic components: Improve reusable buttons, cards, headings, contrast tokens, modal patterns and third-party integrations.
- Week 4 — Retest and monitor: Repeat manual and automated checks, confirm fixes on production, document remaining exceptions and add checks to release QA.
For a redesign or major rebuild, make accessibility part of the original scope rather than an optional last-minute add-on. Keshav Enterprises can review accessibility alongside website development and conversion journeys, then recommend a prioritized technical scope.
Website accessibility FAQs
What is WCAG 2.2 Level AA?
WCAG 2.2 is a W3C recommendation for accessible web content. Level AA is a commonly selected target that includes Level A and AA success criteria. It is a technical benchmark, not a universal statement of legal compliance in every jurisdiction.
Can a free accessibility scanner audit my entire website?
No. Automated scanners find some detectable issues, but manual keyboard, assistive technology and task-based testing are also needed.
Does website accessibility improve SEO?
Some practices, such as descriptive links, meaningful headings and accessible navigation, overlap with good site structure. Accessibility alone does not guarantee higher rankings.
Does accessibility help increase leads?
It can remove barriers that prevent people from completing forms, bookings and purchases. The effect on lead volume depends on the audience and the specific issues fixed, so measure outcomes.
Is WCAG 2.2 mandatory for every Indian business website?
Requirements depend on the organization, sector, contracts and applicable law. Consult qualified legal guidance for compliance obligations; do not treat a general checklist as legal advice.
Is 24 by 24 pixels enough for every mobile button?
No. WCAG 2.2 Level AA has a 24 × 24 CSS-pixel target-size criterion with exceptions, but larger targets are often more usable. Consider the entire interaction context.
Can accessibility be fixed with a WordPress plugin?
Plugins may help detect or address specific issues, but no plugin can guarantee that a site’s custom content, forms, navigation and user journeys are accessible.
How often should a website be audited?
Audit after major redesigns and significant feature changes, include checks in routine QA and periodically retest important journeys. The frequency depends on how often the website changes.
Make your website easier for everyone to use
A useful accessibility audit delivers more than a score. It identifies the barriers affecting real visitors, maps fixes to specific components and verifies that people can complete essential tasks. If your website serves customers in Delhi NCR and you want an evidence-based review of accessibility, UX and enquiry flow, contact Keshav Enterprises with your website URL and the customer journeys you want improved.
