WCAG Accessibility Checklist for Indian Business Websites

WCAG Accessibility Checklist for Indian Business Websites

A practical WCAG accessibility checklist for a website should cover content, design, code, forms, keyboard use, mobile behaviour and testing with assistive technology. For most Indian businesses, aiming for WCAG 2.2 Level AA is a sensible target, while also checking whether a government, education, healthcare or procurement requirement specifies a particular standard.

Website accessibility means making a website usable by people with visual, hearing, motor, cognitive or learning disabilities. It also improves usability for older users, people on mobile devices, users with slow connections and anyone navigating a website in difficult conditions.

This guide is written for Indian NGOs, schools, clinics, agencies, D2C brands and small businesses. It explains what to check before launch, what to include in a website brief, and how to test whether accessibility work is actually effective.

What WCAG Compliance Means

The Web Content Accessibility Guidelines, commonly called WCAG, are published by the World Wide Web Consortium. They provide testable recommendations for making websites and digital products more accessible.

WCAG is organised around four principles:

• Perceivable: Users can receive information through sight, hearing or alternative formats.
• Operable: Users can navigate and operate the interface using different input methods.
• Understandable: Content and interactions are clear and predictable.
• Robust: The website works with browsers, devices and assistive technologies.

Each guideline has success criteria at three levels:

• Level A: Basic accessibility requirements.
• Level AA: A broader and commonly used practical target.
• Level AAA: The highest level, which may not be realistic for every type of website.

For a business website, Level AA is usually the most useful target. It does not mean every person will have the same experience, but it establishes a strong baseline for accessible design and development.

WCAG 2.1 or WCAG 2.2?

WCAG 2.2 adds criteria related to focus visibility, dragging alternatives, target size, accessible authentication and help mechanisms. A new website should generally consider WCAG 2.2, while checking any client, tender or regulatory specification that refers specifically to WCAG 2.0 or 2.1.

WCAG conformance is not a one-time certificate that makes a website permanently accessible. New pages, uploaded PDFs, marketing banners, plugins and website redesigns can introduce new problems. Accessibility needs to be included in the normal content and maintenance process.

India-specific considerations

Indian organisations should also consider:

• Regional-language content and readable script rendering.
• Mobile-first browsing and inconsistent network conditions.
• Accessibility of PDFs, application forms and downloadable documents.
• Payment, registration and appointment-booking journeys.
• Compatibility with Android devices and commonly used browsers.
• Requirements in government tenders or institutional procurement.
• Accessibility expectations under India’s disability rights framework.

The Rights of Persons with Disabilities Act, 2016 is relevant to disability inclusion in India. The exact obligations can depend on the organisation, service and applicable rules or procurement requirements. WCAG testing is useful, but it is not a substitute for legal advice where a specific compliance obligation applies.

Accessibility Checklist Before Design and Development

Accessibility is cheaper and more reliable when considered before the website is designed. Adding accessibility fixes after development often requires changes to the layout, content model, forms and front-end components.

Use this checklist during the planning stage.

Define the people and tasks

Identify the main tasks users need to complete:

• Read about the organisation or product.
• Find contact details and location.
• Submit an enquiry or application.
• Book an appointment.
• Donate or make a payment.
• Download a brochure, report or invoice.
• Buy a product.
• Register for an event or course.
• Find an emergency or support phone number.

Then consider how people with different disabilities may complete those tasks. A donation form may need keyboard support, clear error messages and an alternative to a visual CAPTCHA. A clinic website may need readable appointment instructions and an accessible way to call the clinic.

Include accessibility in the project brief

A website brief should mention:

• The WCAG version and target level.
• Required browsers and mobile devices.
• Whether keyboard-only testing is required.
• Whether screen-reader testing is required.
• Which PDFs and documents must be accessible.
• Language and script requirements.
• Who will review content after launch.
• How accessibility defects will be prioritised.

Do not write only “make the website accessible”. That is too vague to test. Specify the expected standard and the key user journeys.

Choose an accessible design system

