Add Tests, Tools and Guidelines for Content Accessibility #6490
Replies: 3 comments 15 replies
-
I'm converting this to a discussion because this is a very general proposal that is not immediately actionable. The idea is valid, but we need more specific descriptions for tools and tests that can be implemented (what problem they solve, how do they solve it, how do users interface with them, etc). As for guidelines I feel like that's not something the project has to offer an opinion. It's a broad subject, applicable to any application or game, not to a specific engine (though official documentation for the aforementioned tests and tools should be created alongside them). |
Beta Was this translation helpful? Give feedback.
-
TL;DR : I am wholly in favour of implementing accessibility features into the engine by default, and think that would be a boon for many developers and players alike. However, in the short term I feel that addons and GDExtension will allow for greater flexibility in development as well as allowing users to create bespoke solutions that integrate seamlessly with their specific game. I really like this proposal/discussion. I think focusing on accessibility features by default will make the process of creating accessible games much easier. I personally try to create accessible features in my games, but I am definitely limited to implementations that I am aware of. (i.e. reducing/removing flashing lights, subtitles, TTS, and such). I would love to see as many accessibility features as possible be integrated directly into the Godot Engine if nothing more than to make the process that much easier and enjoyable. However I do agree with Yuri that not everything is "immediately actionable". And arguably more regular participants probably have a bigger say than me. I do believe that in the short term, implementations of accessibility features can be created through community developed addons and such. With GDExtension in Godot 4 I'm expecting that integrating native libraries will be much easier. It will encourage development of "extensions"(?) for hooking into accessibility systems such as OS-side TTS (Systems that blind users are likely to have installed already, not Godot's existing TTS implementation). And I imagine many more features could be added through the use of addons in the future. From what I've experienced, this is more or less the default for the Godot Community. That is, if there's a feature you like, first see if it can be implemented with an addon. If not, try to find a way that it can be implemented, including changing the base code of the engine. Before I go too far, I am not assuming you don't know this, I'm including it for anyone who might be reading this discussion in the future, who is less familiar with this process. This engine's modularity in development lets individuals such as myself to create addons to perfectly fit my needs and/or the needs of my players. I actually made a subtitle addon for handling 3D spatial audio in a somewhat reasonable way. I don't think I've updated it past 3.2. And honestly I really would appreciate an engine-default subtitling system, I would probably use it for all of my games if it were added. But making it as an addon allowed me to creature a bespoke solution to my project, a game using 3D spatial audio, that would render it unusable to another project such as any 2D game. And just let me re-iterate, I am completely in support of an engine default solution, because that would enable developers to save time as well as enable the engine itself to become more accessible. I feel this could be more actionable if we discussed very specific features and implementations, the kinds of details that could be made into an issue/feature bounty. And it's entirely possible I'm completely missing the point. I was having a hard time parsing the links provided. That might just be me having a hard time processing that information load. |
Beta Was this translation helpful? Give feedback.
-
Here's how Visual Studio is Integrating an Accessibility Checker |
Beta Was this translation helpful? Give feedback.
-
Describe the project you are working on
https://github.com/spicylobstergames/shotcaller-godot
Minimalistic 1v1 MOBA/RTS in top-down pixel style
Describe the problem or limitation you are having in your project
Having a hard time assuring that I'm providing accessible interfaces.
For eg. the default button focus color is replaced by font hover color and removing the focus style leads to a failure in accessibility tests. Just to be clear, focus color (and styles) should always override hover colors (and styles) and that's easy to test, and if a developer somehow changes it with scripts we could raise an accessibility warning. Fixing this kind of misbehavior should be a top priority imho.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
The current User interface has very limited features that help developers to deploy accessible content.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Content Accessibility Tests, Tools and Guidelines should provide means for making games, applications, and other content accessible to people with disabilities.
Tests would allow us to check if the editor itself and developed games are not breaking simple and testable accessibility rules.
Tools would make easier by enable and validate accessible environments and providing quick shortcuts to set them up.
Guidelines are not required but provide insights in order to develop more accessible games.
Here's a very useful list of guidelines that can also be used to generate tools and tests https://www.w3.org/WAI/WCAG21/Techniques/
If this enhancement will not be used often, can it be worked around with a few lines of script?
N/A
Is there a reason why this should be core and not an add-on in the asset library?
N/A
Beta Was this translation helpful? Give feedback.
All reactions