Accessibility: The Reader Who Cannot Watch

Thursday, 17:50, at Pennywell Books. Tom is closing the shop and the card terminal has lost its pairing with the till. This happens about once a month, and the knowledge base covers it with a video. He opens the article on his phone, standing at the counter with the last customer waiting. The shop has music playing and his phone is on silent, so the narration is lost. The video is a recording of a full desktop screen, which on his phone is a strip of grey with a cursor moving about on it. There are no captions. Under the video there is one sentence: "See the video above." He phones the desk. Forty miles away at head office, at the same moment, Amara in finance opens "Approve a purchase order". It has four screenshots and no text steps, and her screen reader says "image, image, image, image". Two readers, one knowledge base, and neither of them can watch.

Accessibility, for a help desk's pictures and videos, means that every reader can reach the same result from the same article. It does not matter whether they can see the picture, hear the sound or play the video at all. It is built from four things. First is a complete text alternative. Next are captions (the spoken words shown as text on the video). Then comes a transcript (the spoken words as plain text under it). Last is alt text (the sentence a screen reader speaks in place of an image). None of them is an extra. This article is part of our Visual & Video Guides series. It is about the readers the video was not made for, who turn out to be most readers, some of the time.

It covers who cannot watch, and why it is a large group. Next come the text alternative, always; captions; transcripts; and alt text for every image, with a table of bad and good. Then come the reader on a phone, the reader with the sound off, and colour, contrast and "the green button". A short war story and the accessibility checklist to copy finish the article, in that order.

Who Cannot Watch

The list is longer than the desk expects, and most of it is situational rather than permanent. Readers who are blind or have low vision use a screen reader, which speaks the page and can say nothing useful about a picture that has no alt text. Readers who are deaf or hard of hearing get nothing from narration without captions. Readers in an open-plan office, a shop, a library, a ward, a lecture or a meeting have the sound off and are not going to turn it on. Readers on a phone see a desktop recording as a postage stamp. Readers on a locked-down kiosk, a thin client or a machine with no speakers cannot play video at all. Readers who cannot tell red from green cannot follow "click the green button". And readers in a hurry, which is everyone with a ticket, want to search for the word they need, and a video has no words to find.

The permanent cases and the situational cases need the same fixes, which is the useful fact at the centre of this subject. The text steps that Amara's screen reader needs are the text steps that Tom, on a phone with the sound off, also needs. Search needs them too. The keeping-current article in this series needs them as the fallback when the screen changes. Captions written for a deaf colleague are the captions everyone in the open-plan office reads. Build for the reader who cannot watch, and every other reader gets a better article. The reader who cannot watch is not rare. It is you, in a meeting, with your phone under the table.

In many places and for many kinds of organisation, making help accessible is a legal duty as well as good manners. Which rules apply to yours is a question for whoever handles compliance. The answer does not change what the desk should do. A knowledge base is help, and help that only some staff can use is a help desk that has quietly decided which staff it serves. The desk did not mean to decide that. It recorded a video and forgot to write the steps down.

The Text Alternative, Always

The one rule from which the rest follows is that every picture and every video has a text route to the same result, in the same article, complete on its own. Complete means a reader with the images hidden and the sound muted can do the whole task from the words. The test takes two minutes and should be done before publishing: switch images off in the browser, mute the machine, and follow the article. Where you stall, the text is incomplete, and the picture or clip was carrying an instruction it should not have been carrying alone.

"See the video above" is not a text alternative. Neither is "as shown", "pictured below" or a caption that names the picture without saying what to do. The alternative is the numbered steps, each a complete action with the control named and located in words. That is exactly what the format decision in When a Picture Beats a Page of Steps requires for other reasons. It is exactly what Keeping Media Current When Screens Change relies on when the video expires. One set of text steps, three jobs: the alternative for the reader who cannot watch, the fallback when the screen changes, and the words that search finds. It is the cheapest thing in the article and the one most often left out.

Write the text first. Write the video script as one sentence per action, the method in The Ninety-Second Video. This produces the text steps, the captions and the transcript from one sheet before the recording exists. So the accessible version is not a retrofit; it is the source. Retrofitting text onto thirty finished videos is weeks of watching clips with a notepad. Writing it first is the same words, in the right order, for free.

Captions

Captions are the spoken words, and any sound that carries meaning, shown as text on the video in time with the speech. They come in two forms: open captions, burned into the picture so they are always visible, and closed captions, a separate text track the viewer switches on. Most video players and most knowledge bases that embed video accept a caption file alongside the clip; where yours does not, burn them in. Either way, the words come from the script sheet's narration column, so a video made the way this series describes has its captions written before it is recorded. The cost is the few minutes of lining them up with the speech.

Automatic captions, where the player or the recorder generates them from the audio, are a start and not a finish. They are tireless, confident, and occasionally fluent in a language nobody speaks. "Pair the terminal" arrives as "pear the terminal", and a system's name becomes three words that mean something else. Proofread every automatic caption against the script before publishing. Expect to correct the names of controls, which are exactly the words the reader most needs to be right. A caption that misnames the button is worse than no caption, because the reader with the sound off has nothing to check it against.