A design system should define accessible colours, typography, buttons, form fields, cards, menus, alerts, tabs, modals and error states. Reusable accessible components reduce the chance that every page will implement the same interaction differently.

Be cautious with third-party themes and page builders. A theme may look clean while using poor heading structure, low-contrast text, inaccessible sliders or keyboard traps. Review the actual front-end output rather than relying only on a theme’s accessibility claim.

Visual Design and Content Checklist

Visual accessibility is more than choosing large text. Users need sufficient contrast, predictable layout, readable language and information that does not depend on colour alone.

Check colour contrast

Text should have adequate contrast against its background. WCAG has different contrast requirements for normal text, large text and user-interface components. Use a contrast analyser during design and again on the implemented website.

Check these elements:

• Body text and headings.
• Text placed over images.
• Button labels.
• Placeholder text.
• Navigation links.
• Form borders and focus indicators.
• Disabled and selected states.
• Charts, graphs and data visualisations.
• Text in banners and pop-ups.

Do not use light grey body text merely because it appears visually subtle. It can be difficult to read on mobile screens or for people with low vision.

Do not use colour as the only signal

A form should not say only “fields marked in red are required”. Add text, an asterisk with an explanation, or another clear indicator.

Similarly:

• A chart should use labels or patterns in addition to colours.
• A stock status should say “Out of stock”, not only show a red dot.
• A calendar should not identify available dates only through colour.
• Links within body content should be distinguishable without requiring colour vision.

Use meaningful headings

Headings help people scan a page and help screen-reader users navigate by section. Use one clear page heading, usually an H1, followed by a logical hierarchy of H2 and H3 headings.

Avoid choosing a heading level only because its font size looks right. Visual size should be controlled with CSS, while the HTML heading level should reflect the structure of the content.

For example:

• H1: Dental consultation
• H2: Who this service is for
• H2: What to bring
• H2: Fees and appointment details
• H3: Documents for new patients

Write clear and direct content

Accessible content is easier to understand. Use short paragraphs, descriptive link text, lists and plain language.

Avoid links such as “click here” or “read more” when several appear on the same page. Prefer:

• Download the annual report
• View clinic appointment timings
• Read the return policy

If technical or legal language is necessary, explain it near the relevant action. This matters for NGO beneficiaries, first-time online users and people reading in a second language.

Support Indian languages carefully

If the site supports Marathi, Hindi, Tamil, Bengali or another Indian language, check more than translation quality. Verify that:

• The correct language is declared in the HTML.
• The selected font renders all characters properly.
• Line spacing is comfortable.
• Text does not get cut off when it wraps.
• Buttons expand for longer translated labels.
• Screen readers identify the language where possible.
• Language switching is easy to find and operate.

Do not rely on an automatic translation widget without reviewing the output. Poor translations can create accessibility and service-delivery problems, particularly for healthcare, education and financial information.

Keyboard, Focus and Navigation Checklist

Some users cannot use a mouse or touchscreen accurately. They may use a keyboard, switch device, voice control or another assistive technology.

Test the whole website without a mouse

Use the Tab key to move through the page. Check whether you can:

• Reach the logo and navigation.
• Open and close the menu.
• Operate dropdowns and accordions.
• Move through image galleries or sliders.
• Open and close pop-ups.
• Complete every form.
• Select dates and times.
• Add items to a cart.
• Apply filters.
• Submit a payment or enquiry.
• Reach footer links and legal pages.

Use Shift + Tab to move backwards and Enter or Space to activate controls where appropriate. If an action cannot be completed without a mouse, it needs attention.

Make focus visible

Keyboard users need to know where they are on the page. The focus indicator should be clearly visible against the background and should not be removed with CSS such as outline: none unless it is replaced with a better indicator.

Check focus on:

• Navigation links.
• Buttons.
• Form fields.
• Search controls.
• Modal close buttons.
• Product options.
• Pagination.
• Cookie controls.
• Sticky elements.

The focused element should not be hidden behind a fixed header, chat button or cookie banner.

Provide a skip link

