Skip to content

Accessible Crawl

Edgar A. Bering IV edited this page Dec 12, 2021 · 1 revision

While DCSS has never been explicitly developed with visually or motor impaired players in mind, it turns out that both can enjoy the game. The purpose of this page is to discuss ways in which their experience (and, ideally, that of all Crawl players) can be improved. Therefore, this is strictly about interface modifications. The first installment of this page grew out of a discussion between Moritz and dpeg, and has since been expanded on by ebering.

Background

In general, having a text based interface (“ASCII”) is by itself not enough to provide a blind-friendly experience. Glyphs need to be supported by additional features. What makes Crawl already playable for the blind are the following features, all of which automate interface tasks:

  • autoexplore
  • autofight (Tab)
  • ranged combat (targeting)
  • Ctrl-F
  • Ctrl-X

These automations, as well as the macro system, are also what make crawl accessible to players with motor restrictions.

Major obstacles for blind players are: the large scale map of each level (its geography and strategic interaction), the difficulty of screen-reading the viewport/HUD.

Easily approached improvements

The following improvements to the interface do not require significant technical overhaul, the only thing keeping them off of the User Interface Improvements implementable list is specific designs developed with input from blind or motor impaired players.

View description commands

Getting information about the surrounding is very important. Any commands that makes blind players rely less on the map is helpful. All of this is about additional commands which produce textual feedback. Here are some ideas which of these are most useful has to be decided by blind players (who don't have to agree in these choices, of course):

  • list terrain on the eight adjacent squares (starting at north, then proceeding clockwise)
  • same with monsters
  • overview of terrain in view: You can see 34 tiles. Of these are 20 floor, 10 shallow water, 2 deep water, 1 door and one altar to Trog.
  • mention the nearest walls?
  • The current monster list is already a permanently viewing command in its own right. There could be an option to enrich it by appending positions to monsters, such as gnoll (2 up, 3 right) and 2 orcs (1 up, 0 left; 2 up, 1 right), as has been done to the ^x list. The space required for this extension might require a larger terminal, and still suffers from the reader-unfriendliness of the HUD, so this particular feature might need to move to the HUD re-design section.
  • Moritz mentioned that absolute coordinates for the level could be useful. Crawl cannot give out actual coordinates because that is hiddent information, although this would work with randomly chosen horizontal/vertical offsets.

Colour usage

Crawl's console interface needs to be reviewed for places where colour is used exclusively to convey information. Some screen readers can describe the glyph colours but this is not ideal to rely on, symbolic representation is better. As these usages are located they can be moved to the User Interface Improvements page.

Cursor placement

Many screen readers take the cursor placement of a console as a cue for where to start reading. Currently, we always place the cursor at the player @ symbol in the viewport. A better option might be to place the cursor at the location of where to start reading to get the latest update from the game in reaction to user input. When and where to do this in the UI requires input from screen-reader players, the obvious ideas are:

  • The 'start of turn' indicator in the message window, when its displayed
  • The start of any displayed prompt
  • Top left for some menus

More involved technical projects

aidanh's project to widgetify and modernize the crawl UI may make several of these projects more approachable.

Pagination instead of multi-column displays

Multi column console displays don't screen-read nearly as well as single-column lined displays. Many of our screens are inherently multi-column so that a sighted player in an 80x24 console does not have to scroll. Unfortunately this output is less convenient for a screen reader, and it would be good to have a toggle to force all menus to be single-column. Many parts of the UI are still significantly hard-coded, and there is some technical work to be done in refactoring/rewriting these menus to support a single-column paginated view as well as a multi-column view.

Modularized HUD

Blind players use screen readers to get feedback about the game state. (This is why ASCII is necessary, but not sufficient.) However, the map (i.e. the main section of the main Crawl screen, with the player @ at its centre) is extremely hard to parse via screen reader. Some blind players seem to do this, but others just turn off the map in games where that is possible.

For Crawl, it would make sense to provide an option that produces output not on one screen with a fixed layout (terminal), but on several separate ones, or in a specified order with each section screen-reading easily:

  • map
  • messages
  • monster list
  • HUD (health, magic, Str/Dex/Int etc.)
  • inventory
  • spell list
  • list of status effects

Perhaps this should be even more fine-grained, like having a separate Health screen etc. This way, blind players can have their screen readers only read out the parts they want to know about (currently, you have to skip part of the gibberish map reading).

The current implementation of the main display is highly non-modular and cross-loaded in the codebase. As aidanh's refactor continues this should become less true, an ultimate goal of that work is to widgetify the main display, after which modular rearrangements are easy.

Sound support

This has been brought up several times. For blind players, acoustic feedback is very valuable. There is already the possibility to link regular expressions on messages to sound files. It would be very good to start on this – we can be slow on this one, there is no need to produce a monolithic sound library in one go.

Sounds used should be open source. I would hope that, like with Crawl's tiles, we can enable player support for this task.

In a second step, sound support could be based not just on messages but also on surroundings. Ideally, we could display the presence of the following game features through ongoing sounds:

  • monsters (indicate number and threat level by volume/frequency?)
  • terrain (floor/water/lava)
  • low health
  • altars, portals, staircases

Background reading

Clone this wiki locally