Playbook, SaaS company
A conformance statement, and somebody who cannot finish the form
Two completely different messages arrive under this heading. One is a row in a procurement pack from a buyer who needs a written statement with a date on it. The other is from somebody already paying who cannot complete a task with a keyboard or a screen reader. The first needs a document, the second needs a defect recorded, and neither is served by the sentence our product is accessible.
Why this is not the general answer
The handling pattern for accessibility requests holds across every trade. What follows is the part that does not.
- The buying version wants a written conformance statement with a scope, a date and a list of known exceptions, and nothing said in a chat window substitutes for that document.
- The support version is a defect report from a paying user, and it is only useful if it captures the screen, the assistive software and the version, none of which the person will think to include.
- Claiming a product is accessible without naming what was tested and when is the specific harm here, because that claim is pasted into a procurement pack and then contradicted by somebody trying to use the product.
- Some requests sit outside the product entirely, such as material supplied in another format or more time on a trial, and those are decisions for a person rather than facts about a feature.
How it arrives
- do you have an accessibility statement we can review
- can the product be used with a screen reader
- the date picker cannot be reached with a keyboard
- do you publish your known accessibility issues
- we need your documentation in an accessible format
- who do we contact about accessibility
What has to be indexed for this to work
| The accessibility statement, with its scope and its date | Which parts of the product were assessed, against what, when, and by whom. A statement without a scope and a date is not usable by a reviewer, and quoting one that lacks them puts you in a worse position than saying it is being prepared. |
|---|---|
| How a conformance document is requested | Who to contact, whether anything has to be signed first, and how long it takes. Reviewers are working to a deadline, and the route is the part that actually unblocks them. |
| The known issues list, with workarounds where they exist | Publishing gaps reads as credibility rather than weakness in this area, because a statement with no exceptions is the one nobody believes. It also gives a blocked user something to do this afternoon. |
| Who receives an accessibility request, and what you commit to | A named destination and a response period. Without one, these requests are answered politely by whoever is nearest and quietly go nowhere, which is the failure this pair exists to prevent. |
The reply
Our accessibility statement sets out what was assessed, when, and the exceptions we know about, and it is the document to use if you are reviewing us [1]. If you have hit something specific, that is worth reporting properly rather than working around: the team needs the screen, the assistive software and its version, and the browser [2]. I cannot test anything or tell you how a particular screen behaves with a particular tool. Leave your name, an email and those details and it goes to the person who handles accessibility.
It answers the buying question and the support question in that order, without pretending they are the same request. It asks for three specific things, because a report saying the site is not accessible cannot be acted on. And it refuses to characterise how any screen behaves with assistive software, which is the claim that would be quoted back.
Where it stops
The trigger. Any request for a conformance document, any report of a barrier in the product, and any request for material in a different format.
This needs the person who handles accessibility rather than a page. Leave your name, an email, and if you are reporting a barrier, the screen, the assistive software and its version, and it will go across today.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never claim conformance to any standard beyond what your own published statement says, including saying the product is fully accessible.
- Never state that a screen works with a particular screen reader or assistive tool, since that is a test result rather than a document.
- Never treat a barrier as a preference, or offer a workaround as though it settled the matter.
- Never promise a fix, or a date for one.
Questions
- Our statement lists real gaps. Should it quote them?
- Yes. A reviewer trusts a statement with exceptions in it and distrusts one without any, and a user who is told about a known gap and a workaround is treated better than one who is told everything works. The gaps are the credible part.
- Can it complete an accessibility section in a buyer's template?
- No. It answers in chat with references back to your own statement, which lets a reviewer verify each claim at source. Transcribing that into their document, and attesting to it, is a person's job with a person's name attached.
- Should the widget itself be part of the assessment?
- It should. Anything a visitor has to interact with on your site belongs in the same scope as the rest of the page, and a support channel that some visitors cannot use is a poor advertisement for a statement about accessibility.
Keep reading
- Everything for a SaaS companyOne widget serves prospects, trialists and paying customers. What it can answer about plans and limits, and what has to reach a person.
- Handling accessibility requests in generalTwo different things arrive as one message. A published accessibility statement answers the first. The second is a request, and it needs a person.
- The angry message is from an administrator with a renewal comingReliability, a capability moved to a higher tier and a bill in dispute. Where a paying team's complaint goes, and what is never conceded.
- Somebody wants into the beta, and the answer is not a dateAn invite queue for an unfinished capability is not a line. What may be said about early access, and why no date may be given.
- It is the middle of the night somewhere and the product is still runningThe software runs all night and the team does not. What to publish about coverage windows, time zones and plan based response times.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.