Website Accessibility Guide for Indian Businesses

Website accessibility means designing and building digital experiences that more people can perceive, understand, navigate, and operate. That includes people using screen readers, keyboards, voice control, magnification, captions, high-contrast settings, reduced motion, or ordinary mobile devices in difficult conditions. It also includes temporary and situational limitations: a broken arm, bright sunlight, slow bandwidth, a noisy room, or a form completed while holding a child.

Accessibility is sometimes reduced to an automated score or an icon in the footer. Neither is enough. It is a quality practice across content, design, code, and operations. A website can pass an automated scan and still contain an unusable menu, confusing errors, or a checkout that loses keyboard focus.

This guide gives Indian business teams a practical starting point. It is not legal advice or a certification. Requirements can vary by sector, contract, market, and applicable law, so regulated or public-facing organisations should obtain qualified guidance. Scallar integrates these principles into website development and interface review rather than applying accessibility as a launch-day patch.

Begin with People and Tasks, Not a Score

List the most important tasks on the website: understand a service, compare an option, read a policy, submit an enquiry, book a meeting, buy a product, download a document, or sign in. Accessibility testing should confirm that people can complete those tasks through different input and presentation methods.

Prioritise pages by business and user impact. The homepage matters, but a contact form, pricing page, checkout, job application, support article, and account recovery flow may matter more. Include error and success states, not only the default screen.

Use WCAG as a structured reference, but connect each requirement to the experience. Teams are more likely to fix "the menu cannot be opened by keyboard" than an unexplained criterion number.

Use Semantic Page Structure

HTML elements carry meaning for browsers and assistive technology. Use a logical heading hierarchy, landmarks such as header, nav, main, and footer, real lists for grouped items, buttons for actions, and links for navigation. Avoid making a clickable div behave like a button unless all required keyboard and accessibility behaviour is recreated.

Each page should normally have one descriptive H1 followed by H2 and H3 headings that reflect the content structure. Do not choose heading levels for visual size. Style them with CSS while preserving the outline.

Give page titles and link labels enough context. "Learn more" repeated ten times is difficult to navigate out of context. "Review website pricing factors" communicates the destination.

Make Every Core Task Work with a Keyboard

Disconnect the mouse and use Tab, Shift+Tab, Enter, Space, Escape, and arrow keys as appropriate. Focus should move in a logical order and remain clearly visible. Every interactive control must be reachable and usable.

Menus, dropdowns, accordions, dialogs, carousels, tabs, date pickers, cookie controls, and custom selects require special attention. When a dialog opens, move focus into it; when it closes, return focus to the triggering control. Escape should close dismissible overlays unless doing so would lose important work.

Avoid positive tabindex values that manually reorder the page. The source order should match the visual and interaction order. Skip links can help keyboard users move directly to main content.

Create Visible, Consistent Focus States

Browsers provide focus indicators for a reason. Do not remove outlines without a clear replacement. Focus needs enough contrast against every background and should not be hidden behind sticky headers or floating elements.

Differentiate hover from focus but give both a coherent design. Test icon buttons and controls inside cards, dark sections, and mobile navigation. A focus ring that works on white may disappear on blue or black.

The design system should define focus centrally so new components do not each invent a weaker version. Scallar's UI/UX design service treats focus, errors, and responsive states as core component behaviour.

Write Useful Alternative Text

Alternative text describes the purpose of an image in context. A product image may need the product, colour, and view. A chart needs the insight or an adjacent data table. A team photo may need names when identity matters. A decorative texture should usually have an empty alt value so a screen reader can skip it.

Do not begin every description with "image of." Do not stuff keywords. Avoid repeating a caption word for word unless that is the clearest equivalent. For complex diagrams, provide a short alt and a longer explanation nearby.

Logos used as links should communicate the destination, such as "Scallar home," rather than describing every shape. Images containing text should be avoided for essential information because text cannot reflow, translate, or adapt to user settings.

Design Forms People Can Understand and Recover From

Every field needs a programmatically associated visible label. Placeholder text is not a label; it disappears and often has poor contrast. Explain required formats before submission and group related options with fieldset and legend where appropriate.

When validation fails, identify the fields, explain how to correct them, and preserve the user's input. Move focus to an error summary for long forms and link each message to its field. Do not rely on red colour alone.

Provide enough time for completion or allow extensions. Avoid unexpected context changes when a field receives focus. Confirm successful submission in visible text, not only a colour change or disappearing form.

Keep forms concise. Accessibility and conversion often improve together when unnecessary fields are removed. The server must still validate because client-side controls can be bypassed.

Check Colour Contrast and Non-Colour Cues

Text, icons, focus states, form borders, and essential graphics need sufficient contrast. Test actual colour pairs, including disabled, error, hover, and selected states. Thin light-grey text may look elegant on a design monitor and become unreadable on a phone outdoors.

Do not use colour as the only way to communicate status. Add text, icons, patterns, or position. A chart legend should remain understandable in greyscale. Links inside body text need a distinction beyond subtle colour where surrounding text makes them hard to identify.

Brand teams can preserve character while meeting contrast. The answer is often a wider palette with defined roles, not abandoning brand colours.

Support Text Resize, Zoom, and Reflow

Users should be able to zoom and enlarge text without losing content or controls. Avoid fixed-height containers around text. Let headings wrap and allow buttons to grow. At narrow widths, information should reflow rather than requiring horizontal scrolling, except where the content genuinely needs two dimensions, such as a large data table.