A “Skip to main content” link allows keyboard users to bypass repeated navigation. It can be visually hidden until focused. This is especially useful on websites with large menus, announcement bars and repeated header elements.

Avoid keyboard traps

A keyboard trap occurs when focus enters a component but cannot leave it using normal keyboard commands. Modals, embedded forms, chat tools, calendar widgets and payment components should be checked carefully.

When a modal opens, focus should move to an appropriate element inside it. When it closes, focus should return to the control that opened it. Users should be able to close it without guessing.

Images, Audio, Video and Documents

Media and downloads are often overlooked in accessibility reviews. A website can have accessible HTML but still exclude users through inaccessible PDFs, videos and promotional graphics.

Add useful alternative text

Every meaningful image should have alternative text that communicates its purpose. The wording depends on context.

For example:

• A product image may need the product name, colour and relevant visible feature.
• A photograph of an NGO activity may need a short description of the activity.
• A decorative divider should usually have empty alternative text so it is ignored by screen readers.
• An image containing important event details should not be the only place where those details appear.

Do not begin every description with “image of”. Avoid stuffing keywords into alt text.

Make video and audio accessible

Videos should ideally include:

• Captions for spoken content.
• Identification of important speakers where needed.
• Descriptions of meaningful visual information.
• A transcript for important educational or informational content.
• Controls that work by keyboard.
• No unexpected autoplay with sound.

For a school course, clinic explanation or fundraising appeal, publish the key information as text as well. Automatic captions can help with a first draft, but they need human review for names, Indian accents, medical terms and regional-language content.

Check PDFs and downloadable files

An accessible website does not make an inaccessible PDF accessible. Review:

• Document title and language.
• Heading structure.
• Reading order.
• Table headers.
• Link text.
• Image descriptions.
• Colour contrast.
• Form fields.
• Text that can be selected and searched.

If a scanned document cannot be remediated quickly, provide an HTML version or a clearly labelled accessible summary. This is useful for annual reports, admissions information, policy documents, price lists and GST-related business documents.

Forms, Payments and Error Messages

Forms are among the most important areas in a WCAG accessibility checklist because they affect leads, applications, appointments, donations and purchases.

Label every field clearly

Every input needs a visible, associated label. Placeholder text is not a replacement for a label because it disappears when the user starts typing and may have poor contrast.

Labels should explain the expected information:

• Full name
• Mobile number with country code
• Email address
• Organisation name
• Preferred appointment date
• Message or support request

If a field is required, state that clearly. Do not make users guess whether an optional field can be left blank.

Use suitable input types

Use appropriate HTML input types and autocomplete attributes where relevant. This can help mobile users display a suitable keyboard and help browsers fill common information.

Examples include:

• Email
• Telephone
• Date
• Search
• URL
• Name
• Address

Do not force users to enter information in a format that is difficult to understand. If a phone number may include an Indian country code, explain the accepted format instead of silently rejecting valid variations.

Write useful error messages

An error should identify:

1. Which field has a problem.
2. What is wrong.
3. How to correct it.

“Invalid input” is not enough. A better message is: “Enter a valid email address, such as name@example.com.”

Errors should be available to screen readers and should not rely only on colour. Place the message near the relevant field and provide a summary at the top for long forms.

Do not make CAPTCHA the only route

CAPTCHAs can be difficult for users with visual, hearing or cognitive disabilities. If spam protection is necessary, provide an accessible alternative or use server-side and risk-based controls that do not require every user to solve a visual puzzle.

Check payment and booking journeys

Test the complete journey, including:

• Cart or service selection.
• Coupon or discount fields.
• Address and contact details.
• UPI or card payment hand-off.
• OTP entry.
• Payment failure.
• Retry options.
• Confirmation message.
• Invoice or receipt download.
• Cancellation or refund information.

Third-party payment and booking providers also need review. If the external component is inaccessible, document the limitation and look for an alternative rather than assuming the main website is sufficient.

Mobile, Motion and Interaction Checklist

