How do you translate screen reader announcements accurately when an app, website, or accessibility test recording speaks labels, roles, and changing control states aloud? Begin by identifying what the assistive technology is announcing: the name of an element, its type, its current state, its position, or a status change. Then translate the information without changing what the user can operate or what the interface has actually done.
This guide explains how to translate screen reader announcements, spoken accessibility test recordings, and narrated assistive-technology interactions into clear written text or another language. It covers buttons, links, headings, checkboxes, switches, error messages, live regions, keyboard focus, and ambiguous synthetic speech. It is written for translators, teachers, testers, designers, and language learners who need to understand the difference between spoken interface output and ordinary conversation.
The critical rule is that a screen reader is often describing an interface state, not issuing a command. “Checked” means the control reports a selected state; it does not necessarily tell the user to check it. “Button” identifies a control role; it does not mean the speaker has pressed that button. The difference is small in writing and enormous in use. Accurate translation protects the user’s mental model of the interface.
Understand what a screen reader is saying
A screen reader is assistive technology that presents information from a digital interface through speech and often braille. It may announce text, element labels, structure, and the current focus or selection. The audio is generated from the application, the browser, accessibility information, and user settings; it is not necessarily a human narrator reading a prepared script.
That distinction matters because the phrases are compressed. A screen reader might announce “Search, edit text, blank,” combining an accessible name, a control type, and a current value. A translator hearing only the audio might render it as an instruction to search or edit blank text. But the announcement may simply indicate that focus is inside an empty search field. Accurate translation requires reconstructing the relation among the parts.
If a recording includes a tester speaking simultaneously with the screen reader, keep the voices separate. The tester may say, “I expected an alert,” while the screen reader announces only “Saved.” One is an evaluation; the other is an observation of output. Combining them can make the screen reader appear to claim more than it actually did.
Learn the basic vocabulary of accessible interfaces
Five concepts explain much of the audio: accessible name, role, state, value, and focus. The accessible name identifies an element for the user, such as “Submit application.” The role says what kind of element it is, such as button or checkbox. The state may say whether it is checked, selected, expanded, or disabled. A value can be text in a field or a number in a slider. Focus indicates where keyboard interaction currently applies.
These concepts are useful because they are not interchangeable. “Expanded” does not mean “selected.” “Unavailable” may describe a disabled operation, not an absent file. A value of five is different from a position of five within a list. Translators should capture each semantic component rather than choosing a single attractive phrase that discards half of the announcement.
For a technical foundation, the W3C overview of WAI-ARIA explains how roles, states, properties, and live regions help expose interface semantics. The translator need not become an accessibility developer, but understanding these distinctions prevents ordinary vocabulary from distorting what the interface tells the user.
Establish what the recording is intended to show
An accessibility recording may demonstrate successful navigation, reproduce a bug, train users, or compare the output of two screen readers. The purpose determines what must be retained. In a bug report, an awkward or incorrect announcement is often the main evidence and should not be silently corrected. In a user guide, the translator may explain the intended meaning separately, provided the recorded output remains distinguishable.
Identify the software, device, assistive technology, language setting, and recording date when those details are available. Do not invent them. The same page can sound different depending on platform, screen reader, browser, verbosity settings, and user preferences. A phrase familiar on one system may not appear verbatim on another. Translation should describe what was recorded, not pretend the sample represents every configuration.
Write the task in a sentence: “The tester moves through a form and checks whether labels and errors are announced,” or “The trainer shows how to open and close a menu with the keyboard.” This statement helps distinguish meaningful output from incidental screen reader speech.
Separate the human voice from synthesized speech
In many recordings, two speech tracks overlap: a person narrating their test and synthetic audio produced by the assistive technology. The person might say, “Now I press Enter,” while the screen reader announces “Navigation menu, expanded.” A translation that merges the two into one quote can reverse chronology or attribution.
Use speaker labels or an equivalent typographic convention. “Tester:” should introduce the human’s commentary. “Screen reader:” should introduce the software announcement. Where attribution is uncertain because the voices sound similar, compare with the visual cursor, microphone quality, timing, and known speech output settings if available. Do not assign a claim to a named person because their voice resembles the synthesis.
This careful separation also applies to AI voiceovers and recorded demonstrations. See how to translate AI voiceovers and text-to-speech narration for the broader risk of confusing generated speech with human authorship.
Translate roles as roles, not ordinary objects
A screen reader announcing “button” gives the user a clue about possible interaction. Translating it as “press” changes a description into a command. Similarly, “link” is not always the same as “page,” and “tab” is not necessarily a browser tab; it may be a tab control within a single view. The role belongs to the element’s semantics, not to a narrator’s preference.
Keep a role glossary for common interface terms: button, link, heading, list, list item, checkbox, radio button, switch, slider, combobox, dialog, and navigation region. The proper target-language wording should match established accessibility terminology where available. Where no familiar equivalent exists, a short explanatory phrase may help readers understand the control’s function without disguising its formal role.
Do not assume that a visually styled component behaves according to its appearance. A control may look like a button while being announced as a link because of its implementation. In an accessibility test translation, that mismatch may be the very defect the tester is documenting. Preserve the observed announcement and describe the visual discrepancy separately.
Keep control states precise
States tell users what is true now. Common announcements include checked, not checked, selected, not selected, expanded, collapsed, disabled, required, and invalid. They should not be smoothed into generic words like “active” or “ready,” because those may conceal important differences. A disabled checkbox can still be checked. A selected tab may not be expanded. An invalid field may still contain text.
When a target language distinguishes completed actions from ongoing states, make sure the translation reflects the original output. “Checked” in a screen reader announcement usually reports the checkbox’s current state, not proof that the user has just checked it. A phrase such as “the box has been checked” might imply an action occurred when the recording only established a state.
Test state translations with a two-row comparison: before and after interaction. If a user toggles a switch and the audio changes from “off” to “on,” the translation should preserve those values and their timing. It should not replace them with “disabled” and “enabled” unless the source and role justify that distinction.
Recognise that focus is not activation
Keyboard focus tells the user which control is currently targeted. Moving focus onto a button does not necessarily press it. A screen reader may announce a button name and role simply because the user reached it with Tab. If the translator writes “the Save button is clicked,” the record may falsely claim that a save occurred.
Track focus and action separately. Focus movement may use Tab, Shift+Tab, arrow keys, swipe gestures, or screen reader navigation commands. Activation may use Enter, Space, a touch gesture, or another input. The precise behavior depends on the element and platform. Preserve the demonstrated input sequence when creating a tutorial, and avoid inferring activation from an announcement alone.
In a test report, make the distinction visible: “Focus moved to the Save button; the screen reader announced its name and role.” If the recording later shows the button being activated, report that as a second event with its own evidence. Clear separation is essential for reproducible accessibility testing.
Handle headings and landmarks as navigation cues
Screen readers often announce heading levels and structural regions, such as “heading level two” or “main region.” These are not decorative details. They tell a user where content sits in a page hierarchy and how to navigate efficiently. A translator who drops the level number may remove information needed to understand the interface structure.
Keep hierarchy consistent. “Heading level three” does not become simply “title” if the task involves evaluating page structure. Similarly, a navigation landmark differs from a generic list of links. These distinctions matter in long pages where users jump between regions rather than reading linearly.
For nontechnical audiences, explain the convention once in a note: the screen reader announces structural information alongside the visible words. Do not insert an explanation into every quote. The goal is to preserve a usable transcript without overwhelming the learner with repetitions that do not belong to the original sequence.
Translate alerts and status messages with their urgency intact
Dynamic interfaces announce changes without requiring users to move focus. A form may say “Saved,” “Three results,” or “Payment failed.” Some status messages are advisory; others are urgent alerts. The translation must keep the event and severity accurate. “Payment pending” is not “payment successful.” “Error” is not merely “notice.” The stakes can be practical and immediate.
WAI-ARIA distinguishes live-region behaviors and roles that convey changing status to assistive technology. The W3C ARIA guidance provides an entry point for these concepts. In transcription, describe what the screen reader actually announced and when it happened. Do not state that every implementation will interrupt speech or read all updates identically, because assistive technologies and settings may differ.
If a recorded alert was not spoken when expected, that absence can be a test finding. Do not repair the transcript by adding the message the tester wanted to hear. A faithful translation represents both the expectation and the observed silence as distinct facts.
Distinguish a label from the text field’s value
An input may have a label such as “Email address,” contain a value, and expose additional instructions such as “Required.” A screen reader may announce these items in one stream. The translator should identify which words are the field name, which are user-entered content, and which describe requirements or errors.
This matters for privacy. A recording may speak aloud a real email address, name, or account number while demonstrating a form. Public translation must follow the approved disclosure policy. Do not repeat private content just because the voice pronounced it. If the source has been redacted, preserve that boundary in the translated transcript rather than reconstructing an identifier from the audio or display.
For related guidance, see translating redacted transcripts without exposing private information. Accessible delivery and responsible data handling are compatible obligations, not competing goals.
Keep numbers, positions, and quantities distinguishable
An announcement such as “item 3 of 12” gives a position in a set. It is not the same as the value three, a third-ranked search result, or a count of three selected items. A slider might announce “50 percent,” while a listbox might announce “option 5 of 8.” A translator should preserve the relationship identified by the interface.
Create a notation standard for positions, values, and counts. When the target language naturally orders the pieces differently, keep their logical roles stable. “Five results found” should not become “result number five found.” “Step two of three” is not “two steps completed.” These small slips can confuse navigation and make the transcript appear to contradict the display.
When the source speaks dates or times, verify whether it is reading content, a time selection, or a system clock. Do not convert a spoken time to another time zone unless the project explicitly requires that transformation and its reference context is known.
Handle pronunciation, abbreviations, and symbol names
Synthetic speech may pronounce acronyms, file extensions, punctuation, and unusual labels in unexpected ways. A screen reader could read a sequence of letters individually, sound it as a word, or expand a symbol according to settings. The transcript should represent the underlying announced information as accurately as possible while preserving evidence of a problematic pronunciation when pronunciation is the subject of the test.
If a symbol is important—such as an asterisk marking a required field, a slash in a path, or a minus sign in a number—do not silently omit it. If the screen reader says “star,” investigate whether it refers to an actual star icon, an asterisk, or a spoken literal word. The visible interface and accessible name can help, but they do not automatically override the audio.
For a learner-facing article, you can provide both the literal source announcement and an explanation. For a formal bug report, the exact spoken output and the expected output may need separate fields. Preserving this separation makes the report reproducible and keeps translation from hiding the problem.
Know when not to translate a command string
Some accessibility demonstrations include keyboard shortcuts, code snippets, URL fragments, or literal commands. A translator should not translate machine-readable strings if doing so would make them unusable. “Press Control plus L” is an instruction involving keys. “Enter /settings/profile” includes an exact path. A name like aria-expanded identifies a technical attribute rather than ordinary English words to be freely paraphrased.
Translate the explanation surrounding these items, but retain exact characters where necessary. If there is an established localized name for a key or technical role, use it consistently while making the literal input unambiguous. A short glossary can distinguish “spoken as” from “type exactly.”
When a tutorial uses an operating-system-specific shortcut, do not replace it with an unverified equivalent for another platform. You can explain that alternatives may differ by environment, but the source recording remains evidence of one demonstrated configuration.
Preserve error messages and failure states
Screen reader test recordings frequently document failure. An input might be invalid even though the visual page looks acceptable. A popup may open without announcing its title. A button may have an empty accessible name. The translated transcript should preserve these defects instead of smoothing them into an ideal user experience.
Suppose the screen reader says only “button” when focus reaches a visible Submit control. A weak translation might fill the gap with “Submit button.” That would conceal the accessibility failure. The accurate transcript says “button,” while a separate note may state that the visible control appears labelled Submit but its accessible name was not spoken. These are different evidential layers.
Similarly, if an error message was not announced, do not infer that it reached the user. A tester may see the error and complain that the screen reader remained silent. Preserve both observations. The difference between visible feedback and accessible output is often the exact reason the recording was made.
Handle live regions without inventing timing guarantees
A live region is a portion of an interface whose changes may be conveyed by assistive technology, depending on role, settings, and implementation. The words “polite” and “assertive” in ARIA describe intended announcement priority, not an emotional tone that should be translated as courtesy or aggression. Avoid literal social-language interpretations of these technical labels.
The actual screen reader output can vary. Some changes may be queued until the user is idle; others can interrupt speech or be omitted because of timing or implementation details. A translator should record the observed order and pauses rather than assuming a normative behavior from an attribute name. If writing a technical explanation, distinguish specification-level intent from the particular recording’s behavior.
The WAI-ARIA specification gives definitions of state and live-region properties. It can help a reviewer identify the intended technical meaning, but it should not be cited as proof that a specific page behaved correctly. That claim requires a test of the page and environment.
Distinguish accessible text from visible text
Some components have accessible names that differ from their visible labels. An icon may have an accessible name such as “Open navigation.” A visible button could say “Next,” while assistive technology announces “Next lesson.” Differences are not automatically errors; they may provide useful context. But the translator must keep the two sources distinct.
When the task is translating a test recording, quote the spoken accessible name and separately describe any visible label. If the task is localizing an actual application, the accessible name and visible label should be coordinated so that the user receives consistent meaning. A translation can be technically grammatical while making the two channels contradictory.
A useful review exercise is to place the visible label, accessible name, screen reader announcement, and target translation in adjacent columns. Check whether the distinctions are intentional and supported. Do not merely compare word lengths or claim success because all text strings have been translated.
Do not turn the transcript into a false accessibility certification
A transcript of a successful navigation sequence is evidence about that sequence, not proof that the entire site meets accessibility standards. Some readers may assume that because a screen reader speaks a button, the button is operable with all inputs. That conclusion does not follow. A control can have a label yet fail keyboard activation, focus order, status feedback, or other requirements.
Use calibrated language. “In this recording, the screen reader announced the button label” is a defensible observation. “The site is fully accessible” requires far broader evaluation. Translators and educators should model this distinction, especially when writing summaries for nontechnical audiences who may not know how accessibility testing works.
If the source author makes an expansive claim, translate it accurately while maintaining attribution. Do not independently endorse it through the surrounding prose. The goal is to help readers understand what the demonstration establishes and what remains untested.
A worked example: a newsletter signup form
Imagine a fictional test recording in which a tester tabs to an email field, types a sample address, moves to a checkbox, and presses a submit button. The screen reader announces “Email, edit text, required,” then “Updates, checkbox, not checked.” These exact words are invented for teaching, not taken from a particular device. They illustrate distinct information types.
A weak translation might say, “Enter an email and subscribe to updates.” That turns the state of an unchecked checkbox into an instruction to subscribe. A more faithful test transcript preserves the spoken labels, roles, and states: the Email control is required, and the Updates checkbox is currently not checked. If the tester later activates the checkbox, the transcript records the transition separately.
Now imagine the form reports “Email invalid” but does not move focus. A complete test record should preserve that the message was announced or that it was visible only. The translation must not conflate a sighted tester’s description with screen reader feedback. This difference determines whether the user could identify what to fix.
A second worked example: an expanding menu
Consider another fictional recording. The user reaches an account menu button. The screen reader announces “Account, button, collapsed.” After activation, it announces “Expanded,” and focus later moves to a menu item called “Profile.” The correct translation shows a state transition and subsequent navigation; it does not imply that a different page loaded merely because the menu expanded.
If the translator renders collapsed as “closed for maintenance,” the reader may think the feature is unavailable. If expanded becomes “enlarged,” the reader may imagine a visual resizing operation rather than a menu opening. The technical context is the safeguard. “Collapsed” and “expanded” describe the current disclosure state of that control.
Test the translation by asking whether a reader can predict the next interaction. After the menu expands, the user can navigate its items. After choosing Profile, a new destination may appear. Each event has its own evidence. Faithful ordering makes the transcript useful to both testers and language learners.
A third worked example: an unexpected live message
Imagine a learner is typing into a search box while a screen reader announces “Three suggestions available.” The learner has not chosen any suggestion yet. A misleading translation might say “three suggestions selected,” creating a false action. Another might say “three results found,” implying that the final search has completed when the interface may simply be offering autocomplete choices.
The correct treatment preserves what is known: the system announced that three suggestions are available. If the tester then navigates among suggestions, the recording may identify which one is focused or selected. Do not replace availability with confirmation. In interfaces that support dynamic suggestions, these distinctions are central to successful use.
This example also teaches a broader vocabulary skill. “Available,” “selected,” “focused,” “applied,” and “submitted” each describe a different stage. A translator who learns those relationships can write clearer instructions in many fields beyond accessibility.
Build a reliable transcription workflow
First, capture the source audio at a quality that makes the synthetic speech intelligible. Where possible, preserve the recording of the visual interface too. Second, identify separate voices and the environmental setup. Third, transcribe announcements literally enough to document their components, marking uncertain pronunciations and interruptions rather than guessing.
Fourth, annotate each announcement with its likely role—name, role, state, value, count, structure, or status—while keeping that analysis outside the quotation. Fifth, translate the announcement using a consistent accessibility glossary. Sixth, review the target against the audio and, when relevant, the visible application and test steps. Finally, test whether a reader understands the resulting sequence without conflating focus, activation, and state.
A modest issue log makes this manageable: timestamp, source phrase, source function, target wording, uncertainty, and decision. For a short classroom demonstration, the log may contain only a few entries. For a complex form, it can become a useful regression checklist when the application changes.
Choose a glossary that supports learning rather than memorization
Instead of collecting isolated translations of “selected” and “expanded,” group each term with its contrasting state and the kind of control that uses it. “Checked/not checked” often describes checkboxes. “Expanded/collapsed” often describes disclosure controls. “Selected/not selected” can describe items in a choice set. “Disabled/enabled” addresses availability for interaction. These are teaching relationships, not absolute descriptions of every implementation.
A glossary also benefits from negative examples. “Focus” is not “click.” “Required” is not “already completed.” “Alert” is not always “emergency.” “Navigation region” is not a street map. Learning these distinctions helps a translator resist familiar but wrong dictionary equivalents.
For broader language development, the eduKateSG guide to cross-linguistic transfer in vocabulary explains why a word that resembles a familiar term can still mislead. Accessibility translation is a precise example of that general learning challenge.
Make a companion guide usable for beginners
If the final product is a tutorial rather than a formal test transcript, include a short explanation before the sequence: a screen reader announces information about controls while the user navigates. Then give the reader enough context to distinguish the announcement from the required action. Use visible headings and concise paragraphs. Separate exact quotations from your explanatory wording.
You may want a short orientation such as “When you hear ‘button,’ focus is on a control; it does not mean the button has been activated.” Then walk through a real, verified example with the source audio and actions. Avoid using invented interface steps in a live help article. Fictional examples are useful for teaching concepts only when clearly labelled as fictional.
When preparing multilingual learning resources, include the source term, target equivalent, plain-language meaning, and an example of the interface state. This supports both technical accuracy and ordinary reading comprehension. The educational aim is to help learners understand what the spoken words are doing in context.
Evaluate the translation with a cold test
A cold test asks someone who has not seen the source transcript to read the translation and explain what is happening. Can the reader tell which element has focus? Can they distinguish whether the checkbox is checked? Can they identify the point when an error appears? If the reader thinks a button was pressed when the recording shows only focus movement, the wording needs examination.
A second test compares the target text directly against the recording. This catches cases where fluent phrasing removed a role, reversed a state, or attributed an announcement to the wrong speaker. Ask a reviewer familiar with the relevant accessibility terminology to inspect high-risk technical distinctions. Natural target-language editing should not silently change the semantics.
Document remaining limitations. The audio may be clipped, two voices may overlap, or the visual recording may be unavailable. A good report names what could not be verified. Clear boundaries make the translation more useful than an overconfident reconstruction.
Frequent translation errors and how to prevent them
The first error is changing descriptions into instructions. The second is treating focus as activation. The third is collapsing state words into generic adjectives. The fourth is merging human commentary with synthetic speech. The fifth is silently fixing the very defect an accessibility test records. These errors are common because all can produce fluent sentences that sound plausible to a nonexpert.
Catch them with a focused review pass. Underline every imperative verb and check whether the source issued a command or reported a state. Circle every word indicating checked, selected, expanded, required, disabled, or invalid. Check every speaker label. Compare every claimed interface event with the audio and visual evidence. This method is faster and more dependable than proofreading solely for grammar.
A final technical review should also inspect literal identifiers, shortcut keys, and exact announcement text when those matter to the test. Smooth prose is a benefit only after the state and event model is correct.
Frequently asked questions
Can I translate screen reader output as ordinary dialogue? Not safely. Screen readers often announce names, roles, states, and structural cues in compressed form. Translate those functions rather than turning the output into a conversational sentence with invented actions.
Does “button” mean the button was pressed? No. It commonly identifies the role of the focused element. Activation is a separate event that needs supporting evidence in the recording.
Are “checked,” “selected,” and “expanded” the same? No. They describe different states and may apply to different control types. Use the precise term appropriate to the source announcement.
Should I correct an awkward screen reader announcement in the transcript? If the task is documenting accessibility behavior, preserve the observed output. You may add an explanation or recommended fix separately, but do not silently replace the evidence.
Can translation alone prove a site is accessible? No. A translated recording documents a particular interaction under particular conditions. Accessibility evaluation requires broader testing than one spoken sequence.
A more useful way to hear interface language
Screen reader announcements teach an important lesson about translation: a small word can describe a large change in state. The difference between focused and activated, available and selected, or collapsed and expanded determines what the user understands they can do next. Capturing these distinctions accurately is as important as producing natural grammar.
Start with the recorded output, identify its functional parts, and keep the human tester’s comments separate from assistive-technology speech. Translate labels and states consistently, preserve technical strings, and test the resulting explanation against the interaction. The result is a clearer guide for multilingual readers and a more trustworthy record of what the interface actually announced.