MUD Accessibility

Table of Contents

1. The Blind MUD Community
2. Screen Reader Compatibility
3. Accessible MUD Design Principles
4. MUDs Known for Accessibility
5. MUD Clients for Accessibility
6. Technical Considerations
7. Implications for Our Urbit MUD

The Blind MUD Community

Why MUDs Are Uniquely Accessible

MUDs occupy a singular position in gaming: they are one of the only multiplayer game genres where blind and sighted players compete on genuinely equal footing. Because the entire game experience is conveyed through text, the fundamental medium is already compatible with screen readers and text-to-speech. No other mainstream multiplayer genre can make this claim.

This isn’t theoretical. The numbers back it up:

• Materia Magica reports that blind players form up to 50% of online users on some nights.
• MUDRammer (an iOS MUD client) found that 14% of its players were blind after implementing accessibility features – work that took roughly one day.
• Alter Aeon states that “nearly all of our players are blind or visually impaired.”
• Across the genre, an estimated 10,000 active MUD players globally continue playing across roughly 760 active MUD games tracked by MUDStats.com.

The blind gaming community has gravitated toward MUDs precisely because they don’t require the visual-first accessibility retrofitting that plagues mainstream gaming. The game is the text.

Community Hubs

AudioGames.net is the central hub for blind and visually impaired gamers. The site maintains a database of accessible games (including MUDs), and its forums host active discussions about MUD recommendations, client configuration, soundpack development, and accessibility feedback. MUD-related threads on AudioGames.net are among the most active in the community.

Other community spaces include:

• blind-gamers@groups.io – A mailing list where blind gamers discuss MUD clients, game recommendations, and accessibility issues. VIP Mud and Alter Aeon are frequently discussed.
• r/MUD on Reddit – ~20,000 members; accessibility threads appear regularly with recommendations for screen-reader-friendly games.
• MUDListings.com – Maintains a curated “Screen Reader Friendly” category.
• Individual MUD Discord servers – Many accessible MUDs (Cosmic Rage, Alter Aeon) maintain Discord communities with dedicated accessibility channels.

Notable Blind Developers and Players

• Morpheus (Alter Aeon) – A blind player who worked directly with lead developer Dentin over many years to implement server-side filters, abbreviated commands, blind mode, and builder accessibility tools. Much of Alter Aeon’s reputation as the accessibility gold standard traces to this collaboration.
• Lilah (Materia Magica) – Created approximately 2,000 custom sound triggers and aliases, and pioneered a dual-screen-reader system for combat (one reader for background text at ~300 WPM, another for priority notifications). She insisted on making all her tools free, recognizing that “a lot of the blind players are underemployed.”
• Nathan Smith (Cosmic Rage) – A blind developer who built Cosmic Rage from the ground up with accessibility as a core design principle rather than an afterthought.
• The Wayfinders (Discworld MUD) – A player-run club dedicated to increasing accessibility and helping vision-impaired players navigate the game.

Screen Reader Compatibility

How Screen Readers Interact with MUD Clients

Screen readers (JAWS, NVDA, VoiceOver, Orca) work by reading text content on screen aloud via text-to-speech. For MUD clients, this means:

1. Text arrives from the server via telnet/websocket
2. The client renders it in a text buffer
3. The screen reader reads the new text aloud, either automatically or on demand
4. The player types commands which the screen reader may also echo

The core challenge is information volume. A busy MUD can flood the screen with combat messages, chat, room descriptions, and system notifications simultaneously. A sighted player scans and filters visually; a screen reader user hears everything linearly.

Common Problems

• ASCII art – Maps, borders, decorative headers, and box-drawing characters produce gibberish when read aloud (“dash dash dash dash pipe asterisk asterisk pipe dash dash dash”)
• Color-only information – If a player’s health status is conveyed only by color (green = healthy, red = critical), screen reader users miss it entirely
• Tabular data – Screen readers can’t navigate plain-text tables cell-by-cell; they read left-to-right, line-by-line, mixing columns together
• Scrollback speed – During combat, text can scroll faster than any screen reader can speak, causing critical information to be lost
• Decorative formatting – Fancy borders, centered text, and visual separators waste screen reader time on non-information
• Auto-detection – Automatically detecting that a user is blind (e.g., by screen reader user-agent) is considered a privacy violation; accessibility mode should always be opt-in

Key Screen Readers

Accessible MUD Design Principles

Writing for Screen Readers

