Guide
Write Accessibility Into the Tender and Every Release Can Prove It
An audit before launch finds what was decided months earlier. We help you set the standard, the evidence and the test at the start, then check every release against them.
4-minute read5 November 2026
In Brief
- Accessibility found late becomes a list of defects to negotiate. The costly causes, such as the component library and the form design, are already fixed in place by then.
- We see four actions: name the standard in the tender, define the full scope, ask for evidence by requirement, and test a real task by keyboard and screen reader before scoring.
- Thinqmesh builds keyboard and screen reader checks into your release process, with an accessibility report alongside the automated tests, so each release carries its own evidence.
Accessibility is usually dealt with near the end of a public sector project. A report arrives shortly before launch, lists many defects, and the department decides which of them can wait. We believe the requirement belongs earlier, written into the tender with the same weight as security or data residency, so that every bidder prices it and every release is checked against it.
The Costly Causes Are Decided in the First Weeks
The component library, the form design, the login route and the way documents are published all settle early. Each one either carries accessibility with it or leaves it out. When a problem is found at the end, correcting it means reopening work that was already accepted.
That is why the cost shows up late and looks like bad luck. A requirement stated in the tender, evidenced by the supplier and tested on a real task with a keyboard and a screen reader finds the same problems while they are still small. Rule 15 already points to the government website guidelines and to IS 17802, and the Supreme Court's 2024 judgment in Rajive Raturi v. Union of India directed the Union Government to set non-negotiable rules. Whatever the final text says, a buyer who adopts these terms now is ready for it.
Four Actions That Put Accessibility in the Contract
Each one can be written into the next tender, or tried on the service you run today.
Name the Standards and Their Versions
A tender that cites the standard gives every bidder the same target and gives you something to test against.
Cite IS 17802 Parts 1 and 2 and the government website guidelines that Rule 15 points to, and decide whether you also want a current WCAG version. Naming versions turns a general wish into a requirement that a bidder can price and an evaluator can check.
Get started
- Find the accessibility clause in your last tender and list the standards it names.
- Add the standard and its version to the next tender you issue.
Define the Scope in Full
Mobile apps, generated documents, third-party login and payment parts, and the screens staff use all belong in scope.
Back-office screens are where a colleague with a disability does their job, and generated PDFs are where a citizen collects a certificate. Writing the scope in full holds the whole service to one requirement, and leaves none of it to a later change request.
Get started
- List every screen, app and document a person touches in one service.
- Mark the parts that come from a third party and ask that supplier for their evidence.
Ask for Evidence by Requirement
A statement for each requirement, with the method used and the known failures, tells you far more than a single claim.
A report that lists no failures deserves a closer look, because automated scanners find only part of the problem. Ask for the method behind each statement and for the failures the supplier already knows about, so the conversation starts from facts.
Get started
- Ask bidders for conformance statements, requirement by requirement.
- Read the known failures first and ask how each will be fixed.
Test Two Real Tasks Before You Score
An evaluator attempts the tasks your users need most, with a keyboard and a screen reader, on the bidder's working system.
Submitting an application and downloading a certificate show quickly whether a service works for everyone. Make the result a gate, treat a blocked task as a blocking defect, and re-test at each major release so the finding holds after launch.
Get started
- Pick the two tasks your users most need to complete.
- Try them on your current service with the mouse unplugged and note where you get stuck.
How Thinqmesh Solves This
Our quality and testing work begins with the paths that matter most to your users, then builds the checks into your release process so that the answer on accessibility arrives with every change.
- Week 1
Your Key User Journeys, Ranked by Risk
We establish the key user journeys on your own software, including the tasks people must be able to complete with a keyboard or a screen reader.
- Week 2
Tests for the Highest-Risk Paths
Automated tests are written first for the paths that carry the most risk, and accessibility checks are designed alongside them.
- Week 3
Checks That Run on Every Change
The tests are connected to your release process so that they run on every change, and problems are caught while they are inexpensive to correct.
- Week 4
A Suite Your Team Can Extend
Your team receives a working test suite and an accessibility report, and the results inform each release decision.
You finish with a test suite and an accessibility report that your own team can extend, and a clear answer on whether each release is safe to ship.
