Guides

Screen Reader Support with open-source tools

Transforming a standard MUD interface into an accessible environment requires minimizing verbal noise while maximizing information density. This guide focuses on streamlining output streams, implementing non-visual feedback via GMCP, and configuring client-side triggers to improve the experience for blind and low-vision players using screen readers like NVDA or JAWS.

4-8 hours6 steps
Screen Reader Support with open-source tools hero illustration
1

Implement a Text-Only Toggle

Create a server-side command (e.g., 'SET ACCESSIBILITY ON') that disables all ASCII art, maps, and decorative borders. Screen readers struggle with non-alphanumeric characters used for visual flair, often reading them as individual punctuation marks which creates significant audio lag.

⚠ Common Pitfalls

  • •Inconsistent implementation across different zones or legacy codebases
  • •Hardcoded borders in combat scripts that bypass the toggle
2

Streamline Prompt Verbosity

Screen readers read the prompt line every time the user enters a command or a tick occurs. Configure a 'compact' prompt mode that limits output to essential stats (HP, Mana, Move) without labels or decorative separators. Ideally, move these stats to out-of-band communication (GMCP) so the client can handle them silently.

prompt_handler.lua
function format_accessible_prompt(hp, max_hp, mp, max_mp)
  return string.format("H:%d/%d M:%d/%d>", hp, max_hp, mp, max_mp)
end

⚠ Common Pitfalls

  • •Dynamic prompt updates during combat causing the screen reader to restart the line repeatedly
3

Configure GMCP for Status Monitoring

Use GMCP to send character status, room VNUMs, and inventory changes. This allows the MUD client (like Mudlet) to track state without cluttering the main text buffer. Sighted players use bars; screen reader users need this data available for custom keyboard shortcuts that query status on demand.

⚠ Common Pitfalls

  • •Sending updates too frequently (e.g., every 0.1 seconds) which can overwhelm the client's processing buffer
4

Develop Audio Cues for Combat Events

Replace or augment text-based combat notifications with distinct audio files (WAV/OGG). Use client triggers to detect specific patterns like 'You miss' or 'Target is dead' and play a unique sound. This provides immediate feedback without waiting for the screen reader to finish reading a long line of text.

combat_triggers.lua
if string.find(line, "You land a crushing blow") then
  playSoundFile(getMudletHomeDir() .. "/sounds/hit_crit.wav")
end
5

Establish Buffer Redirection for Chat Channels

Redirect global chat channels (OOC, Gossip, Newbie) to a separate virtual buffer or window. This prevents 'chat spam' from interrupting critical room descriptions or combat messages. Provide a command or shortcut for the user to read the last 5-10 lines of the chat buffer specifically.

⚠ Common Pitfalls

  • •Screen readers failing to focus on the secondary window automatically
  • •Missing urgent private messages because they were redirected without an audio alert
6

Verify Output with Screen Reader Interruption Settings

Test the output using NVDA. Ensure that the MUD client is configured to 'interrupt' speech for new lines if desired, or that the server-side 'brief' mode is optimized to provide the most important information (like exit names) at the beginning of the line rather than the end.

⚠ Common Pitfalls

  • •Important information (like 'A dragon enters') being buried at the end of a long paragraph of room description

What you built

By prioritizing structured data over decorative text and providing audio alternatives for timing-sensitive events, you create a playable environment where screen reader users can compete and interact on equal footing with sighted players. Regular testing with actual assistive technology is the only way to ensure these implementations remain functional.