AI tool interfaces keep explaining themselves: Which copy should go, and which must stay?
We checked the stop-describing-ui rules and used HotAI’s QR code implementation to examine input requirements, error messages, and download feedback. No user-outcome experiment was conducted.
What to consider
Keep text that affects the user’s next action. stop-describing-ui favors specific action labels over feature descriptions, but explicitly retains destructive consequences and restrictions that users would otherwise discover by failing. In HotAI’s QR tool, empty-input errors and retry guidance must stay; a successful generation also needs a clear download action. This article compares the repository’s rules, WCAG explanations, and our implementation. It does not measure task-completion rates after copy changes.
The rules retain conditions that prevent real mistakes
As of the review date, the README illustrates empty states and toggles, with the full rules in skills/stop-describing-ui/SKILL.md. The skill replaces generic feature descriptions with specific action verbs and removes explanations already conveyed by the page. It also has exceptions: irreversible consequences such as deleting data must remain, as must permission restrictions that users would otherwise discover by attempting an action.
These are interface-writing recommendations, not a substitute for accessibility requirements. The skill generally removes backend details, but a statement that affects whether someone will upload material still needs an accurate explanation of the actual processing. Decide whether a sentence prevents a real mistake rather than counting how many words disappear.
Use the QR implementation to justify specific copy
HotAI’s QR generator reads the input, trims leading and trailing whitespace, and checks whether anything remains. Reader mode first checks that an image has been selected; file selection also checks type and size. Keep the guidance that lets the user continue, rather than replacing every branch with one generic failure message.
The table follows actual branches in vendor/file-converters/qr-code.js and common.js to explain why the existing messages are useful. It is not a before-and-after user study. Generating an image and extracting a QR payload produce different results, so their buttons should retain different action labels.
| Condition | Current message | Information to retain |
|---|---|---|
| Whitespace-only input | Enter text or a link. | Identify the missing input so the user can supply it |
| No QR image selected | Select a QR code image first. | Point to the next action: select a file |
| No QR code found in the image | No QR code was found. Upload a clear image containing the complete code. | Distinguish decoding failure from a missing file |
| QR image generated | The QR code is ready. Download it to save a copy. | State that an image is ready and how to save it |
Make errors and completion states perceivable
WCAG 2.2’s error-identification guidance calls for a text description of automatically detected input errors. A red border or exclamation icon may support that message but cannot replace the explanation. HotAI asks for missing input and separately asks users to shorten oversized content; these failures need different recovery actions.
The status-messages guidance covers result notifications that do not move focus. Adding a QR image does not establish that a screen-reader user knows generation has finished; completion needs an appropriate programmatic announcement. We did not test screen-reader compatibility and do not claim that the whole page conforms to WCAG.
After removing prose, check that the task still works
A repeatable check can start with ordinary text, followed by whitespace, to see whether the message guides the user to supply input. Then upload an image without a QR code and check that the page explains the decoding failure instead of presenting it as completion. These are proposed checks, not pass results obtained for this article.
This review checked the upstream rules and status branches in our code. We did not install the third-party skill, time user tasks, or interview users. A later comparison should keep inputs and devices consistent and observe whether people can find the download and recover from errors. Fewer words alone do not establish an efficiency improvement.
Checked sources
The following sources support the project descriptions and reported facts. The analysis is by the site editors; claims from these sources are not presented as results from our own tests.