Style is plain. Use one line at a time, at the bottom of the frame, in a high-contrast box, placed so it never covers the control being clicked. If the control is at the bottom, the caption moves up for that step. Short sentences, which the script already has. Meaningful sounds in square brackets: "[the terminal beeps]", "[the light turns green]", because a reader who cannot hear the beep needs to be told it happened. No decoration, no colour changes, no animation. The caption is the narration for a reader who cannot hear it, and it should be exactly as boring as the narration.

Transcripts

A transcript is the narration as plain text, placed under the video on the same page. For a help video it is nearly the same thing as the text steps. If the narration was one sentence per action, the transcript and the steps differ only by the few remarks that were spoken but not stepped. Examples are "this takes about ten seconds" and "the light turns green". The fix is to add those remarks to the steps. Then the text steps are the transcript, and there is one block of text under the video instead of two that drift apart. Do not maintain a separate transcript if the steps can carry it.

The transcript is also what makes the video findable. A video's only door for search is its title. A transcript under it gives search every sentence of the narration. So a reader who types "terminal beeps twice" finds the article even though no title would ever contain those words. This is the same point made in the ninety-second video article from the other side. There, the title was the only thing search could see, and here is the cure. The reader who cannot watch and the reader who cannot find are helped by the same paragraph.

Where a video is long or has several parts, which this series discourages, the transcript carries the time of each part so a reader can jump to it. For example: "At 0:40, reassigning the delivery." For the ninety-second clip there is nothing to jump to, and the transcript is simply the steps. The screen reader reads them aloud in order, which is the video narrated, which is the video.

Alt Text for Every Image

Alt text is the sentence a screen reader speaks in place of an image, and every image in a help article has it. The sentence says what the image shows and what the reader should notice. For an annotated screenshot, that means the highlighted control and where it is: "The expense claim form; the Save button, at the bottom right, is boxed." For a photograph: "A thumb lifting the blue lever under the open lid of the label printer." For an image with numbered badges, the numbers and what each marks, briefly. It is never "image", "screenshot", "photo", the file name, or empty. It is never a repeat of the whole step above it, because the screen reader has just read that step.

One sentence is the right length, two at most. Alt text is spoken, so a paragraph of it is a paragraph the reader cannot skim and must sit through. A reader who wants the detail has the step text and the transcript for that. A good test is to read the alt text aloud to a colleague who cannot see the screen and ask them where the control is. If they can point, it works. The craft of the mark the alt text describes, one highlight, the right shape, is in Annotated Screenshots Done Well. Its style card includes the alt text line for this reason.

Photographs and screenshots that are purely decorative do not belong in a help article, so the question of empty alt text for decoration does not arise. If an image has no instruction in it, remove the image. Every image left has a job, and the alt text says what the job is. A reader who can see the picture never notices the alt text. A reader who cannot has nothing else.

The Reader on a Phone

The phone reader is standing up, in a hurry, with one hand busy and a small screen. The article was probably written on a large monitor by someone sitting down. Text steps serve them best: short, numbered, one action each, readable without zooming. Screenshots serve them only if cropped to the dialog, because a full-screen capture at phone width is a thumbnail of a screen. Video serves them only if it was recorded as a window with the text zoomed up, as the cheap-production article asks. Even then, it serves them only if the signal will carry it and the sound can be on, which at a shop counter it cannot. The layout that works is text first, media below, so the phone reader gets the steps without waiting for the clip to load.

Show the clip's length beside it and never autoplay. A video that starts itself on a phone with the sound on in a quiet ward is a video that gets the knowledge base banned from the ward. Keep clips small, which they are if they are ninety seconds of one window. And test on a phone, once per article, by opening it in the stairwell with the sound off and following it. If the steps can be followed with a thumb while the other hand holds a cable, the article works. Test on the oldest phone the desk owns, which is always the desk lead's.

Public articles are phone articles. An article that only staff at desks can see is read mostly at desks; an article open to everyone is read wherever everyone is. If you run QuerySolv, a knowledge base article visible to everyone is read by requesters wherever they happen to be. In practice, that means on a phone in a corridor as often as at a desk. So the public side of the knowledge base is designed for that reader first. The same applies to any tool with a public side: the moment an article leaves the building, it is on a phone.

The Reader With the Sound Off

Captions carry the narration to the reader with the sound off, and the video itself should still make sense in silence. It does if it was made the way this series describes. The cursor moves in a straight line, pauses, clicks and pauses, so the reader can see what was clicked and what happened. The click indicator shows the click. The result appears on screen. The narration may carry information that is not visible on the screen: "wait until the light on the terminal turns green", "you will hear two beeps". That information must be in a caption and in a text step. The silent reader cannot hear the beeps and the screen does not show the light.

A silent clip with captions is a legitimate way to make the video in the first place. The article Cheap Production That Looks Fine treats it as one of the two acceptable sound choices, the other being narration from a headset. What is never acceptable is a clip whose only account of itself is in the audio: no captions, no steps, a voice explaining things over a cursor. That clip helps the reader at a quiet desk with headphones and nobody else. The reader at a quiet desk with headphones is the one person who could have followed the text.

