Skip to content

Accessibility by default #7862

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
alice-i-cecile opened this issue Mar 1, 2023 · 6 comments
Open

Accessibility by default #7862

alice-i-cecile opened this issue Mar 1, 2023 · 6 comments
Labels
A-Accessibility A problem that prevents users with disabilities from using Bevy A-UI Graphical user interfaces, styles, layouts, and widgets

Comments

@alice-i-cecile
Copy link
Member

          These are fine for now, but needing to specify accessibility components manually kind of defeats the purpose of "accessibility by default", increases the burden on individual developers, and makes our UI examples more bloated / less approachable. I don't think its reasonable to expect your average game developer to remember to do this / do it correctly. Ideally our main "ui introduction example" has no explicit accessibility components.

Definitely cool with this as an initial step, but I think its very important to resolve this in the near future.

Originally posted by @cart in #6874 (comment)

@alice-i-cecile alice-i-cecile added A-Accessibility A problem that prevents users with disabilities from using Bevy A-UI Graphical user interfaces, styles, layouts, and widgets labels Mar 1, 2023
@alice-i-cecile alice-i-cecile added this to the 0.11 milestone Mar 1, 2023
@alice-i-cecile
Copy link
Member Author

Agreed. I'd like to suggest that we adopt a subset of AccessKit's schema into Bevy's UI component structs, using it as the basis for our widget source of truth where possible. Essentially, the closer bevy_ui can come to creating NodeBuilders from its components, the fewer explicit accessibility examples we'll need, I feel like the accessibility schema covers much of what you'd need for a UI definition. At the very least, it'd be a solid start.

I agree with this assessment, this seems like a thoughtful API to build to, both for accessibility and in general.

@ndarilek
Copy link
Contributor

ndarilek commented Mar 2, 2023

If Bevy wants or needs an accessibility SME, I'm happy to step up. I think we may actually be the first general-purpose game engine integrating accessibility into its core (I.e. not a blind person-specific game engine, and not as a third-party plugin.)

@cart
Copy link
Member

cart commented Mar 2, 2023

If Bevy wants or needs an accessibility SME, I'm happy to step up. I think we may actually be the first general-purpose game engine integrating accessibility into its core (I.e. not a blind person-specific game engine, and not as a third-party plugin.)

Brilliant. We will discuss this for the next round of SME appointments.

@Almost-Senseless-Coder
Copy link

Actually, the Quorum language (https://quorumlanguage.com/) has a (sorta...) general-purpose game engine built-in, and Andreas Stefik, the lead author/researcher, has published a BSD-licensed C++ library making communicating accessibility-relevant information from the game engine to the operating system easier.

That said, Quorum is built on top of Java. That alone can be a disadvantage in games development and the development process with quorum is relatively clunky - no automated recompilimg, for instance. The Quorum Studio IDE, in particular its accessible scene editor, is a boon to blind (or deafblind, like me) programmers, though.

I'll be watching this issue with interest.

@ndarilek
Copy link
Contributor

Jeez, I'd totally forgotten about Quorum when I suggested that Bevy was the first general-purpose accessible game engine. Granted, it's pretty niche, but I wish it'd taken off more, and at least based on what I've read, it's a great example of making a 3-D game engine and editing environment both blind-accessible and visual. Might be worth us looking more closely into for inspiration of how to make visual editing more accessible in the upcoming editor.

Gotta admit, I'm occasionally tempted to abandon Bevy for Quorum even though it is a custom JVM language. It'd be nice for us to aspire to that level of accessibility both for developers and players. :)

I can submit a blog post update PR clarifying things a bit if there's interest. I think we should leave the existing claim in, but I'm comfortable giving Quorum the distinction of being the first general-purpose visual-first game engine that made the engine itself accessible. It just sounds like less of a big deal when spelled out like that. :)

Thanks for speaking out for Quorum.

@Almost-Senseless-Coder
Copy link

Giving people credit never hurts, especially fellow open-source projects. Besides, Stefik and his team will probably be happy to share experiences and expertise.

Still, Bevy's design system speaks to me more than that of the Quorum engine; I'm not talking about any disadvantages of the JVM and garbage collection yet, but the cleanliness of game code encouraged by Bevy's design decision is definitely an advantage.

@alice-i-cecile alice-i-cecile modified the milestones: 0.11, 0.12 Jun 19, 2023
@mockersf mockersf modified the milestones: 0.12, 0.13 Oct 20, 2023
@alice-i-cecile alice-i-cecile removed this from the 0.13 milestone Jan 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Accessibility A problem that prevents users with disabilities from using Bevy A-UI Graphical user interfaces, styles, layouts, and widgets
Projects
None yet
Development

No branches or pull requests

5 participants