A large share of Indian website traffic comes through mobile devices. Mobile accessibility is therefore not a separate concern from WCAG compliance.

Check zoom and text resizing

Users should be able to zoom content without losing information or functionality. Test the website with browser zoom and larger text settings.

Look for:

• Horizontal scrolling caused by fixed-width containers.
• Text hidden behind images or headers.
• Buttons that overlap.
• Menus that become unreachable.
• Form fields extending beyond the viewport.
• Important content disappearing at larger text sizes.

Make touch targets practical

Small links and controls are hard to use, especially for people with tremors or limited motor control. Keep enough space between adjacent controls and ensure important buttons are easy to activate on a phone.

This is particularly important for:

• Close buttons.
• Menu icons.
• Quantity controls.
• Date pickers.
• Product swatches.
• Checkbox labels.
• Carousel arrows.

Avoid unexpected motion

Animations can distract users or cause discomfort. Avoid background videos that start automatically and rapidly flashing content.

Where motion is used:

• Give users a way to pause or stop it.
• Respect the operating system’s reduced-motion preference where practical.
• Do not use animation to communicate information without a static alternative.
• Check that moving content does not block buttons or text.

Do not rely on hover

Hover interactions do not work reliably on touchscreens and are difficult for keyboard users. If a menu, tooltip or product detail appears on hover, provide an equivalent click or focus interaction.

Technical Accessibility and SEO Checks

Accessibility and search engine optimisation overlap in several areas, although they are not the same. Semantic HTML, descriptive headings, meaningful links and fast performance can help both users and search engines.

Use semantic HTML

Use real HTML elements for their intended purposes:

• Buttons for actions.
• Links for navigation.
• Headings for sections.
• Lists for lists.
• Tables for tabular data.
• Labels for form fields.

Do not create a button using a div and then try to reproduce all keyboard and screen-reader behaviour manually unless there is a strong reason and proper testing.

Check page titles and language

Each page should have a useful, unique title. The HTML language attribute should identify the main language. This helps screen readers select suitable pronunciation rules and helps users understand the page context.

Use ARIA carefully

ARIA can help describe custom components, but incorrect ARIA can make a website less usable. The first preference should be semantic HTML. Add ARIA only when the component needs additional information or behaviour that native HTML does not provide.

Common problems include:

• Adding a button role without keyboard support.
• Applying aria-hidden="true" to content that users still need.
• Giving duplicate or misleading labels.
• Hiding an error from assistive technology.
• Using live regions for every small page update.

Check status messages

Users should be informed when an important action succeeds or fails. For example:

• “Your enquiry has been submitted.”
• “Three products match your filters.”
• “Payment was not completed. No amount was charged.”
• “The file is being downloaded.”

These messages should be available to screen-reader users without requiring them to search the entire page.

Testing and Audit Process

Automated tools are useful, but no accessibility scanner can evaluate the complete user experience. A reliable review combines automated checks, manual review and assistive-technology testing.

Use more than one browser and device

At minimum, test the main user journeys on desktop and mobile. Consider commonly used combinations such as:

• Chrome with NVDA on Windows.
• Safari with VoiceOver on macOS or iPhone.
• TalkBack on Android.
• Keyboard-only use without a screen reader.
• Browser zoom and operating-system text-size settings.

The appropriate test set depends on the target audience. A school serving Android users may prioritise TalkBack and low-cost mobile devices. A professional services website may have a larger desktop audience but still needs mobile and keyboard testing.

Test real user journeys

Do not inspect only the home page. Review the pages and actions that matter to the organisation:

• Contacting the business.
• Requesting a quote.
• Making a donation.
• Buying a product.
• Booking an appointment.
• Applying for a programme.
• Downloading a report.
• Finding a phone number or address.

Record issues with the page URL, affected component, user impact, WCAG reference where applicable, screenshots and recommended fix. This makes it easier for a developer, designer and content editor to work from the same list.

Prioritise defects by impact

Fix issues that block users first. A keyboard trap in a donation form is more urgent than a minor heading-level inconsistency on an old blog post.

