Accessibility Features

[aevyrie]

Bevy will need to implement accessibility features at some point; I hope we can be proactive and consider these needs during the design of some of Bevy's fundamental systems. I don't have any concrete plans in mind, but my hope is that this can serve as a place to discuss these features and what we need to accomplish.

What features do we need for the dev tools (Bevy editor) and shipped products? Are there legal requirements or standards we can follow? A11y? WCAG? This isn't an area I have any experience, so it would be great to hear from those who do.

I've copied the since-discarded draft RFC here as a starting point.

Summary

Accessibility features are needed for applications and games. This covers very high-level needs, and will probably require subsequent sub-RFCs to hash out the design details of the many potential accessibility features.

Motivation

Accessibility features are required to ensure we aren't excluding end users or developers. In addition, accessibility features improve software for everyone who uses it. For instance, keyboard navigation is often faster than using a pointer. We get to both include everyone and enrich things for everyone!

Guide-level explanation

Some common terms and features we should consider:

• TTS: Text-to-speech
• Color blindness modes
• Text resizing (or respecting OS settings)
• Rebinding inputs
• Navigating UI without a mouse

Rationale and alternatives

Even if we can't commit the resources or find the expertise to implement some or all of these desired features, at the bare minimum we should keep these features in mind as we work on the rest of the engine. We can still actively take steps to avoid making accessibility features more difficult to implement in the future.

[Optional] Prior art

• Editor-Ready UI #254 (comment)
• https://github.com/lightsoutgames/godot-accessibility
• https://crates.io/crates/tts
• Accessibility (A11y) emilk/egui#167

Unresolved questions

• What standards or laws would serve as useful guidelines or criteria?
• What users can we work with to validate solutions serve their purpose?

[aevyrie]

I'd like to highlight a comment from @ndarilek in #254 (comment)

In terms of making my job easier, here are two bits of advice:

1. Make keyboard navigation first-class. Godot has this problem right now. The tree widget is absolutely broken for keyboard navigation, and fixing it isn't a priority. I'd do it myself, but since I can't see what I'm doing, it's like coding with a strip of cloth between me and the keyboard. Not saying it needs to be exhaustive and platform-specific, but keyboard/gamepad support should be consistent, and fixing breakage should be prioritized.
2. Send events for just about everything. Focus enters/leaves a widget. Text is added to, or removed from, a TextEdit. Focus/selection moves around an editor. I need to intercept just about everything and provide a speech representation. Godot has some lacks here too, and there's been a bit of resistence to adding signals I need, meaning accessibility becomes more and more hacked-on.

From what I've seen in egui's TTS implementation, it's using liberal use of UI events to facilitate TTS for navigation.

[B-Reif]

Motivation

We have a moral imperative to consider the needs of all end-users of the games and applications made with Bevy. Accessibility features are required to ensure we aren't excluding end users or developers.

Just wanted to add that accessibility features improve software for everyone who uses it. For instance, keyboard navigation is often faster than using a pointer. We get to both include everyone and enrich things for everyone!

[aevyrie]

Thanks for pointing this out, I'll update the parent post. 🙂