Agree the tasks with the buyer before you build anything. A demonstration is evidence about the tasks demonstrated, in the environment demonstrated, and nothing else, so the value of the whole exercise is decided by whether those tasks are the ones they care about. Everything else on this page is preparation.
What a demo is, in procurement terms
One of the named options a buyer can ask for, alongside a conformance report and an accessibility statement, or in combination with them. Federal guidance treats it that way and leaves the evaluation guidelines to the buyer.
Ask What They Will Judge It Against
The buyer sets the criteria, so ask for them. In federal practice the acquisition team develops the guidelines for evaluating the demo, and whether the buyer or the vendor drives it is decided by the solicitation. That means the answers to who holds the keyboard, which assistive technology, and what counts as success all exist somewhere before your demo does.
If they have not written any down, offer a short plan and get it agreed in writing. Three or four tasks, the environment, and who operates. An agreed plan protects both sides: they see what they asked for, and you are not judged on a journey nobody mentioned.
Build the Script Around Their Tasks
The federal wording asks vendors to describe typical user scenarios and tasks, including those of disabled users, so that testing is fair and accurate. That is the right shape for a demo script, and it means starting from the work rather than from the feature list.
- Pick the tasks they buy the product for. Sign in, find the thing, do the thing, get the result out. Not the settings screen you know is clean.
- Write each one as a completion, not a click path. The test is whether the task finishes, which is a different question from whether every control has a name.
- Include one error state. A wrong password, a rejected field, an expired session. Error handling is where real journeys break and where demos never go.
- Name the environment. Operating system, browser and version, assistive technology and version. Put it on a slide so nobody has to ask.
- Decide who drives. Somebody fluent with the assistive technology, or the buyer's own tester. Both are defensible; guessing on the day is not.
Use Data You Would Be Happy to Share on a Screen
Everything in the demo account is about to be visible to people outside your company, and on a recording if anyone presses record. So build a fixture: made-up names, made-up addresses, made-up card numbers from your payment provider's test set. No real customer, no real employee, no production database with the names swapped out.
This is not only about privacy. A fixture is repeatable, which means the same demo produces the same result next quarter for the next buyer, and a barrier somebody spots can be reproduced afterwards by your own team.
Demo the Release, Not the Branch
Run what a customer would actually get. Where a federal agency tests a product before award, the vendor supplies the final commercially available release, and the guidance suggests stating outright that trial versions will not be accepted, because features may be missing and the results would not be about the real product.
The same logic applies to a branch with your accessibility work half-landed. Demoing an unreleased fix and shipping it three sprints later is the fastest way to turn a good-faith demonstration into a claim you cannot support.
Say What You Did Not Show
Close the demo by naming the boundary out loud. Which tasks were covered, which environment, which build, and what was not touched. That single minute is what separates a demonstration from an implied promise about the whole product.
If a task did not go well, say that too, and say what happens next. Buyers are considerably more forgiving of a known problem with a plan than of a smooth demo followed by a discovery. This is the same instinct behind an honest conformance report, and buyers who read those recognize it.
A Sandbox Is a Bigger Ask Than It Sounds
Some buyers would rather test your product themselves in a sandbox than watch you use it. Federal guidance flags that this route should involve legal, because it can amount to gifting or to purchasing a trial version, which is more than a demo arrangement.
So treat a sandbox request as a commercial conversation as well as a technical one. Who has access, for how long, with what data, under what terms, and what happens to the account afterwards. Those are answerable questions and they are much easier answered before the environment exists.
What a Demo Actually Proves
That these tasks, in this build, in this environment, could be completed by this operator. It is real evidence and it is narrow evidence, and there is nothing wrong with narrow evidence as long as everybody knows the width.
What it does not prove is conformance, because conformance is a property of full pages and complete processes rather than of a successful demonstration. If the buyer needs that answer too, the demo sits alongside the report rather than replacing it, and our page on what to require of a supplier covers what the report should arrive with.