A practical order is:

1. Problems that prevent completing a key task.
2. Problems that affect many pages or a shared component.
3. Problems involving forms, payments, authentication or legal information.
4. Problems that create confusion or unnecessary effort.
5. Lower-impact consistency and quality improvements.

After fixes, retest the original issue and nearby components. A change to a shared navigation component can solve one problem while creating another.

Common Mistakes to Avoid

Several approaches create the appearance of accessibility without solving the underlying problem.

Relying only on an accessibility widget

An overlay or accessibility widget may offer controls such as font changes or contrast modes, but it cannot automatically repair poor HTML, missing labels, confusing content or inaccessible third-party forms. Treat it as an optional feature, not as a replacement for accessible design, development and testing.

Publishing image-only information

Many organisations publish event schedules, menus, fee structures and notices as images. This makes the information difficult to search, resize, translate or read with assistive technology. Publish the essential text in HTML and provide an accessible download where needed.

Using a single accessibility statement as proof

An accessibility statement is useful when it honestly explains the standard used, known limitations, contact method and review process. It does not prove that every page meets WCAG. Do not claim full compliance without a documented evaluation that supports the claim.

Fixing only the visible design

Larger text and improved contrast help, but accessibility also depends on source order, keyboard operation, labels, focus management, error handling and screen-reader output. A visually attractive redesign can still create serious barriers.

Forgetting content after launch

Website teams often fix the original pages and then upload an inaccessible PDF, create a graphic-only announcement or add a new form without labels. Add accessibility checks to the content publishing workflow and train the people who update the website.

Frequently Asked Questions

Is WCAG compliance mandatory for every Indian business website?

There is no single answer for every business. Requirements can depend on the organisation, sector, public-service role, tender conditions and applicable Indian laws or rules. Even where a specific legal obligation does not apply, WCAG is a useful technical benchmark for reducing barriers and improving service access.

Should a small business target WCAG Level AA?

Level AA is a practical target for most new business websites. Small businesses can begin with the highest-impact areas: keyboard access, readable contrast, headings, form labels, error messages, alternative text and mobile usability. A smaller accessible website is usually more useful than a larger website with inaccessible core journeys.

Can an automated accessibility tool certify my website?

No. Automated tools can identify certain code and content problems, but they cannot reliably judge whether instructions are understandable, whether alternative text is meaningful or whether a user can complete a complex task. Combine automated scanning with manual keyboard review, assistive-technology testing and, where possible, testing by people with disabilities.

Does accessibility improve SEO?

Some accessibility practices also support search visibility, including meaningful headings, descriptive links, useful text alternatives, semantic HTML and good performance. Accessibility should not be treated only as an SEO technique. The main purpose is to make information and services usable by more people.

Are accessible PDFs necessary if the website is accessible?

Yes. A PDF is a separate digital document and must be reviewed separately. If an important report, application form, brochure or invoice is available only as an inaccessible file, users may still be blocked even when the surrounding web page is well built.

How often should a website be accessibility-tested?

Test before launch, after major design or technology changes, and when adding important forms or third-party integrations. Also review accessibility during normal content updates. The frequency should reflect how often the website changes and how important its online services are.

Where to Start

Begin with a short audit of your five most important user journeys. Test the home page, navigation, contact or enquiry form, primary service or product page, and any payment, booking, donation or application flow.

Then create an accessibility backlog covering:

• Keyboard access and visible focus.
• Heading and landmark structure.
• Colour contrast and text resizing.
• Image alternative text.
• Form labels and error messages.
• Mobile layout and touch controls.
• PDFs, videos and downloadable documents.
• Screen-reader and browser compatibility.
• Content publishing responsibilities.

Include WCAG requirements in the website brief before requesting design or development proposals. Ask vendors to explain how they will test the site, which third-party services are included, and how accessibility issues will be handled after launch.

For a website audit, redesign or new build, you can talk to the Govindani Infotech team on WhatsApp about your requirements; project scope and pricing are confirmed by the team after understanding the website and its accessibility needs.