Accessibility option: Accessible readouts

[SeanMirrsen]

Following the discussion here, I'll be making a list of reasonably small changes and additions to the game that would make the game more playable for players who are forced to use screen-reader software to "see" the game screen due to disabilities of vision. All of this obviously applies only to "console" builds of the game.

• Accessible readouts - In combination with the log-less mode, there will be enough empty space on the sidebar to display some information that can't be easily tracked via screen-reader software. Things like the current sight radius in tiles, the heading of the currently driven vehicle, the direction and distance to nearest hostile monster, etc. Also in this mode, heavily symbolized readouts in the status section of the sidebar could be converted to plain text, like time-of-day tracking, non-numeric healthbars (would display readable, if shortened, descriptions, like "GOOD", "INJURD", "MNGLD", etc., to make the change of status easier to track).

(Split from #15864)

[lucianposton]

Along with readouts, disabling unnecessary animations like weather and WoW-style damage indicators would probably be a good idea e.g. in an accessibility option/mode. Annoying af having every rain drop dictated to you until you realize what's happening and find how to disable it. 😤

[BlindGuyNW]

I’ve already disabled weather. :)

From a certain point of view I don’t like the idea of an accessibility-specific mode. THat’s more a philosophical issue from my day job though.

On Mar 25, 2016, at 7:52 AM, lucianposton [email protected] wrote:

Along with readouts, disabling unnecessary animations like weather and WoW-style damage indicators would probably be a good idea e.g. in an accessibility option/mode. Annoying af having every rain drop dictated to you until you realize what's happening and find how to disable it.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #15869 (comment)

[Leland]

Closing - old and no movement. Feel free to ping me here if there's still interest, or make a new issue.

FWIW, I'm all for this. Hope the game improves its accessibility.

[BlindGuyNW]

Hey, I just started getting back into CDDA actually. :) I’ve been trying to figure out vehicles. Readouts could definitely help with that, because the way the ascii deforms is really confusing. Sadly, I don’t know how much more interest there will be from other blind people, just because the game is niche to begin with.

…

On May 1, 2017, at 8:58 PM, Leland Clemmons ***@***.***> wrote: Closing - old and no movement. Feel free to ping me here if there's still interest, or make a new issue. FWIW, I'm all for this. Hope the game improves its accessibility. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#15869 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABtsc6l2J6iN71YvQozjotHFNRNhgHqtks5r1qnwgaJpZM4H2wKd>.

[kevingranade]

Actually I like to keep this one open.

[damien]

I was having a think about how I’d go about doing a few things within CDDA and stumbled across this. I think having some way to expose the game state in a structured format could enable a solution here in addition to enabling things like automated testing of stuff in game or more elaborate ways to control the display of the UI.

In more specific terms, I’m thinking of a socket, port, or file on the system that when read returns a structured representation of the current game state.

A few things this data could contain:

1. Tiles, items, and monsters currently viewable on-screen or wherever a user is focusing their view poet (e.g. “looking” off screen or peeking through a window)
2. All the data required to render the side bar in as much fidelity as possible. We could leave it to the consumers of the data to decide how they want to display, read, or otherwise expose it to a user.
3. Some metadata about the current game state. I think we’d only need enough for a consumer to know if the game state has changed and their representation of it needs to be updated.

A few open questions I thought of, but can’t answer:

1. How the heck does one use this to model UI state, like open or selected menu items?
2. Is this overkill? Are there simpler ways to enable richer presentation mediums than some kind of internal API or RPC layer?
3. How much of the game state can actually be serialized and exposed in a meaningful way?
4. Would having a think about how we handle game state (storage, representation) be a better starting point to enable solutions to problems like accessibility?

Sorry for the long comment. Thinking on this got gears turning. I can spin this out into it’s own related ticket if any of this doesn’t sound completely unreasonable.

[alex19EP]

hello @damien. i am just a blind cdda player not a developer. but i can give you some accessibility related answers.

1. Tiles, items, and monsters currently viewable on-screen or wherever a user is focusing their view poet (e.g. “looking” off screen or peeking through a window)

such system is already implemented. menu can be accessed by V key. and it helps me alot.
frankly, I think that it can be simply improved in order to further improve accessibility.

You claim that accessibility can be improved by giving as much information as possible to third-party software. I think that we can and should go the other way. the game itself can provide this information accessibly.

some thoughts I set out in #26885