Test at 200 percent browser zoom and with increased mobile text settings. Check navigation, cards, modals, cookie banners, tables, and floating CTAs. Text should not overlap or be clipped.

Use relative units for typography and spacing where appropriate. Avoid scaling font size directly from viewport width, which can create unpredictable extremes.

Make Mobile Accessibility a First-Class Test

Touch targets need enough size and separation. Sticky actions should not cover content, form buttons, or browser controls. Support portrait and landscape when practical. Do not disable pinch zoom.

Check how screen readers on mobile announce menus, forms, and dynamic updates. Test with slower networks because loading states and timeouts affect accessibility. A control that appears late and shifts the page can cause accidental taps.

Mobile users often operate one-handed. Place frequent actions within a comfortable reach and avoid interactions that depend on hover.

Provide Captions, Transcripts, and Media Controls

Videos with meaningful speech need accurate captions. Audio content needs a transcript or equivalent. Auto-generated captions should be reviewed for names, technical terms, and Indian accents. Describe important visual information that is not spoken.

Do not autoplay audio. Give users controls to pause, stop, and change volume. Avoid rapidly flashing content. Respect reduced-motion preferences and offer a way to pause non-essential animation, carousels, or moving banners.

Embedded players should have descriptive titles and keyboard-accessible controls. If a third-party player is inaccessible, the business still owns the customer experience and should provide an alternative.

Handle Dynamic Content and Status Messages

Single-page applications often update content without a full page load. Screen-reader users need appropriate announcements for form success, errors, loading completion, cart updates, and search results. Use live regions carefully; too many announcements become noise.

Manage focus when routes or major views change. Set a meaningful document title and place focus at the start of new main content. Loading indicators should include text or an accessible name.

Do not hide critical content behind a control that only renders it after JavaScript when a simpler native pattern works. Native details and summary elements are often a robust choice for FAQs.

Make Tables and Data Understandable

Use tables for tabular data, not page layout. Mark header cells and associate them with rows or columns. Provide a caption or nearby heading. Keep tables concise and offer a mobile strategy: horizontal scrolling in a labelled region, priority columns, or a meaningful card transformation.

Charts need accessible names and a text summary of the conclusion. Provide source data in a table or downloadable format when the detail matters. Avoid communicating only through visual position and colour.

Write Plain, Scannable Content

Clear language helps everyone. Use descriptive headings, short paragraphs, specific instructions, and consistent terms. Explain abbreviations on first use. Put the important answer before background.

Button and error copy should say what happens: "Send enquiry," "Download pricing guide," or "Enter a 10-digit phone number." Avoid playful wording in critical actions if it creates uncertainty.

For multilingual websites, mark the page language and language changes. Use professional translation for important content and test that fonts and layouts support the script.

Accessibility and SEO Reinforce Each Other, but Are Not the Same

Semantic headings, descriptive links, transcripts, meaningful titles, crawlable content, and good performance can benefit both accessibility and search. That overlap is useful, but SEO does not prove accessibility. A page may rank while excluding keyboard users, and an accessible application screen may be intentionally private from search.

Treat both as quality disciplines with different tests. The SEO-friendly website and lead-generation guide shows how content and conversion architecture connect without claiming that one checklist satisfies every user need.

Use Automated Testing as a Starting Point

Automated tools can find missing alternatives, contrast failures, invalid labels, duplicate IDs, and some semantic issues. Run them in development and CI where possible. They are fast and repeatable.

They cannot reliably judge whether alt text is useful, heading structure makes sense, focus order is logical, errors are understandable, or a task is cognitively manageable. Combine automation with keyboard testing, screen-reader checks, zoom, mobile devices, and real users with disabilities when the stakes justify it.

Record results by template and task. Fix system-level problems first because one component correction can improve many pages.

A Practical Remediation Order

1. Restore access to critical tasks such as contact, purchase, login, and support.
2. Fix keyboard traps, missing labels, focus loss, and inaccessible navigation.
3. Correct page structure, headings, landmarks, and link names.
4. Improve contrast, text resize, touch targets, and mobile reflow.
5. Add alternatives for images, documents, audio, and video.
6. Refine complex widgets and dynamic announcements.
7. Update the design system, CMS guidance, and release tests so defects do not return.

Do not postpone all improvement because full remediation feels large. Fix high-impact barriers, communicate limitations honestly, and maintain a prioritised plan.

Accessible Procurement and Vendor Questions

Ask agencies and software vendors how they test, which standards they target, what components are known limitations, and whether accessibility is included in acceptance criteria. Request evidence from representative screens, not only a policy statement.

Clarify who remediates third-party tools, documents, video captions, and content entered after launch. Include accessibility in design and development review, not only final QA. Confirm source-code access and component documentation so issues can be corrected later.

Ongoing Governance After Launch

Assign an accessibility owner, but share responsibility. Designers own states and contrast. Developers own semantics and interaction. Writers own clarity and alternatives. Editors own uploaded media and headings. Product owners decide priority and budget.

Add checks to content templates and release criteria. Train editors on headings, links, images, and documents. Review new third-party widgets before purchase. Re-test priority journeys after redesigns, CMS changes, or major integrations.

The website launch checklist includes accessibility alongside forms, analytics, SEO, and production operations so it remains part of delivery.