Playbook, developer tools company
The interface is a terminal, so the usual accessibility answers do not apply
This heading normally means a web form somebody cannot complete. Here it almost never does. The surfaces are a command line tool that prints colour, an interface driven entirely from the keyboard, and a documentation site dense with code blocks and diagrams. Each fails in its own way, none of them is helped by a statement that the product is accessible, and most of what arrives is a precise, well written defect report.
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.
- Colour is doing real work in the output. Pass and fail, added and removed, warning and error are often distinguished by colour alone, which makes the result unreadable for some people and worthless in any log where the escape codes have been stripped.
- There is an established convention for suppressing colour and for detecting that output is not attached to a terminal, and whether your tool honours it is a factual, checkable question that belongs in your documentation rather than in a policy.
- A documentation site fails in ways an ordinary site does not: code blocks read aloud character by character, diagrams carrying the architecture with no text alternative, and copy buttons that cannot be reached without a pointer.
- The reader is usually technical enough to name the assistive software, the version and the exact step, so the report arriving here is far more actionable than in any other trade, provided the conversation actually asks for those three things.
How it arrives
- does the command line tool respect the no colour convention
- the diff output only distinguishes changes by colour
- your code blocks are unreadable with a screen reader
- can the interface be driven entirely from the keyboard
- the architecture diagrams have no text description
- is there a conformance statement we can send to procurement
What has to be indexed for this to work
| How the tool decides whether to emit colour | The environment variable it honours, what it does when output is redirected to a file or a pipe, and any flag that forces plain text. This is the most asked and most answerable item here, and it is one line once somebody writes it down. |
|---|---|
| Keyboard operation of any interactive interface | Every action reachable without a pointer, the focus order, and anything that is genuinely pointer only. Where something cannot be done from the keyboard, say so, because a list of what works is useless if it is silently incomplete. |
| The documentation site's own accessibility notes | How code blocks are marked up, whether diagrams carry text alternatives, and whether navigation is fully operable from the keyboard. Your documentation is a product surface and it is the one most readers meet before anything else. |
| The conformance statement, with a scope, a date and the known exceptions | Which surfaces were assessed, when, and what is known not to conform. Buyers ask for the document rather than for an assurance, and the exceptions list is the part that makes the rest of it credible. |
The reply
Colour output follows the usual convention: it is suppressed when the standard environment variable is set and when output is not attached to a terminal, and the flag that forces plain text is documented on that page [1]. Where colour is currently the only signal distinguishing a state, that is a defect rather than a setting, and it is worth reporting as one. For the documentation site, the accessibility notes cover the code block markup and the text alternatives on diagrams [2]. I cannot test anything or change how the tool behaves. If you tell me the command or the page, the assistive software and version, and what you expected instead, I will pass all of it on with your name and email.
It answers the colour question with the convention rather than with a policy, because a technical reader wants to know what the tool does and can verify the answer in a minute. Classifying colour only signalling as a defect rather than a preference is the honest call and it is what gets it fixed. The three things it asks for are exactly what somebody needs to reproduce it.
Where it stops
The trigger. The reader describes something they cannot do with their own setup, or asks for a conformance statement, an assessment date or a list of known exceptions.
This needs to reach the people who can test it and fix it, which I cannot do. Send me the command or the page, the assistive software and version, and what you expected instead, with your name and email, and it goes across as a report rather than as a question.
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 say the product, the interface or the documentation is accessible, because that claim gets pasted into a procurement pack and then contradicted by somebody trying to use it.
- Never state a conformance level, a standard or an assessment date that is not in your published statement.
- Never offer a workaround that requires the reader to abandon their assistive software or turn something off to proceed.
- Never treat a report of colour only signalling as a preference, since it is a defect and recording it as one is the entire point.
Questions
- Is a command line tool even in scope for this?
- Yes, and it is where most of the real problems live. Colour only output, progress indicators that repaint constantly and prompts that cannot be read in order all make a tool unusable for somebody, and none of that shows up in an audit of a web page.
- Can it raise the defect for us?
- No. It writes into nothing, so what happens is an email carrying the details it collected. That is still a large improvement on a report saying the docs do not work with a screen reader, which nobody can act on.
- What should we publish first if we have nothing?
- The colour behaviour and the keyboard notes. Both are short, both are factual, and between them they answer most of what arrives here. A conformance statement is a separate piece of work with a date and a scope attached.
Keep reading
- Everything for a developer tools companyOn a docs site an assistant competes with search, not a phone line. Version skew, deprecations and error strings decide whether it earns its place.
- 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.
- Can we get into the beta is a request rather than a questionEarly access programmes, regions that are not open yet and a library for a language nobody has written. What can be said without committing anyone.
- The deploy window is at night and nobody is at a deskChange windows and incidents both happen at night. What can honestly be answered overnight, and how a severity definition decides who is woken.
- Most complaints here are technically specific and frequently correctDeprecation deadlines, a change that broke a build, and a reader who is usually right. Answering without conceding or arguing the technical point.
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.