Accessibility in a chat client: what a reader is owed

A chat client is not a private tool for the person who wrote it. It is read by people who arrived with a keyboard, a screen reader, a bright window behind them, or a text size they set years ago. Accessibility here is not a feature list; it is the minimum a reader is owed. The same duty runs through congregation sites, and The Church Web Review follows it for the volunteers who hold those sites up.

What makes a site usable for blind or low vision readers?

A screen reader does not see the interface. It reads a tree of roles, names and states, and it acts on whatever the tree exposes. A button drawn as an icon with no accessible name is announced as "button" and nothing else. A field labelled only by a picture of the word "Search" has no name at all. A dialog that traps focus inside itself and offers no way out is a room with the door painted on.

The practical rules are old and stable. Every control carries a real text label, not a placeholder that vanishes on the first keystroke. Headings are marked as headings, in order, so a reader can jump between sections instead of walking every line. Focus is visible, and it moves in a predictable sequence. Status changes, a message arriving, a connection dropping, are announced through a live region rather than only drawn. None of this requires a redesign; it requires that the markup say what the thing is.

How do captions, contrast and text size help deaf, colour blind and older readers?

Sound that carries information needs a text equivalent. A voice call has no caption track by default, so a client that offers one should also offer a transcript pane, and the transcript should be selectable text, not an image. Where a notification is a tone, the same event needs a visible line.

Contrast is measured, not judged by eye. The usual threshold is 4.5 to 1 for body text and 3 to 1 for large text and interface borders. Colour must never be the only signal: a green dot for online and a grey dot for away fails for a reader who cannot separate the two, so the state also needs a word or a shape. Text that can be enlarged to 200 percent without the layout breaking is the other half of the same promise, and it is usually broken by fixed pixel heights on rows and panels.

What should a small volunteer team fix first?

Start with a review, not an audit. An audit is a document nobody finishes. A review is a handful of pages, a fixed order, and a dated list of faults. Pick five screens: sign in, the contact list, an open conversation, the settings panel, and the error state when the server is unreachable. Walk each one with the keyboard alone, no mouse. Then walk it with a screen reader. Then at 200 percent zoom. Then in a bright room.

Write down what fails, with the screen name and the date. Do not fix anything during the walk; the point is the list. When the list is written, sort it: anything that blocks a task entirely comes first, then anything that misleads, then anything cosmetic. A team of three can hold five screens in one sitting. The list from that sitting is worth more than a specification nobody has read.

Keyboard alone is the cheapest test there is

Unplug the mouse, or ignore it. Tab through the client and watch two things: where the focus ring goes, and whether it is visible at all. A focus ring removed for looks is a client that cannot be used without a pointer. Then check the order. Focus should move left to right, top to bottom, and it should not jump into a panel that is hidden.

Escape should close what opened. Enter and Space should activate what is focused, and they should not do different things on the same control. Arrow keys inside a list should move within the list, not out of it. These are conventions, and conventions are what a reader already knows before arriving. A client that invents its own is asking every reader to learn it again.

Motion, autoplay and the cost of a moving interface

Movement pulls attention whether the reader wants it or not. A blinking indicator, a looping animation, a video that starts on its own, all of these compete with the text the reader came for. The rule is small: keep moving, blinking and auto playing elements to a minimum, and give every one of them a stop. A client that plays a sound on every message needs a switch that turns it off, and the switch needs to be findable without reading a manual.

Where motion is decorative, it can be removed. Where it carries meaning, such as a typing indicator, it needs a text equivalent as well, because a reader using a screen reader will not see it. The same discipline applies to congregation sites, where a home page that opens with a full screen video and no pause button asks the visitor to wait for the thing they came to read. The magazine The Church Web Review treats that case directly, alongside captions for live streams, contrast for older readers, and the question of where a volunteer team begins when nobody on it has done this before.

Labels, states and the difference between the two

A label says what a control is. A state says what it currently does. A toggle labelled "Notifications" with no announced on or off value is half a control. A connection indicator that changes colour but announces nothing is invisible to a reader who is not looking at it. Both need to reach the accessibility tree, and both need to change when the underlying value changes.

This is where a small client usually fails quietly. The visual design is fine, the mouse works, and the fault only appears when someone reads the interface instead of looking at it. That is why the review order matters: keyboard first, screen reader second, zoom third, bright room fourth. Each pass catches a different class of fault, and the list from all four is short enough to act on.