Music fails the silent reader twice. First, it adds nothing they can hear. It fails once more when the organisation's open-plan readers turn the sound off to avoid it and lose the narration too. The no-music rule in this series is usually argued on taste and on dating. Its accessibility argument is that music makes people mute videos, and muted videos need captions. The videos with music are the ones least likely to have them.

Colour, Contrast and "The Green Button"

No instruction relies on colour alone. "Click the green button" fails for the reader who cannot tell green from red. It fails for the reader whose theme shows the button in a different colour. It also fails for the reader on a monochrome screen reader who hears "button". Name the control by its label and its position: "Click Save, the button at the bottom right." The annotation on the screenshot can be coloured, because the step text beside it names the control in words. The colour is a pointer and never the only carrier of the instruction. Where two controls differ only by colour, a status light say, describe what else differs: "the left-hand light, which is lit when the terminal is paired".

Contrast matters for captions and badges. A caption in a light grey on a light screen is a caption nobody reads. The style card's choice of a strong highlight colour and a solid caption box is as much for this reader as for the one in a hurry. And avoid anything that flashes. A clip that flickers rapidly, a cursor effect that pulses, or a screen that strobes while loading can trigger seizures in some readers. Such flashing is unpleasant for all readers. The slow, steady cursor rule covers most of this; the rest is checking that nothing on the screen blinks fast during the take, and re-recording if it does.

A Short War Story: The Payment Approval Videos at Bluewater Bank

Bluewater Bank rolled out a new payments portal with a set of nine videos recorded by the desk. They were well made, narrated, and published without captions or text steps because the videos were, in the desk's own words, "the documentation". Dominic, a loans officer who is deaf, raised a ticket on the first morning asking for the written procedure for approving a payment. Sasha on the desk replied that a transcript would follow. That took three weeks, because there were no scripts and someone had to watch nine videos with a notepad. In the meantime Dominic approved payments by asking a colleague to watch the video and dictate the steps to him. The next audit recorded that as an approval control performed by two people with one login, which the desk had to explain. The rework meant nine script sheets reverse-engineered from the clips, captions proofread against them, and text steps under every video. It took six weeks of a technician's spare hours, and the audit finding took longer than that to close. The lesson Sasha wrote into the desk's publishing checklist was that the text alternative is written first. Writing nine scripts before recording would have cost an afternoon. Recovering them afterwards cost six weeks and an audit point.

The Accessibility Checklist

Run the checklist on every article that carries a picture or a clip, before it is published and again whenever its media is re-made. It is one page, joke-free, and it is checked by someone other than the author. Ideally, that is a colleague who uses a screen reader or captions every day, asked once, thanked, and listened to. The first section is the one that matters most; if it fails, nothing below it rescues the article.

ACCESSIBILITY CHECKLIST — EVERY PICTURE, EVERY CLIP
Article: _________________________________   Checked by (not the author): ______________

THE TEXT ALTERNATIVE
  [ ] complete numbered text steps in the same article, one action each, control named and located in words
  [ ] the task can be completed with images hidden and sound muted, following the text alone
  [ ] no step says only "see the video", "as shown" or "pictured below"
  [ ] text steps sit above the video or beside the image, not hidden behind a link

VIDEO
  [ ] captions present, covering every spoken sentence and every meaningful sound in brackets
  [ ] captions proofread against the script; names of controls correct
  [ ] captions placed where they never cover the control being clicked
  [ ] transcript under the video (the text steps, plus any spoken remarks not already in them)
  [ ] duration shown; no autoplay; no music; nothing flashes or pulses
  [ ] makes sense with the sound off: steady cursor, visible click, visible result
  [ ] anything carried only by the audio, such as a beep or a spoken wait, is also a caption and a text step

IMAGES
  [ ] alt text on every image: one sentence, what it shows and which control is marked and where
  [ ] no alt text that reads "image", "screenshot", "photo", a file name, or nothing
  [ ] numbered badges listed in the alt text with what each marks
  [ ] no instruction exists only as text drawn on an image
  [ ] every image has a job; decorative images removed

COLOUR AND CONTRAST
  [ ] no step relies on colour alone; controls named by label and position
  [ ] captions and badges readable against the screen behind them
  [ ] status lights or coloured states described by something other than colour

THE READER ON A PHONE
  [ ] article opened on a phone; steps readable without zooming
  [ ] screenshots cropped to the dialog; readable at phone width
  [ ] video recorded as a window with text zoomed; small enough for poor signal
  [ ] layout is text first, media below

Published: ____________   Media re-made (re-check): ____________   Owner: ____________

Tom's article at Pennywell is now six text steps and two cropped photographs of the terminal with one arrow each. Below the steps is a thirty-second silent clip with captions for the reader who wants to see the pairing dance. He re-paired the terminal from the steps the next time it dropped, standing at the counter, with the music on. Amara's "Approve a purchase order" has five steps and four screenshots with alt text. Her screen reader now says "the purchase order form; the Approve button, at the bottom right, is boxed". That is more than it said before, and exactly enough.

Frequently Asked Questions