ReLiC Query · Accessibility

Accessible Tabletop Play

Accessibility is not one feature. Different players encounter different barriers, and the useful question is usually: what information, action, timing, or communication channel does this person need in order to participate?

Start with the player, not the diagnosis

Two people with the same disability may use different tools and prefer different accommodations. Ask what makes play easier, what creates friction, and what fallback works when the primary channel fails. Avoid making a player disclose medical information they do not want to share.

Do not make one sense carry essential information

For digital play, important information should not depend only on an image, only on color, or only on sound. WCAG 2.2 requires text alternatives for non-text content, and Microsoft’s gaming accessibility guidance similarly recommends additional channels for important visual and audio cues. In tabletop terms, a map marker can also have a text label; a warning color can also use an icon or word; an audio cue can also appear in text.

GM practice

• Say out loud when a token, condition, target, or scene state changes if a player cannot reliably perceive the visual change.
• Do not use red-versus-green alone for ally/enemy, safe/dangerous, success/failure, or status information.
• When an image contains decision-relevant information, describe that information instead of merely saying that an image is present.

Blind and low-vision players

RNIB notes that sight loss is a spectrum and that different players may rely on different strategies, including larger text and stronger contrast. A useful tabletop session therefore needs more than one visual mode.

GM practice

• Describe spatial relationships with stable reference points: “the doorway is ten feet north of you” is more useful than “over there.”
• State changes to range, adjacency, cover, hazards, and movement when those changes matter to a decision.
• Read or provide important handouts in text form rather than requiring visual inspection of an image.
• Let the player choose whether they want concise descriptions or fuller scene narration; more words are not automatically more accessible.

Deaf and hard-of-hearing players

Microsoft’s subtitle and caption guidance distinguishes subtitles, which represent speech, from captions, which also convey important non-speech audio information. The same principle works at a tabletop: dialogue alone is not the only information that may need a text equivalent.

GM practice

• Provide a text channel for rules calls, names, clues, numbers, and other information that is easy to mishear.
• Identify who is speaking when several people are talking or when speaker identity matters.
• If music, alarms, knocks, footsteps, or other sounds affect decisions, state their meaning in text or another visible form.
• Reduce overlapping speech. A clear turn-taking norm often helps everyone, not only players with hearing loss.

Speech and communication access

A player does not need spoken voice to roleplay. Communication can be typed, selected, signed through an interpreter, synthesized, or relayed through another agreed method.

GM practice

• Accept typed declarations and dialogue as equal participation, not as a lesser substitute.
• Do not require rapid verbal response to prove character intent.
• Pause long enough for augmentative or text-based communication before moving the scene forward.
• Agree in advance on a quick signal for “I am composing a response” so silence is not mistaken for disengagement.

Motor and input accessibility

Microsoft’s input guideline recommends allowing players to operate interfaces through input mechanisms of their choice and specifically identifies mouse-only interaction as a potential barrier. For digital tabletops, important actions should ideally have alternatives to precise dragging, repeated clicks, or time-sensitive input.

GM practice

• Allow another player or the GM to move a token when the player requests it while the player retains decision authority.
• Offer typed coordinates, menu selection, keyboard activation, or another alternative when drag-and-drop is difficult.
• Avoid punishing slow physical input with in-world consequences unless speed itself is knowingly part of the agreed game.

Cognitive, learning, and reading accessibility

W3C notes that cognitive and learning disabilities can affect perception, memory, language, attention, problem solving, and comprehension. Helpful design patterns include adaptable presentation and enough time to read and use content.

GM practice

• Present the immediate choice before optional detail.
• Keep recurring terms consistent. Renaming the same mechanic or location for flavor can increase memory burden.
• Maintain a short written summary of current goals, important names, and unresolved clues.
• Break dense rules explanations into steps and let players ask for the short version without embarrassment.
• Do not assume that a player who needs reminders was not paying attention.

Timing and turn pressure

Accessibility can be affected by limited time to read, process, communicate, or physically enter an action. W3C’s accessibility guidance includes providing enough time, and Microsoft’s game accessibility guidance includes time limits as a distinct accessibility concern.

GM practice

• Tell players before using a real-world timer.
• Provide a non-timed alternative when speed is not essential to the game’s purpose.
• For complex turns, allow a player to prepare a declaration while another turn is resolving.

Remote play needs redundancy

Online sessions fail in ordinary ways: microphones cut out, video freezes, connections drop, and chat can lag. Accessibility improves when the table has a known fallback.

• Keep a persistent text channel for critical information.
• State how a disconnected player’s character will be handled before it happens.
• Put key state—initiative, current objective, conditions, or turn owner—in a place players can re-check instead of relying only on memory.

A practical accessibility check before session one

1. Can every player receive essential information?
2. Can every player communicate a decision?
3. Can every player perform or delegate required interface actions?
4. Can every player get enough time to perceive, process, and respond?
5. Is there a fallback when voice, video, mouse input, or another primary channel fails?
6. Have you asked the players what actually works for them?

What this guide does not claim

This is practical guidance, not a certification, legal compliance determination, or promise that any particular VTT is accessible to every person. WCAG and the Xbox Accessibility Guidelines cover more detail than a tabletop article can reproduce, and direct testing with disabled users remains essential.

Reviewed against the linked sources August 30, 2026.