Use consistent, predictable formatting. Every room description, item listing, and combat message should follow the same structural pattern. Screen reader users build mental models from consistency.

Prefix information with labels. Instead of relying on position or color:

HP: 150/200  Mana: 80/100  Moves: 45/50

Not:

[##########------]  [########--------]  [################]

Use punctuation strategically. Screen readers interpret punctuation as pauses:

• Commas and periods create brief pauses
• Colons create slight pauses (useful for label:value formatting)
• Double colons (::) create longer pauses – useful for separating sections
• Blank lines between sections help readers distinguish blocks of information

Keep descriptions concise but complete. Every word spoken aloud costs time. A 500-word room description that a sighted player scans in seconds takes a screen reader user a full minute to hear.

Avoiding ASCII Art

ASCII art is the single biggest accessibility barrier in MUDs. This includes:

• ASCII maps (room grids with [ ] and --- connectors)
• Health/mana bars using # or = characters
• Box-drawn tables and borders
• Decorative text art (logos, banners, welcome screens)
• Status displays using symbols instead of words

Alternatives:

• Replace ASCII maps with the nearby command pattern (Alter Aeon): “The town square is to the north. The blacksmith is to the east. The inn is two rooms south.”
• Replace health bars with text: HP: 150/200 (75%) or HP: wounded
• Replace bordered tables with comma-separated or colon-separated lists
• Provide a set screenreader or set blind command that strips all ASCII art server-side
• Allow builders to mark ASCII sections separately from descriptions so the server can strip them selectively

Sound Cues

Sound is the most powerful accessibility tool for blind MUD players, effectively replacing the “at-a-glance” scanning that sighted players do visually.

Effective uses of sound:

• Combat events – Distinct sounds for hits, misses, critical strikes, spells landing, enemy death
• Status changes – Audio alerts for poison, low health, stat buffs/debuffs
• Communication – Different tones for tells, group chat, global channels, system messages
• Navigation – Ambient sounds indicating area type (forest, city, dungeon), audio cues for exits
• Alerts – Someone entering the room, being attacked, receiving items

Implementation approaches:

1. Mud Sound Protocol (MSP) – Server sends sound triggers inline with text; client plays corresponding audio files
2. Client-side triggers – Players or soundpack creators write regex triggers that play sounds when specific text patterns appear
3. GMCP sound events – Structured out-of-band data telling the client to play specific sounds
4. MUD Client Media Protocol (MCMP) – A newer standard for media playback coordination

Consistent Formatting

Room descriptions should always follow the same structure:

[Room Name]
Description text.
Exits: north, south, east
Players here: Gandalf, Frodo
Items here: a rusty sword, a leather bag

Never change the order of these elements. Screen reader users learn to skip forward to the section they need. If exits sometimes appear before items and sometimes after, navigation becomes guesswork.

Combat messages should be clearly attributed:

You hit the goblin for 15 damage.
The goblin hits you for 8 damage.
Gandalf casts fireball at the goblin for 30 damage.

Not:

*WHACK* 15 damage!
-8 HP
>>>FIREBALL<<< 30 damage!

Navigation Aids

Blind players cannot use visual maps. The MUD must provide equivalent navigation through text:

• nearby command – Lists areas and their cardinal direction relative to the player: “The market is 2 north, 1 east.”
• exits command – Always available, listing all exits with brief destination descriptions
• map text / map written – Converts visual map data into written room-by-room descriptions
• Breadcrumb/backtrack – Ability to retrace steps automatically
• Landmarks – Named reference points for orientation (“You are near the fountain in the town square”)
• Speedwalk – Macro command to traverse known paths: speedwalk market instead of n;n;e;s
• Unexplored exit tracking – Flag exits the player hasn’t taken yet (Alter Aeon’s blind-mode map does this)

Combat Accessibility

Combat is where accessibility most commonly breaks down. Fast-paced combat generates enormous text volume that overwhelms screen readers.

Design strategies:

• Brief combat mode – Reduce combat output to essential information: damage dealt, damage received, enemy status changes, death
• Combat summary – After combat ends, provide a summary: “Battle over. You defeated 3 goblins. Damage taken: 45. XP gained: 120.”
• Auto-combat with alerts – Let routine combat run automatically; only interrupt the screen reader for decisions or danger (low HP, new enemy, special attack)
• Gagging repetitive text – Server-side or client-side suppression of repetitive “You miss” or “The goblin dodges” messages
• Sound-driven combat – Replace most combat text with distinct audio cues; only speak critical events
• Turn-based or slower pacing options – Where possible, allow players to slow combat pace without competitive disadvantage
• Priority channels – Separate combat text into importance tiers; screen readers only announce high-priority events in real-time, with full logs reviewable after combat

MUDs Known for Accessibility

Alter Aeon (The Gold Standard)

URL: alteraeon.com, port 3010 (blind-friendly login)

Alter Aeon is widely regarded as the most accessible MUD in existence. Its accessibility wasn’t bolted on – it evolved through years of collaboration between lead developer Dentin and blind player Morpheus.

Key features:

• set blind command – Activates low-spam mode, textual map options, and screen-reader-optimized output in one command
• Dedicated blind login port (3010) – Starts with all accessibility options pre-configured
• nearby command – Shows direction and distance to surrounding areas in text, replacing visual maps entirely
• map command (blind mode) – Shows unexplored exits, helping blind players systematically explore areas
• Server-side filters – Strips decorative text, ASCII art, and redundant output
• Abbreviated commands – Reduces typing for common actions
• MUSH-Z client – A Windows client bundled with soundpack, scripts, and screen reader interface; used by most of the blind player base
• Multi-platform support – Mac (VoiceOver + telnet), iOS (MUDRammer), Android (Fado), Linux (Tintin + Orca)
• Community-built soundpacks – Multiple soundpack options maintained by blind players themselves

Alter Aeon’s approach demonstrates that the best accessibility work comes from direct collaboration with blind players, not from sighted developers guessing at needs.

Cosmic Rage

URL: cosmicrage.earth

A sci-fi MUD built from the ground up by a blind developer (Nathan Smith / Nathan Tech). Because the lead developer is blind, accessibility isn’t a feature – it’s the default.

Key features:

• Zero ASCII art – No maps, no decorative borders, no symbol-based displays
• Structured text with headings – Output is organized for linear reading
• Comprehensive soundpack – Rich atmospheric audio including ambient sounds, combat effects, and navigation cues
• Works with any MUD client – VIP Mud, MUSHclient, Mudlet all supported
• Roleplay-encouraged – Active community with friendly players and accessible social features

Miriani

A sci-fi MOO (a MUD subtype) focused on space exploration, salvaging, and combat against the alien Praelor.

Key features:

• Extensive VIP Mud soundpack – Triggers, aliases, and sounds covering ambience, combat, and navigation
• Text-first design – No visual-only information
• Accessible space combat – Audio cues for ship systems, enemy positions, and damage

Discworld MUD

Based on Terry Pratchett’s Discworld novels, this MUD has invested significantly in accessibility.

Key features:

• screenreader command – Lists and auto-sets all recommended screen reader options
• brief look – Minimizes room description verbosity on entry
• options output skills = list – Converts branched skill trees (a screen reader nightmare) into flat lists
• map text / map door text – Written descriptions of surrounding rooms replacing visual maps
• Quow’s screenreader package – A community-built MUSHclient configuration with screen reader plugins pre-configured
• The Wayfinders – A player-run club dedicated to accessibility, helping new blind players learn the game

Materia Magica

A MUD with a 20+ year history that transformed its accessibility through the efforts of blind player Lilah.

Key features:

• Visually impaired plugin package – MP3 audio files, map/channel capture, concurrent sound support
• Server-side hooks – Integration points allowing customized sounds and modified code for VI players
• Free accessibility tools – All VI tools distributed at no cost
• 50% blind player population – On peak nights, half of online players are blind

MUD Clients for Accessibility

VIP Mud

Platform: Windows | Cost: $30 (30-day trial) | URL: gmagames.com/vipmud.shtml

The most widely used MUD client among blind players. Purpose-built for accessibility.

Screen reader support: JAWS, NVDA, WindowEyes, System Access, Cobra, SuperNova/Hal, and MS SAPI – all working out of the box with zero configuration.

Key features:

• Multiple simultaneous voices for different output types (combat, chat, system)
• Per-window and per-output-type screen reader assignment
• Full scripting language comparable to zMUD/TinTin++
• User-friendly script builder for non-coders
• MSP (Mud Sound Protocol) support
• Multiple ASCII art suppression methods
• Speedwalking, path retracing, breadcrumb navigation
• Multi-character concurrent session support
• Word extraction from output for command composition (grab a hard-to-spell NPC name from the text and paste it into a command)
• User-maintained dictionary of difficult terms for quick insertion

Limitations: Windows-only, costs money ($30), aging codebase (supports Windows 2000 through 10).

MUSHclient

Platform: Windows | Cost: Free | URL: mushclient.com

A powerful, free MUD client that supports screen readers through the MushReader plugin.

Screen reader support: MushReader is a plugin + DLL that auto-detects and works with JAWS, NVDA, WindowEyes, and System Access. Install the plugin XML in the plugins directory and the DLL in the main MUSHclient directory.

Key features:

• Extensive plugin ecosystem
• Powerful scripting (Lua, Python, VBScript, and more)
• Community-maintained accessibility configurations (e.g., Quow’s Discworld screenreader package)
• Professional-grade trigger/alias/gag system
• Free and open

Limitations: Windows-only, requires manual plugin setup for accessibility, less intuitive than VIP Mud for new blind users.

Mudlet

Platform: Windows, macOS, Linux | Cost: Free | URL: mudlet.org

The most popular cross-platform MUD client. Significantly improved screen reader support starting with version 4.17.

Screen reader support: Main display and code editor are now readable by screen readers. Settings menu includes “Advertise screen reader use via protocols supporting this notice” checkbox, which notifies game servers via GMCP that a screen reader is in use.

Key features:

• Cross-platform (the only major accessible client on macOS and Linux with a GUI)
• GMCP, MSDP, MSP protocol support
• Powerful Lua scripting
• Active development with ongoing accessibility improvements
• announceIncomingText and enableClosedCaption accessibility options
• Large community and plugin ecosystem

Limitations: Accessibility is improving but not yet on par with VIP Mud for blind users. GUI elements still have accessibility gaps.

BlightMud

Platform: Linux, macOS (terminal) | Cost: Free | URL: github.com/Blightmud/Blightmud

A terminal-based MUD client written in Rust with built-in accessibility features.

Screen reader support: Built-in text-to-speech engine (optional, requires libclang and libspeechd), screen reader friendly mode, and a dedicated screen reader channel on the developer’s Discord.

Key features:

• Terminal-based, so inherently compatible with terminal screen readers (Orca on Linux, VoiceOver terminal on Mac)
• Lua scripting for aliases, triggers, timers
• Lightweight and fast
• Active blind user community providing feedback

Limitations: No GUI, terminal-only. Requires comfort with command-line tools.

LociTerm

Platform: Web (any browser) | Cost: Free | URL: github.com/RahjIII/lociterm

A Progressive Web App MUD client built from scratch with accessibility as a core design goal.

Screen reader support: ARIA screen reader hinting enabled by default. Screen reader mode strips color codes, translates emoji to plain text, and reduces output clutter.

Key features:

• Runs in any modern browser – no installation required
• ARIA-native design
• OpenDyslexic font option for players with dyslexia
• High-contrast settings for low vision
• Visual formatting always backed by equivalent text
• Connects to 200+ games
• Mobile-friendly

Limitations: Dependent on browser accessibility support. No local scripting ecosystem comparable to VIP Mud or MUSHclient.

Vancia Client

Platform: Windows | Cost: Free | URL: github.com/vincent-lg/vanciaclient

A free MUD client designed to offer rich accessibility with different screen readers.

Technical Considerations

ARIA Labels for Web Clients

For a web-based MUD client (highly relevant to our Urbit MUD), WAI-ARIA provides the semantic layer that makes dynamic content accessible to screen readers.

Critical ARIA patterns for MUD web clients:

aria-live regions – The core mechanism for announcing new MUD text:

<div id="game-output" role="log" aria-live="polite" aria-relevant="additions">
  <!-- MUD text appended here -->
</div>

• Use aria-live="polite" – waits for the screen reader to finish current speech before announcing new content
• Use role="log" – semantically indicates sequential updates (chat log, game log)
• Set aria-relevant="additions" – only announce new content, not removals

Important implementation notes:

• The live region must exist in the DOM (even if empty) on page load
• If adding dynamically, wait at least 2 seconds before injecting text
• aria-atomic="false" (default) – only reads new additions, not the entire region
• aria-busy="true" during bulk updates – prevents announcing each line individually during large text dumps

Input area:

<label for="command-input" class="sr-only">Enter command</label>
<input id="command-input" type="text" role="textbox" aria-label="Command input" />

Status information (HP, mana, etc.):

<div role="status" aria-live="polite" aria-atomic="true">
  HP: 150/200 | Mana: 80/100
</div>

Use role="status" for information that changes but doesn’t require immediate attention. Use role="alert" only for urgent notifications (low HP warning, being attacked).

Room/area information:

<section aria-label="Current room">
  <h2 id="room-name">Town Square</h2>
  <p id="room-desc">A cobblestone plaza with a fountain at its center.</p>
  <nav aria-label="Room exits">
    <ul>
      <li><button>North - Market Street</button></li>
      <li><button>East - Blacksmith</button></li>
    </ul>
  </nav>
</section>

GMCP for Structured Data

GMCP (Generic MUD Communication Protocol) is critical for accessibility because it separates data from presentation. Instead of parsing room descriptions from raw text, the client receives structured JSON:

// Room info via GMCP
{
  "Room.Info": {
    "name": "Town Square",
    "desc": "A cobblestone plaza with a fountain.",
    "exits": {"north": "Market Street", "east": "Blacksmith"},
    "players": ["Gandalf", "Frodo"],
    "items": ["a rusty sword"]
  }
}

Accessibility benefits of GMCP:

• Structured data – Client can format room info optimally for screen readers without parsing free text
• Screen reader notification – GMCP supports Char.ScreenReader – the client can tell the server that a screen reader is active, allowing server-side output optimization
• Separate channels – HP, mana, room data, and combat info arrive as structured data, enabling the client to route each to different ARIA regions or speech priorities
• Reduced text volume – Status data sent via GMCP doesn’t need to be embedded in game text, reducing what the screen reader must process

GMCP namespaces relevant to accessibility:

• Char.Vitals – Health, mana, movement (update status region without game text)
• Char.Status – Conditions, effects (trigger audio alerts)
• Room.Info – Room name, description, exits (structured navigation data)
• Comm.Channel – Chat messages (route to separate audio channel)

Sound Packs

Sound packs transform the MUD experience for blind players from “listening to a screen reader drone” to “playing an audio game.” They are the accessibility equivalent of a graphics engine.

Architecture of a sound pack:

1. Trigger patterns – Regex matching specific game text (e.g., You hit the (.+) for (\d+) damage)
2. Sound files – MP3/WAV audio mapped to triggers
3. Priority system – Which sounds interrupt others, which play concurrently
4. Volume/balance – Combat sounds vs. ambient vs. notifications

Best practices for MUD developers:

• Support MSP (Mud Sound Protocol) or MCMP (MUD Client Media Protocol) server-side
• Send GMCP events that map cleanly to sound triggers
• Provide a starter soundpack or partner with blind community members to create one
• Use consistent, parseable text patterns so community soundpack creators can write reliable triggers
• Consider spatial audio for directional information (enemy to the north, water to the east)

Text-to-Speech Considerations

Speed and volume management:

• Experienced blind MUD players listen at 200-400+ WPM
• Lilah’s dual-reader approach: background reader at ~300 WPM for combat scroll, priority reader for important events overlaid on top
• The MUD should support categorized output so clients can route different categories to different TTS priorities

Pronunciation:

• Fantasy names, spells, and items may be mispronounced by TTS engines
• Consistent naming helps TTS learn patterns
• Avoid excessive punctuation or special characters in names
• Consider providing pronunciation hints via GMCP metadata for important terms

Reducing Information Overload

This is the #1 accessibility challenge. Strategies:

Server-side:

• brief mode – Minimize room descriptions on entry
• screenreader mode – Strip decorative text, color codes, ASCII art
• Combat spam reduction – Combine multiple hits into summaries
• Channel filtering – Let players disable specific communication channels
• gag patterns – Server-side suppression of specified text patterns

Client-side:

• Trigger-based gagging of repetitive messages
• Virtual buffers – Categorize messages (chat, combat, system) into separate reviewable buffers
• Sound replacement – Replace text messages with audio cues, removing them from the text stream
• Priority queuing – Only speak high-priority messages in real-time; queue others for review

Implications for Our Urbit MUD

Design from Day One

Accessibility cannot be bolted on after the fact. The architecture of the MUD – how it structures output, handles combat, presents navigation – must account for screen reader users from the first line of code. This is both a moral imperative and a strategic advantage: blind players are a loyal, engaged, and underserved community that forms a disproportionately large share of the MUD player base.

Core Architecture Decisions

Structured output over free text. Every piece of game information should exist as structured data (Urbit nouns) that gets rendered into text for display. The text is a view; the data is the source of truth. This enables:

• Screen reader mode that renders the same data differently
• GMCP-style structured data delivery to clients
• Consistent formatting that never breaks

Separate data channels. Use Urbit’s subscription model to separate game output into distinct channels:

• Room/navigation data
• Combat events
• Player communication
• System messages
• Status updates (HP, mana, etc.)

Each channel can be routed to different ARIA regions, different TTS priorities, or different sound triggers on the client side.

Server-side accessibility modes. The ship should support:

• set screenreader on – Strips ASCII art, replaces color-coded information with text labels, reduces spam
• set brief on – Minimizes room descriptions
• set combat brief on – Summarizes combat instead of line-by-line play
• These should be persistent settings stored in the player’s state

Web UI Patterns

Since our client will likely be web-based (running in the Urbit landscape), ARIA compliance is non-negotiable.

Minimum viable accessible web client:

+------------------------------------------+
| [status region: role="status"]           |
| HP: 150/200 | Mana: 80/100              |
+------------------------------------------+
| [game log: role="log" aria-live="polite"]|
|                                          |
| Game text appears here...                |
|                                          |
+------------------------------------------+
| [command input: role="textbox"]          |
| > _                                      |
+------------------------------------------+

• Game log uses role="log" with aria-live="polite"
• Status bar uses role="status" for non-urgent updates
• Critical alerts (low HP, death) use role="alert" for immediate announcement
• Room navigation uses semantic HTML (<nav>, <h2> for room names)
• No information conveyed by color alone – always include text equivalents
• Keyboard-navigable – every interactive element reachable via Tab/Enter
• Command history via arrow keys (already standard in most inputs)

Advanced patterns:

• Separate ARIA live regions for chat vs. game output, so a screen reader user can distinguish between communication and gameplay
• Toggle-able “verbose” and “brief” modes that change the ARIA region’s content density
• Sound cue integration via Web Audio API, triggered by structured game events
• Skip-navigation links: “Skip to command input”, “Skip to room info”, “Skip to exits”
• A “review last combat” command that replays the combat summary without re-triggering live region announcements

Urbit-Specific Advantages

Urbit’s architecture actually offers some unique accessibility benefits:

• Persistent identity – Player accessibility preferences stored on-ship, follow the player across sessions and devices
• Structured data natively – Urbit nouns are inherently structured; rendering them as accessible text is a transformation, not a retrofit
• Subscription-based updates – Urbit’s pub/sub model maps naturally to separate ARIA live regions and prioritized TTS channels
• Web-first client – Building on the web stack means ARIA, semantic HTML, and screen reader support are first-class citizens of the platform
• Decentralized but consistent – Accessibility standards can be defined in the protocol itself, ensuring every instance of the MUD meets minimum accessibility requirements

Checklist for Launch

Before any public release:

• Screen reader mode (set screenreader on) fully functional
• No ASCII art without text alternatives
• All color-coded information also conveyed in text
• Room descriptions follow consistent structure
• nearby and exits commands provide text-based navigation
• Combat brief mode reduces output to essentials
• Web client passes ARIA audit (axe, Lighthouse)
• Tested with NVDA and VoiceOver
• Sound cue support for core events (combat, communication, navigation)
• GMCP or equivalent structured data protocol for client-side rendering
• Keyboard-only navigation works for all features
• Documentation accessible to screen readers
• At least one blind player has tested and provided feedback

Sources

• Alter Aeon Blind Player Support
• Alter Aeon - A MUD For The Visually Impaired
• AudioGames.net - VIP MUD
• Building a Better MUD for Screen Reader Users - Writing Games
• Cosmic Rage MUD
• Cosmic Rage - AudioGames.net
• Miriani - AudioGames.net
• Discworld MUD Accessibility Help
• Discworld MUD Accessibility
• How Blind Players Made a Text-Only RPG More Accessible - Vice/Waypoint
• How Soundpacks Elevate the MUD Experience - Writing Games
• VIP Mud - GMA Games
• MUSHclient Accessibility Resources
• BlightMud - GitHub
• LociTerm - GitHub
• Mudlet 4.17 Screen Reader Support
• Mudlet Accessibility for Mudlet Part 1
• MUDListings - Screen Reader Friendly Games
• MUD Games in 2025 - Accessibility as Survival
• GMCP Protocol Documentation
• ARIA Live Regions - MDN Web Docs
• WAI-ARIA Overview - W3C
• Blind Gamers Mailing List
• MUD Client Media Protocol - Mudlet Wiki
• Quow’s Discworld Screenreader Package
• New Moon MUD Screen Reader Guide