Most kiosk purchases start the same way. You go and see a kiosk working. Maybe it is at an expo, with the manufacturer showing what the machine can do. Maybe the vendor tells you where one is installed nearby, and you go and stand in front of it. That is a reasonable start. It is just not the whole decision.
Deployment is the other end of the road: the kiosk in your space, on your network, used every day by your visitors, including the ones who cannot see the screen, cannot reach the top of it, or cannot hear the prompts. Between the two sits the whole process of procuring and setting up the kiosk, and every stage of that process is a place where accessibility gets locked in or locked out. A problem found early costs a conversation. The same problem found after installation costs money, time, and a fix that happens in public.
This post walks the whole road. At each stage, it names what has to be verified, and why. The checkpoints are here. The criteria and the procedures behind them are the consulting work, and I will come back to that at the end.
Start with the job the kiosk has to do
Before you look at a single model, write down the job. What will visitors use this kiosk for? Where will it stand? Who has to be able to use it, on their own, without asking for help? Accessibility requirements belong in that definition, at the start, not bolted on after the purchase order is signed.
Vendors sell features. You are buying an outcome: visitors completing a task independently. A kiosk bought for the wrong job cannot be tested into being right, and a definition of the job that forgets disabled visitors produces a kiosk that forgets them too.
What a demo tells you, and what it does not
When you stand in front of a unit, the hardware is real, and you can judge it: the size of the machine, the build, the screen, how a person approaches it and stands at it. That part of the demo earns its keep.
The software is another story. What runs on the demo unit is the vendor's application, presented the vendor's way. If you are buying that software along with the machine, you can and should test it yourself before you commit; that is a later stage of this process, and it matters. If you are building your own software, what runs on the demo is irrelevant to your decision. You are judging the machine, and the platform it gives your software to run on, not their application.
Selection: pick a machine that can be accessible
The enclosure and the input hardware decide most of the accessibility outcome before any software exists. Reach, the quality of the audio, and above all whether the kiosk offers a way to operate it without looking at the screen: these are hardware facts, and software cannot repair hardware that shuts people out. A kiosk with no non-visual path by design is disqualified, no matter what the software promises.
Many kiosks are a touchscreen and nothing else. If the model you like does not come with a tactile keyboard, make sure an accessible keyboard can be added to it, because the wrong choice is expensive to undo once the units are installed.
Get the compliance record, in writing, for hardware and software separately
Ask for the paper. For the software, that means a conformance report. For the hardware, the vendor's accessibility documentation. Which standards do they claim to meet, and who did the evaluating? A kiosk is usually two products, often from two different companies, so get the record for each part separately, and know which record covers which part.
The compliance record is a good start. Treat it as exactly that: a start. I have seen compliance records that were not thorough, and some that were not fully accurate, written by people who meant well and still missed things. Read the record, and then test against it, because later the record is all you have to rely on. It is what sits in your procurement file, and it is what your board will ask about if questions come. Make sure it holds up before it becomes your only evidence.
There is another case. If the software is not something you buy but something developed for you, there is no conformance report to request, because nobody has evaluated a product that does not exist yet. The work moves into the contract instead: the accessibility requirements themselves go into the development agreement, the standards the finished software has to meet and how meeting them will be verified. It is the same principle as the record. What is not written down will not be there to rely on later.
Look at one before you order
Before you order, spend time with an actual unit. An expo floor, a showroom, or one installed near you. A showroom unit already tells you a lot. Do not discount it just because it is not your installation.
The failures that matter most at this stage are physical and behavioral, and they do not appear on a spec sheet or a video call. Stand at the machine the way a visitor would. Reach everything. If it has a keyboard with a headphone jack, plug in and listen. One hour with a real unit teaches more than a month of brochures, and anything you find now is still free to fix, because you have not signed anything yet.
Put accessibility in the contract, not in the conversation
What you agreed with the vendor has to survive into the signed contract, with the compliance record attached. Acceptance terms belong there: how accessibility will be verified before the kiosk is accepted, who fixes what fails and by when, and what happens when a software update breaks something that used to work.
It is simply the difference between a promise and an obligation. Your leverage is never higher than before you sign, and the contract is the only version of the vendor's promises that still exists a year later, when the people who made the promises have moved on.
The screen reader decision
People often ask which screen reader they should choose for a kiosk, expecting a comparison. Right now the honest answer is simpler. For a kiosk, JAWS Kiosk is currently the only screen reader you can get. The real decision is not which screen reader. It is screen reader or no screen reader.
The alternative some vendors offer is prerecorded audio: prompts and instructions recorded into the software. It works, but it has hard limitations. It can only say what somebody recorded. Change the content and you record again. Give the visitor information that depends on the choices they just made, and the recording has nothing to say. I do not recommend it. It is not even the cheaper option it appears to be: the screen reader, with software built to be accessible, costs less than recording everything and re-recording it at every change.
My recommendation is the screen reader and accessible software. A screen reader speaks whatever the software presents, including the things nobody thought to record. I will go deeper on kiosk audio in another post in this series.
The good news here, Vispero, who makes the screen reader has been in business for over 30 years, what you will get from them will be tested and accessible. You may know them as Freedom Scientific which was their company name until recently.
Plan the physical setup before the unit arrives
Plan the physical setup before the unit arrives, because placement decides access. Where the kiosk stands determines the approach, what a visitor has to reach, the lighting on the screen, the noise around it, and how the queue flows past it. Power and network are the easy parts. An accessible kiosk installed in the wrong spot is an inaccessible kiosk.
Installation details are accessibility decisions. A unit that juts into a path is a hazard to a visitor using a cane. A screen washed out by window glare is unreadable to a visitor with low vision. A queue line that blocks the approach turns independence into a negotiation. None of these are software problems, and none of them can be fixed after the fact, so the considerations belong in the installation plan, with the measurements worked out before the unit is bolted down.
Configure it, test the real tasks, then sign off
When the kiosk arrives, set up your actual content and settings first. A kiosk tested with demo content has not been tested.
Then test the way visitors will use it: real tasks, end to end, in the actual space. Paying. Recovering from a mistake. Running out of time. Switching languages. Test with people who have different disabilities. The screen reader implementation will be the biggest accessibility task, and blind testers will find what simulation misses. They are not the whole picture. Low vision, limited reach or dexterity, hearing, and plain cognitive load all belong in the test, because your visitors bring all of them.
End the stage with a sign-off: an agreed acceptance point, with a named person responsible for saying the kiosk is ready. Decide what ready means before the kiosk reaches the floor. Once it is bolted down and announced, every fix costs more and happens in public.
Train the staff
A kiosk does not stand alone. The staff around it are part of the product and the service. They need to know the accessible features exist, how to point a visitor to them, and what to do when something breaks. This matters more than it sounds. Independence is the product you bought.
Deployment is a start line: updates and regression
Going live is not the end of accessibility. It is the start of keeping it. Software updates change behavior, and the kiosk that worked in April can silently break in October: a focus order shifts, a prompt disappears, a timeout shortens.
Accessibility is a property you keep, not a box you checked once. So before go-live, assign an owner to it: someone whose job includes re-verifying the kiosk after updates, and a simple way for visitors and staff to report when something stops working. The organizations that keep their kiosks accessible are not the ones that tested hardest once. They are the ones that never stopped paying attention.
The map and the work
That is the whole road: seeing a unit at an expo, defining the job, choosing the machine, reading the record, signing the right contract, setting the kiosk up well, and keeping it accessible after launch. This post is the map of that road, the stages and what has to be verified at each one.
Walking an organization through it, stage by stage, with the criteria in hand, is the work I do. If you are anywhere on this road, buying your first kiosk or trying to fix one that is already on the floor, let’s talk.