SATYA Accessibility Testing Tool: How to Audit a Website
An accessibility audit is useful only when it changes what your team builds. SATYA—Smart Accessibility Testing for Your Application—gives Indian designers, developers and content teams a practical way to scan a live page, connect detected problems to recognised standards and turn a vague instruction such as “make this accessible” into a prioritised repair list.
The tool is especially relevant to agencies working on government, education, public-service and procurement-led projects, but its findings are useful on ordinary business websites too. Missing form labels, weak colour contrast, broken keyboard focus and poor heading structure do not become harmless just because a site is privately owned.
The right outcome is not a perfect automated score. It is a website that real people can navigate, understand and complete tasks on.
This guide explains how to use SATYA, how to interpret its output, which fixes belong in development rather than content editing, and where automated testing must stop. If you are commissioning a new site, add these checks to your website design brief before the first template is approved.
What SATYA is—and what it is not
According to C-DAC’s official SATYA product information, SATYA can scan single and multiple pages, highlight issues visually, classify findings by impact and produce reports with remediation guidance. The Accessible India Campaign portal also lists SATYA as a Chrome-based accessibility-testing tool for designers, developers and content managers.
That makes it a strong first-pass auditing tool. It is not a substitute for human judgement. A scanner can confirm that an image has an alt attribute; it cannot always decide whether the description communicates the image’s purpose. It may identify a focusable control, yet still miss that the interaction is confusing when used with a screen reader.
The current Chrome Web Store listing describes single-page scans, multi-page samples, impact categories and downloadable reports. Record the extension version and audit date in client work because rule coverage and behaviour can change between releases.
Standards covered by SATYA
Standard | Why it matters | Audit use |
IS 17802 | India’s ICT accessibility standard | Map failures to applicable project or procurement requirements. |
GIGW 3.0 | Guidance for Indian government websites and apps | Use applicable checkpoints and certification scope for public-sector work. |
WCAG 2.1 | International criteria supported by SATYA | Use Level A and AA findings as the automated baseline. |
WCAG 2.2 | Current W3C Recommendation with additional criteria | Review the additions separately and verify manually. |
Section 508 / EN 301 549 | Relevant to US federal and European ICT contexts | Confirm the contract and jurisdiction before claiming conformance. |
India’s GIGW accessibility guidance instructs evaluators to combine tools with manual checks and assistive technology. Meanwhile, WCAG 2.2 extends WCAG 2.1. A responsible report should therefore state exactly what SATYA checked and which WCAG 2.2 additions were reviewed separately.
Do not turn this table into a legal guarantee. Applicability depends on the organisation, service, jurisdiction and contract. Where compliance exposure is material, pair the technical work with qualified legal or accessibility advice.
How to run a useful SATYA website audit
Step 1: define the user journeys before scanning
Do not begin by scanning random URLs. List the tasks that matter: finding a service, opening the menu, submitting the contact form, logging in, adding a product, completing checkout, downloading a document or booking an appointment. The audit should cover every template and interaction involved in those journeys.
Homepage and primary navigation
One representative service, product and article page
Contact, quote or registration form
Search results, filters and empty states
Cart, checkout, account or booking flow when applicable
Validation errors and confirmation screens
Step 2: install SATYA and record the test conditions
Install the official extension from the Chrome Web Store. Record the extension version, browser version, operating system, URL, date, authentication state and whether consent banners or personalisation were active. This small audit header prevents confusion when a later scan produces a different result.
For staging environments, confirm that the extension can access the page. If the site needs HTTP authentication, a VPN or a restricted account, document that access instead of weakening production security merely to run a scan.
Step 3: run a single-page scan first
Start with one representative page. A single-page scan is easier to review than a site-wide report and quickly reveals whether the same template is generating repeated failures. Work from the highest-impact findings down, but inspect the affected element before accepting the tool’s interpretation.
Open the page in its normal visitor state.
Launch SATYA and start the single-page scan.
Review critical and serious findings first.
Select each result and locate the highlighted element.
Reproduce the issue manually before assigning it.
Capture the selector, screenshot, expected behaviour and affected journey.
Step 4: sample multiple page types
A multi-page scan is useful after the first page is understood. It can expose repeated issues across navigation, cards, forms and footers. Do not treat a random sample as complete coverage: an ecommerce checkout, member area or JavaScript application may contain states that a crawler never reaches.
Group findings by component rather than dumping hundreds of URLs into a spreadsheet. If the same unlabelled search button appears on 80 pages, that is one template defect with a large footprint—not 80 unrelated writing tasks.
Step 5: export the report and add implementation detail
An automated export is evidence, not a developer ticket. Add the page state, affected component, reproduction steps, expected result, suggested owner and acceptance test. Prioritise by user impact and journey importance, not solely by how many warnings the tool counted.
How to prioritise SATYA findings
Priority | Typical problem | Action |
P0 — task blocked | Checkout, form or navigation cannot be completed | Fix before launch or deploy an urgent correction. |
P1 — serious barrier | Controls lack names, focus disappears, errors are not announced | Fix the component and retest the full journey. |
P2 — repeated issue | Contrast, headings or link text fail across a template | Fix the shared component before individual pages. |
P3 — isolated improvement | One image description or content warning needs review | Correct during the current content cycle. |
Severity is context-sensitive. A missing label on an optional newsletter field is not equivalent to a missing label on the payment form. Combine the tool’s impact level with the importance of the task and how often the component appears.
Four accessibility fixes developers should understand
1. Write text alternatives for purpose, not appearance
A useful alternative explains why the image is present. Decorative images should normally be ignored by assistive technology; functional images need the action or destination described. Avoid filler such as “image”, “graphic” or a keyword-stuffed filename.
<img src="/team-support.jpg" alt="Support specialist helping a customer configure an online store">2. Give every form control a programmatic name
Placeholder text is not a durable label. Connect a visible label to its field, keep instructions available after typing and associate error text programmatically. Test validation without a mouse and confirm that focus moves to a useful location.
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">If leads are dropping before submission, accessibility may be only one part of the problem. Review the field order, required information, CAPTCHA and mobile behaviour as part of the website maintenance workflow.
3. Make keyboard focus unmistakable
A user must be able to see which control is active. Do not remove the browser outline without replacing it with an equally clear indicator. Check menus, dialogs, carousels, cookie banners, accordions and custom select controls in a logical sequence.
:focus-visible {
outline: 3px solid #0b57d0;
outline-offset: 3px;
}For a deeper manual workflow, use Webcurry’s keyboard accessibility testing guide to check focus order, traps, modal behaviour and skip navigation.
4. Use headings as structure, not decoration
The page title should be represented by one meaningful H1, followed by logical H2 sections and H3 subsections. Do not choose an H4 merely because its default styling looks smaller. Change the CSS, not the document outline.
<h1>Website Accessibility Audit</h1>
<h2>Contact Form Findings</h2>
<h3>Missing Labels</h3>What SATYA cannot confirm automatically
Some of the most important questions require a person to use the interface. Automated tools cannot reliably decide whether instructions are understandable, alternative text is meaningful, focus order matches the visual task, a screen-reader announcement arrives at the correct time or a multi-step process remains usable under stress.
Whether content makes sense when read in heading or link order
Whether every action works comfortably with only a keyboard
Whether a screen reader announces status, errors and dynamic updates clearly
Whether content survives 200% and 400% zoom without losing tasks
Whether touch targets and dragging interactions have usable alternatives
Whether authentication avoids unnecessary cognitive tests
Whether captions, transcripts and audio descriptions communicate the media
SATYA versus other accessibility tools
Method | Best use | Limitation |
SATYA | India-focused scanning tied to IS 17802 and GIGW | Automated coverage does not establish complete conformance. |
WAVE | Visual, in-page review with human context | Findings still need interpretation and verification. |
Lighthouse | Fast browser baseline with other quality checks | The score covers only rules tested in that run. |
axe DevTools | Developer debugging and repeatable rule-based testing | Automated rules cannot assess every experience. |
Manual testing | Interaction, focus, announcements and real journeys | Requires skill, scenarios and consistent documentation. |
Using two scanners does not make an audit complete, but it can expose differences in rule coverage. The strongest workflow combines automated checks, browser inspection, keyboard testing, at least one screen reader and representative user journeys.
A practical agency workflow
For a web design agency, accessibility should begin during discovery rather than appearing as a launch-day plugin. Agree on the target standard, templates, user journeys, testing methods, evidence, remediation responsibility and retest process before quoting the project.
Discovery: document audiences, contractual requirements and essential journeys.
Design: review contrast, focus states, target sizes, error patterns and hierarchy.
Development: use semantic HTML before adding ARIA and test components as they are built.
Content entry: train editors on headings, links, alt text, tables and media alternatives.
Pre-launch QA: run SATYA and a second automated tool, then complete manual journeys.
Post-launch: retest production and include accessibility in maintenance.
AI-generated websites need the same discipline. Use the AI-built website launch checklist for a broader pre-launch review, but do not mistake a polished visual preview or generated accessibility statement for tested behaviour.
Evidence from real website audits
The Association of People with Disability’s Yes to Access audit used WAVE and SATYA across more than a thousand websites and reported recurring problems including missing image alternatives, poor colour contrast and missing captions. The exact counts belong to that project, but the pattern is a useful reminder: many serious barriers are basic, repeated and fixable.
Use research like this to shape the audit checklist, not to claim that every site has the same failure rate. Your report must describe what was actually tested on the client’s pages.
How to write the final audit report
A client should be able to understand what was tested, what failed, how serious it is and what happens next. Include the following fields for every confirmed issue:
Issue title and affected standard or success criterion
URL, component and page state
Who is affected and which task becomes difficult
Steps to reproduce
Screenshot or short recording when useful
Relevant code or DOM evidence
Recommended fix and responsible discipline
Acceptance test and retest status
Keep automated warnings that you have not reproduced in a separate review queue. This protects developers from noisy tickets and protects clients from a report that looks comprehensive but has not been validated.
The bottom line
SATYA fills a useful gap for Indian website projects: it brings IS 17802 and GIGW context into a practical browser-based workflow. Its value is highest when a designer or developer verifies the findings, repairs shared components and then retests the real user journey.
Start small: scan one important page, fix the repeated template problems, complete a keyboard pass and document what remains. That produces more user value than chasing a perfect score across hundreds of pages without understanding a single failure.
Frequently asked questions
What is the SATYA accessibility testing tool?
SATYA stands for Smart Accessibility Testing for Your Application. It is a C-DAC accessibility-testing tool that scans web pages, highlights detected barriers and connects findings to standards such as IS 17802, GIGW, WCAG 2.1, Section 508 and EN 301 549.
Is the SATYA Chrome extension free to use?
The SATYA Chrome extension can be installed from the Chrome Web Store without a listed purchase price. Organisations considering its wider cloud, on-premise or scheduled-scanning options should confirm current commercial terms directly with C-DAC.
Which accessibility standards does SATYA check?
C-DAC lists IS 17802, WCAG 2.1, GIGW 3.0 accessibility pointers, Section 508 and EN 301 549 among the standards supported by SATYA. The exact rules and coverage can change with tool updates, so record the version used for each audit.
Does SATYA fully test WCAG 2.2?
C-DAC currently describes SATYA as supporting WCAG 2.1. Because WCAG 2.2 adds further success criteria, teams should review those additions separately and combine automated results with keyboard, screen-reader, zoom and user-flow testing.
Can an automated SATYA scan prove that a website is accessible?
No. Automated scanning detects many code-level patterns, but it cannot judge every interaction, content decision or assistive-technology experience. Treat the report as a prioritised issue list, not as a compliance certificate.
Can SATYA test Wix, WordPress and Shopify websites?
SATYA evaluates the rendered page in the browser, so it can be used on public pages created with Wix, WordPress, Shopify or custom code. Access restrictions, login states and dynamically loaded components may require separate testing.
What is IS 17802?
IS 17802 is an Indian accessibility standard for information and communication technology products and services. Website teams should use the official standard and applicable legal or procurement requirements when defining the scope of an audit.
What is the difference between SATYA and WAVE?
Both tools help surface accessibility problems, but they use different rule sets, interfaces and reporting workflows. SATYA is particularly relevant when an Indian project needs references to IS 17802 and GIGW; using more than one tool can reveal different issues.
How often should a website accessibility audit be performed?
Run checks before launch, after major template or navigation changes, and whenever forms, checkout flows or interactive components change. A recurring review is useful for sites that publish frequently because new content can introduce fresh barriers.
Which SATYA issues should developers fix first?
Start with barriers that stop people from completing essential tasks: unusable keyboard paths, missing form names, inaccessible errors, low-contrast controls and content hidden from assistive technology. Then address repeated template problems before isolated page-level warnings.
Does website accessibility help SEO?
Accessibility and SEO are different disciplines, but they overlap in areas such as meaningful headings, descriptive links, text alternatives, usable mobile layouts and understandable content. Accessibility work should be justified by user access first, not by a ranking promise.
Can SATYA replace a professional accessibility audit?
SATYA can speed up discovery and regression checking, but a professional audit may also include manual testing, assistive technologies, representative user journeys, issue reproduction steps and remediation verification. The right depth depends on risk, audience and project requirements.
Comments