Unity Accessibility and inclusion

Hi!

I don't have any input now, but I spotted this thread in a different forum that's probably very relevant.

 

As someone with vision issues, being able to increase the font size in the Unity editor would be a big first step.

 

Especially as 4K monitors become more prevalent. Unfortunately, font size is a difficult thing to change. The original GUI system didn't enforce scalability, so many custom editors -- and I wouldn't be surprised if even a few built-in editors -- position things on a pixel basis under the assumption that the font size will not change. Custom editor programmers are supposed to use utility functions like EditorGUIUtility.singleLineHeight instead of hard-coding, say, 16 pixels high. But best practices aren't always followed. Newer Unity versions are switching to a new GUI system, UIElements, but this won't help the many editors that were written in the older GUI system. At some point, maybe some version of Unity can support font size changes and just accept that some older custom editors may be broken until they're updated to handle different font sizes. It'll also be a headache for devs who need to support older Unity versions, since they may need to maintain two different code bases for IMGUI and UIElements. That said, I'm all for the ability to adjust the font size. Of all the accessibility changes I can think of, it would benefit the broadest number of Unity users.

 

Oh this is awesome! I work for NASA in the Office of STEM Engagement and I've been tasked with creating web interactives and web games to help teach STEM principles. These will be seen on official nasa.gov domains. As these websites and games will be hosted on government websites I am held to 508 Compliant standards, which is simply a federal standard for accessibility very similar to WCAG 2.0 Compliance. NASA's older web games were Flash based, but this is not viable any longer. I've looked at PlayCanvas, pure Javascript engines and I'm always coming back to what I know which is Unity.

The prototypes I've been presenting to my work group are Unity WebGL builds. Everyone is very happy with the capability we now have with this, but we have to be accessibility compliant and I've struggled for a few months now trying to figure out a system for this. Unity WebGL builds are a bit of a black-box to the browser, and the accessibility tests that are run on thse Unity WebGL pages are failing. I've been slowly piecemealing together a setup where basic HTML buttons overlay my Unity WebGL content and I use Javascript to send messages/functions into the Unity player. I am figuring with the interactive elements exposed as HTML and CSS I am more able to make those compliant by their being exposed to the browser.

It would be very nice to get accessibility tools in the Unity Editor that work for all platforms, and importantly in my case, WebGL. Specifically for WebGL content the ability/tool in the Unity Editor to better allow the Unity content and the browser to communicate back and forth. Something easy to use and intuitive. I don't know if these means hot spots the browser can "see" within the Unity WebGL content, the ability to "see" tagged items or items with meta data like alt-text or aria labeling.

 

@JamesArndt - You may be interested in Metalpop's UI Accessibility Plugin if you're not already using it. It supports WebGL.

 

That was actually the first first asset I came across when researching this last year. Turns out the security department is averse to dependency on 3rd party plugins. So they likely want to keep those dependencies to a bare minimum. This left me rolling my own solutions. However if Unity could integrate something similar in the Editor itself, that would be golden.

 

This is the other thread where we discussed multiple things about readers and the same guy started the thread, maybe it contains _some_ useful info as well: https://forum.unity.com/threads/unity-not-quite-so-unified.662743/

We also discussed to some extent and gathered some information about these things here: https://forum.unity.com/threads/fcc-cvaa-discussion.607114/

Both occasions: be warned, some useful info, some flame-war. As usual.

 

It is good to hear that Unity is working on the issue.

That is definitely TINY. When I print stuff for use with my friends in our tabletop roleplaying games, I never print less than an 18 size font in Word anymore, and that is just because of middle-aged eyes. The font that I am reading this web page in (thanks to Firefox zooming) is larger than that or I can't read it comfortably. I'm fortunate to have been able to buy an oversized display so I can make text in most programs that large (and trick some programs into not realizing they are on a display that large so they don't shrink the font size down).

I look forward to seeing what Unity is able to come up with. It may break some editor tools, but I would much rather see progress at Unity and let those third party tools have to adapt.

(@ToniLi, the snark is not aimed at you as you agree. Just making a point in my grumpy way because I see so many people on the internet who think font size doesn't matter, or that everybody has young or perfectly correctable eyes like themselves.)

Stairs were a difficult thing to change in a lot of buildings too. Even for people like me who only use a cane, stairs are painful. For others, stairs are downright impossible. But companies found ways to put ramps and better doors in, even the ones who cried that it would be impossible or simply cost so much it would drive them out of business.

In the case of computers, it is that they have become an inseparable and integral part of our lives and so accessibility has had to become a requirement if software wants to expand to allow everybody to use it. Government web sites and certain other industries have requirements now, just like building entry does, but they don't expand far enough. In the case of things like font size and other visual parts of software, I think it will be companies being driven by profit to get more customers (especially older ones) before it will be any regulation setting a standard. You can easily say, "You must have a ramp that has no more than X slope," but how do you decide exactly how the menus in Microsoft Word must be set up to allow for accessibility?

I am very glad that Unity is taking this seriously. Not just for my sake as a Unity hobbyist. I genuinely believe that as Unity makes a point of creating an accessible editor, it will help game developers become more aware of how they need to make their games more accessible.

 

While there's a ton of stuff that could be done the top priorities really need to be where there are legal obligations in place.

James' experiences with section 508 are pretty typical. For anyone reading who isn't aware 508 requires a fairly extensive level of accessibility for any software used in a federal setting, which includes software used in schools.

The key blocker is accessibility for players who are blind. This was already a key requirement prior to the recent update to the law; the update brings it in line with requirements for web accessibility, which has an even greater emphasis on blind accessibility.

In regular native development, e.g. UIkit on iOS, making UI blind accessible is relatively trivial. Screenreader software (either third party or built in to the OS) is able use synthesised speech to speak out the label (volume) role (slider) and state (56%) of UI elements, so long as those bits of metadata are present on the elements.

But with Unity it hits a brick wall. No information about the underlying UI is exposed to the OS, all the OS sees is a bunch of pixels, the whole game is effectively one single unlabeled UI element.

Due to this the educational games sector has been completely hamstrung for many years. Developers who simply cannot legally use Unity resorting to basic HTML games instead, at the cost of kids' education. The same issue has caused the same results elsewhere too. For example the BBC is a prolific games publisher in the UK, and as a publicly funded body they have a chartered requirement to ensure their output is accessible. After trying to work with Unity to get the issue addressed quite a few years back, they simply banned all of the many third party studios they farm work out to from using Unity. Right on cue literally tomorrow there's a workshop session that I'm aware of between a whole bunch of educational gamedevs struggling to implement their legally required accessibility due to lack of support in Unity.

It's the same story in the wider commercial sector. Typical scenario - blind gamer sees mobile game A, which is accessible, and mobile game B, which has a very similar mechanic but is not. Gamer asks dev about accessibility of game B. Dev's response - "Oh wow, I didn't even know blind gamers were a thing. Sounds awesome, I'll look into it". Some time later, gamer chases up. Dev's response - "I'm really sorry, I looked into it and it's not technically possible." Gamer has no idea that game A is native iOS app and game B is unity, only sees two very similar game mechanics.. so concludes that the dev is lying and has just decided that they don't care about blind gamers. Everybody loses. And I've seen this time and time again, it's really sad to see.

Other options have gradually become available, upping the game for HTML through HTML frameworks that support accessibility, and as if last year the Unity Accessibility Plugin.

But even the UAP is by necessity a hack. Instead of exposing the the UI to the OS it manually interfaces with APIs for individual bits of software where they are available, and on iOS and Android attempts to replicate the entirety of each operating system's screenreader functionality inside Unity.

It's a sticking plaster to allow some people access but is not the answer, particularly as it does nothing for other forms of accessibility that rely on OS being exposed, like switch access or iOS' new voice control. The answer is for Unity to expose UI properly for each platform. At a high level what this is about is allowing the display to be rendered correctly for each platform, which is fundamentally what engines are about.

The plugin is an awesome piece of work, but it shouldn't have been necessary to do it and for one dev to try to keep pace with changes made by entire teams of people at Apple and Google isn't a great thing to have to try to do. Unity should 100% hire Michelle (Michelle Martin, the plugin developer) to help get a proper solution worked out for Unity I'm more than certain that both operating system vendors and third party screenreader vendors would be overjoyed to work with Unity on it too.

There have been people pushing for it to be fixed for 10+ years, but it has now dramatically upped in priority due to another piece of legislation - CVAA.

CVAA requires modern communications technology (specifically electronic messaging, voice over IP and video conferencing) to be accessible. This means that any game available in the US market (regardless of where it was made) that has chat functionality must ensure that functionality and any UI or info used to navigate to or operate chat functionality must be accessible, under threat of fines of up to $1m per infraction.

CVAA was enacted in 2010, with the time between then and now granted to the games industry specifically to allow for R&D time. The final waiver expired on Dec 31st.

The law covers small developers as well as large, so Unity's lack of progress on it has very real and serious implications for a significant chunk of their customers.

CVAA covers a wide range of requirements, another that could be at least partially addressed at engine level is accessibility for people with low vision, through scaleable UI (also a section 508 req). Configurable controls are also useful for meeting CVAA requirements; Unity's new input system should provide nice support for this once it hits main release.

I'm very much aware that this has been a heavy post so far, but it's serious stuff.

On a lighter note there's also a a bunch of other ways in which Unity can help devs provide a good experience for more of their players. There are two aspects to this - one is tools to help devs with implementation, like colorblind simulation within the UI (I can give some good algorithms for this). The other is through ways of taking care of some of the heavy lifting, prime candidate for this being subtitling - there's a pretty standard set of of subtitle presentation options starting to spread through games, they're already legally required in other industries (hence identical options from iOS to Netflix to YouTube) and are starting to appear in some publisher level reqs as well as individual games, it would make a great deal of sense to have it implemented once at engine level rather than devs reinventing the wheel every time. This unreal plugin is a nice example - https://gritfish.itch.io/ysm.

This is a getting to be a very long post (and without even touching on accessibility of the editor for devs with disabilities and the legality of Unity being used in classrooms.. 508's reqs are a good starter for that) so I'll leave it at that for now.

In closing - since its inception Unity has been a flat out blocker to accessibility, unnecessarily putting up big walls between devs and the players they want to reach. But it doesn't have to be. Unity has great potential to be a force for good, a really tremendous enabler for both developers and players. It is really wonderful to see steps being taken along that path.

Resources -

https://www.gamasutra.com/blogs/IanHamilton/20190123/334910/Demystifying_CVAA.php

https://www.gdcvault.com/play/1025738/Subtitles-Are-Changing-Don-t

https://www.access-board.gov/guidel...of-the-standards-and-guidelines#E207-software

https://www.wuhcag.com/wcag-checklist/

 

I have been doing a lot of things with phrase recognition and speech synthesis in Unity recently. The Windows.Speech namespace has phrase recognition, but no speech synthesis. As a result I have been having to import an InterOp dll into the projects, which often throws errors because it is not native to Unity. The last I checked, Unity runs off Mono libraries, which does have a speech synthesis namespace and respective classes.

So my question is this, why implement one in the Windows namespace, and not the other? It would be so much nicer and cleaner than having to use an InterOp that may or may not work.

 

A built in Close Caption/Subtitle System, for both cut scenes, game play, and videos - especially videos. The last time I checked, videos with embedded closed captions won't display those captions when played in Unity. If I load a movie with embedded closed captions into Xojo's movieplayer they automatically play on macOS, but not in Unity.

Unreal has a built-in subtitle system. I'm sure Unity could do far better. I currently have to use my own subtitle system.

More built-in accessibility features mean Unity is more accessible to disabled developers, and products made with unity will be more accessible to disabled players.

 

Absolutely. Feel free to reach out at any time.

 

You've articulated this very well. In work meetings I've had to explain these newer technologies to co-workers to help communicate why I'm having difficulty getting 508 compliance/accessibility out of the box. I used the analogy of the Unity content being a "movie". I likened it a video clip playing and went on to explain that even adding things like alt-text to images within that movie is difficult without specific tool sets to do so.

I have done a ton of research and I find it interesting you mentioned the BBC. I came across them repeatedly and found one of their contracted developers who developed a good amount of their web interactives - a company called Goodboy Digital. They used a Javascript library called Pixi.js. This same company has contributed to the open-source library and integrated accessibility features into it. This was one option to utilize, but I kept coming back to my own ease of use with the Unity editor. Check out this article about what they've done to some of the code to enable accessibility for something as trivial as a button.

https://medium.com/goodboy-digital/pixi-becomes-accessible-9d36eec3720c

 

Closed captioning is a difficult subject because there's very specific timings to be had for each region. It's not as simple as "oh lets just fansub this bit" - the timings are laid out clearly on the BBC's website which are typically the benchmark for all media to come.

For someone who can hear, reading subs slightly out of sync is not a problem (foreign language) but for those who can't hear, it's a big issue because we do rely exclusively on timing of sub to digest it before glancing at the action, and this is a huge deal for cutscenes.

HOWEVER! for gameplay where the text stays around (dialogues) then this is not a big deal but I have much more to offer on the subject.

(Need to join alpha actually, sorry staff! forgot)

 

I have a very hard time reading the minuscule text or clicking the tiny little buttons in the unity editor gui.

Some of those ui buttons are literally the size of a grain of rice, requiring superhuman eyesight and hand dexterity, it's a constant source of pain and frustration. you have to be a surgeon to use unity!

please x2 the size of all gui elements by default. not just for people with vision problems, for average people with average eyesight like me who dislike headaches.

Keep up the amazing, work!

 

The wording of @mlspanbu's original post suggests that the UX team wants accessibility feedback for developers working within the Unity editor rather than for end-user builds. But maybe the response here indicates that end-user accessibility features are a higher priority for devs. Perhaps some accessibility features can cover editor users and end users both. If UIElements is eventually expected to be available at runtime, this seems like a good time to make sure it does a good job with accessibility.

For pure in-editor accessibility, in addition to font size (which is of course the main issue everyone mentions), it might help devs with physical challenges if there were alternate options for certain actions. For example, if you need to shift-click something, maybe the UX team could add a way to accomplish the same task without using two hands. Or maybe there could be a temporary zoom to make it easier to click on very small UI elements.

 

They're actually looking for feedback on both things, the editor itself and what they can do to support developers' efforts to make games accessible. Also feedback on other areas like accessibility of the website and asset store too. Anything and everything

 

Yep they did that work on pixi.js specifically to meet the BBC's accessibility standards Reason for me mentioning BBC is that I used to work there (though quite a while ago now). They have a big roster of third party suppliers who I'm sure would dearly love to all be working in Unity.

 

Hello,

I have done some work on trying to make the unity developer experience better for screen reader users:

https://github.com/frastlin/ScreenreaderAccessibleUnityTemplate


The editor itself has no speech feedback whatsoever. The menus are completely accessible though. Being able to access prefabs is a major downside to Unity.

I see two ways to make the developer experience better for screen reader users:

1. Allow everything to be done in code. Currently Unity is like a part code part WYSIWYG editor. The most inclusive situation would be if one could develop either completely in code, or completely in the WYSIWYG editor, or use some combination of the two. This would put Unity on par with most game engines like pygame, Babylon, or Panda3D.

2. Add speech feedback, either through: adding buttons and or making the whole UI a menu, or adding speech support through TOLK or some other screen reader interfacing library (that should be a part of Unity for both developing and games).


These two options are not mutually exclusive.

I would love to test or be more detailed in my observations, just let me know what you need.


Also, see the Accessible Unity Template, that could use some more funding and support so that it works on web and Windows:

http://metalpopgames.com/blog/2017/05/03/unity-accessibility-plugin/

 

Yep absolutely. There are a few sets of algorithms available, none of them are 100% perfect but the most accurate I've seen are the ones used by Color Oracle, they're accurate enough that I've never had a false positive. It's open source so you can just have a poke around in the code and see how they did it.

www.colororacle.org

Or go direct to source and have a look at the academic paper that underpins it -

http://vision.psychol.cam.ac.uk/jdmollon/papers/colourmaps.pdf

There are also some subtleties around labelling and presentation, where it lives and what it affects, and how to handle varying severities. That's probably a conversation for a little further down the line though.

 

Hi
We are developing audiogames for the blind community, and we ended up building our own game development tool under Unity to build our games faster. Our goal is to make this tool accessible, so blind people can become game developers themselves, and get a work opportunity in the gaming industry.
But that it is not going to happen that easy, if we have to do it alone, so we really appreciate that you started to talk about how to make Unity more accessible.

Definitely we would like to help, and absolutely it would be lovely if you help us!

Would you mind to reach us by email or by phone?
my email; david(a)mytruesound.com
the phone can be found on our website

Best regards
david

 

Hi, this is great timing. I just supervised a bachelor student thesis looking into issues of implementing screen reader support in Unity. If you contact me I can put you in touch with the students; the thesis is written in Swedish ... My email is thomasw@dsv.su.se

 

As a developer on Unity for a fairly extended period, I have to say : The new approach to the input manager is long overdue and I want to take a moment to convey why this is such a problem.

For the longest time (literal years) we've been told that an input manager that is inherently flexible, swappable, and runtime configurable was "around the corner" complete with it showing up in a few betas. It has never manifested. I would theorize that this is because it has had a number of unexpected problems in corner cases and backwards compatibility and with the vast range of bug fixes and new features suitable for triple-A and cinematics, it just wasn't a priority. The convenience of a better structure to handling input, or being able to implement input configuration without relying on remapping via scripting just isn't worth the headache. The problem is that this view assumes that the only result of an improved input mapping system is convenience. It's not. This is a pivotal part of simplifying and standardizing solutions to a lot of the challenges faced by developers face with movement impairments.

As an instructor teaching students to use Unity, being able to streamline the process of remapping keys transforms the task of developing alternative control options from an intermediate challenge that may demand my students must spend potentially a week learning, implementing and testing, into a beginner task I can walk them through over an afternoon. This changes how early I can introduce future developers to accessibility as a problem for them to address. Visibility like this really matters.

 

I just rolled my own. It wasn't too difficult to build an input manager that remaps to keyboard/mouse/controller.

 

Hello.
I am a blind game developer. I have used Unity twice myself; once in my work at a company and once in a project I personally worked with one of my friends (he is sighted).
First and foremost:
There is a huge obstacle when blind developers want to set up Unity editor. It's the survay form displayed for the first time I run the editor. Apparently it is web-based, but it is hard to navigate using screen-reader application since the web form is enbedded into one of the editor's child windows. It would be great if this form could be completed using preferred browsers like Chrome.

Game development:
I did most of the stuff using scripts.
I coded a quick editor extension for reading errors and knowing when compilation has finished.
https://github.com/yncat/unity-access
However, this is not perfect in fact. While the editor extension is recompiled, I can't track down errors since the console window in Unity editor is inaccessible at the moment.
The only way left for me is see the log file saved in appData/local/temp. However, this file is locked until the editor process exits, meaning that I need to close the editor whenever an untrackable error happened and my project didn't run. I wish there was an option in the Unity editor native level, which outputs errors in a specified file without always locking it. (When an error occurs, open the file handle, append error text and stack trace and close the handle).

Options:
I asked a sighted developer to change my editor settings so that settings were saved as text (yaml-ish markup language IIRC). That way, I can change settings using my code editor.
Obviously, I can't change the first setting (options output to text). A possible solution I can come up with is adding some commandline options about accessibility.
Examples:
unity --settings-as-text (Changes the way of storing options)

Commandline options have lots of potencial in my opinion in terms of blind accessibility; most blind devs are used to CUI, and devs in the Unity technologies could implement what executes what was instructed in the commands.
I'm very much looking forward to seeing improvements of Unity and the day I can fully utilize this fantastic engine.

 

I manage a small indie game studio called Blind Sparrow Interactive. Our projects put accessibility - blind accessibility, in particular - at the forefront of all that we do. We can't echo loudly enough Ian Hamilton's comments (above) with regards to the importance of Unity being able to natively access VoiceOver in iOS projects.

VoiceOver has been a highly regarded and prominent feature of the iPhone for years, yet still doesn't have Unity support. We enjoy working in Unity, but for our studio, and for many studios who are wanting to make their projects more accessible, it's a borderline deal-breaker. Forcing smaller studios to voice everything written, or to use work-around plug-ins, for what should be a mandatory tool set, is not only costly but detrimental to the quality of the products that can be created and offered.

There's an opportunity here for Unity to not just meet the minimum standard, but to lead the way - to create a tool set that ensures designing with accessibility in mind is effortless, enabling developers to create games and software applications that can be used by more people. The ultimate goal is that everyone can play; everyone can access the information they need; be included; participate; be united.

 

Hi James,

I'm the creator of said plugin. It comes with full source, if that helps. So you can also use it as the base for your own implementation.
The Unity download package does include precompiled libraries for Windows and Android speech output. These aren't used on WebGL, though, and I've been giving out that source to anyone who asked for it, too. I just didn't include it in the package because it will confuse users into thinking they have to manually compile dll or jar files.
Contact me if you need anything!

 

I really need larger font on the editor. I fear that my Unity days may come to an end if this does not happen in the near future. I have wrote about this before on the forums, and even filled out a form to send to Unity, but nothing has happened so far.

I tried out some new test editor and the font was even lighter, less contrast. I sent my thoughts to Unity.

I have lowed my resolution on my monitor, changed my brightness, moved my screens closer and still does not help. I can use FB, Discord, and Chrome without a problem due to easy to change font sizes and contrast.

I have vision problems that can only be partially fixed by my glasses and as I get older, it gets worse. I am certainly not old enough to give up my Unity. LOL

So please, Unity. I cannot be the only one. I have met many over 40 here.

 

hello guys,

Well, I'm a blind (zero vision) developer that want for a lot of time can use Unity...
but, I've tested the last versions and that is the I can got.

1. The new unity hub for download versions, create projects and other sstuffare very well, because is HTML and javascript based.

Various things are bad tagged like the icons and buttons for go to the versions bpanes, project area , et, but is understandable because appear the code function path of each thing, and well. You can use.

2. a important error is when you are creating a project, if you use the browse button to change the project location, after accept the new location in the select folder dialog, the hub return s to the roject page instead continuing with the new project dialog, so you loose your new project dialog so you have to restart again, and if you want change the location, you can't use the select folder dialog; instead you have to put in the editBox the folder path that you want directly.

3. after the project was created, when the editor is launched, the only thing that you can read with your screen reader (jaws for windows or non visual desktop access) are the menus in the top bar.

You can interact with them, but if you open a dialog like build options, preferences or the object yerarchi or something similar, the screen reader can't read nothing.

So, something simple like plaze a game object, attach to it a game script and open it in to visual studio to try to create a project only with a script, currently is imposible.



that a is a small blind report of accessibility . ths was sted with the last alpha using vs 2019

¡thanks!

 

There IS a way to get Unity to give speech feedback, I use it often. It's by no means the best option as it can only use system level screen readers, and it doesn't always work.

 

Hey everyone,
I'm a game developer and student and I'm currently doing my masters thesis on vision accessibility of video games in the context of Unity. For that, I'm currently building a Unity plugin that brings several elements to Unity which make it easier to build games accessible to players with vision impairments. Everything will be open source as soon as my thesis is done, but I would love to see that a bunch of stuff is not needed anymore in the future because it will find its way in the editor. Even though its awesome that they even exist, plugins like the UAP or the thing I'm building will never have the same impact as if Unity does something directly, both because of discoverability and because most of these plugins have a price tag on them.

So here are a few things I would love to see in Unity:
- Access to the native Speech Synthesizers of every platform: Almost every platform offers a speech synthesizer right now, having access to that would make it a ton easier to make stuff like voiced menus
- Having access to system accessibility settings: Settings like "Increase contrast", "Reduce Motion", "Reduce Transparency", "Bold Text", "Large Text"... In form of a value that tells the developer if "Turned on, Turned off, Not Available". It is unnecessary to have the user turn on settings in-game if the information could be read from the system.
- Provide a hook for Unity UI elements into native screen readers (like VoiceOver): As Ian said, UAP is a necessary hack, but it would be far better if you could provide a hook to screen readers out of the box.
- Provide something similar to an UIAccessibilityElement, which can also be detected by screen readers (should be the base element for the point above). Having this element alone would make it super easy to make a ton of games accessible (Games where the interaction can be broken down to: changing focus between elements, selecting an action on that element and performing the action. Simple example would be a Match-3 puzzler)

There is still a ton of stuff besides these four things that could be built for Unity (like a solid sonar system), but these four seem to be reasonable to put into the editor.

Best,
Klemens

 

This is an excellent discussion so far with lots of great suggestions. I also couldn't agree more with Ian Hamilton's posts. It's great that there is a Unity plug-in, but a third party hack shouldn't be necessary, and will be difficult for the developer to keep up with the pace of overall Unity updates.

It would be very helpful if game engines like Unity and Unreal would be able to natively be able to pass information along to assistive technology hardware and software. IOS and Android have VoiceOver and TalkBack respectively. Mac has VoiceOver. Both Windows 10 and XBOX One has Narrator, and even the PS4 has a built-in screen reader. All these platforms also have other accessibility features like magnifiers/Zoom options. Then there's the Microsoft Adaptive Controller. Game engines like Unity should be able to natively support these built-in assistive technoligies at the very least, if not support other third party screen readers like NVDA for Windows.

As more focus is being put on 4K and even 8K resolutions, text scaling, and a wide variety of font size options will be crucial! As a legally blind gamer, I can't tell you how many times it's hard to read tiny menus, endless stats screens and upgrade trees, etc. Text scaling, font size options, and more integrated text-to-speech support would be extremely helpful to both blind low vision users. Even if I can see well enough to play a game, I'd love to be able to save my vision for playing the game, and not struggling to read its menus and other UI.

Unity is also widely used in VR. As a VR enthusiast myself, I find many similar low vision problems in VR that I do in a flat screen game, but also a few unique challenges. Text is often too small, and in VR, too far away. Text and other UI is often placed at a fixed distance from the user's eyes, even when full head tracking is supported. So moving or leaning forward doesn't help, but instead pushes the UI back to maintain that 20/20 visual distance. Combine that with small text, low contrast, and unique VR interfaces for almost every title, and things can be challenging.

Microsoft has been working on a fantastic sounding tool called SeeingVR, and I genuinely hope this tool, or something similar can be natively added into Unity and other game engines and VR dashboards *cough* Oculus *cough*

You can find a video demonstration and explanation of SeeingVR here:

You can also find my YouTube playlist on VR Accessibility here:
https://www.youtube.com/playlist?list=PLSU1VYOSxLf2pY1dAn8gJU7RUQwgloMNj

I know this post is getting long, but I want to tie everything together with one more point.

Adding all of these accessibility features is important, but it's equally important to:

1. Make them easy for developers to use and implement in their apps.
2. Publicise widely and often that your engine supports this.
3. Actively encourage and/or insentivise developers to use these accessibility tools and features.
4. Make accessibility just another core part of developing for Unity, like graphical performance or any other common aspect developers expect in a game engine.
5. Provide some built-in reminders, wizards, and checking tools to verify at least a base level of code, object, and item labels accessibility. Does an app meet controller customization option standards, include color blind modes, text labels for screen readers, etc?

I know automated testing only gets you so far. True testing requires actual users. However, including some automated reminders and checks for such features will get developers thinking about accessibility early and often in the development process, when it's most easy to start implementing. It also makes them aware that Unity would support such features.

OK, I'm done for now.

 

Quite a blocker but one that's easily fixed - I've heard from some blind people who are unable to leave comments here because some areas of the form to sign up for a unity ID are not screenreader accessible.

 

I would direct you to a Unity Feedback post of mine from last year, with a detailed proposal for Accessibility tools ... oh right, it's gone.

Not being bitter , I'm glad this is finally taken care of so here goes my feedback (sorry if some things were already proposed, will read the whole thread later):

I have personally tried to deal with the visual side of accessibility by using OpenCV within Unity for stuff like edge detection, but it’s definitely not the most efficient option. It would be great if a lot of the visual tools could be implemented within the post processing stack (currently there's a preview option for people with color blindness), or some other way that would not decrease overall performance and would be easy to implement at the same time.

Some of the things I mention below are more in the “best practices” category and it would be a bit challenging to make them into “tools”. For those issues a clear and simple checklist might be already very helpful. Others, like game speed control, or text2speech for example and most of the image processing and an accessibility mode at run time, could be included in the accessibility unity package as proper tools.

There are various things important from the point of view of accessibility in games:

• Ability to remap controls
• Control over camera/controls sensitivity
• Ability to control the game with one hand - only keyboard/mouse or just one hand for a touchscreen device
• If possible allowing for UI customization - increasing button size, relocate different elements on the screen
• Sometimes even an ability to skip some difficult part of the game is a huge help for disabled players and allows them to enjoy the rest of the game.
• Ability to slow down the game.
• Separate volume controls/mute option for different sound sources - music, sfx, speech etc.
• Custom “accessibility” mode should be saved as preset

In terms of visual and audio aspects of games:

• Being able to increase contrast, or for example replace texture sets to a very strong intensity and color contrast with blocks of color rather than relying on small visual details
• Including options for drastically changing the game’s appearance - edge detection, b&w version with a variable threshold. This might be very important for players who are visually impaired.
• Adding optional visual “highlights” along with audio cues for important and interactive game objects
• Color blind “preview” - ability to preview the game as players with different types of color blindness would see it - for example to check if the UI is still readable and clear
• Other visual disability previews - blurring, reducing contrast etc. in the same manner as with color blindness, create best-as-possible visualization of a game.
• All “preview modes” should be accessible from the editor window and development build. Another option would be to create an external tool that could process a video
• Text2Speech tools that work for all parts of the game - GUI, chat, dialog options etc.
• Subtitles for any important speech elements
• Ability to change font color and if possible font size
• Ability to recreate all visual cues and elements with audio and vice versa - recreating important sounds with visual cues. Haptic cues work also as a substitute for visuals and sound.

Just as Unity has some sample projects for 3D, or 2D workflow, animation or render pipeline, I hope that an accessibility package/sample project could be created. If you would be interested in this project I'm pretty sure it would have a tremendous impact for many people.

 

Dark mode should not be exclusive to Unity plus/pro. It's an accessibility feature.

 

I don't know what the new unity input system will be like (or when it will make an appearance, I feel like it's one of those things that will still be a long time coming?) BUT I did put a lot of time into making a more accessible input wrapper for unity, some important things I did were:
- 100% rebindable, with the option to expose sensitivity/invert stuff.
- hold/toggle options for inputs
- useful functions like GetButtonDownRepeating() so menu navigation can scroll by holding a direction (with options for how long of a hold before it scrolls past the first option, and how quickly it scrolls)
- Can be used to navigate canvas UI elements

There is probably some more stuff I'm forgetting, but it is here (and free) if you want to check it out:
https://sophieh.itch.io/sinput

I think most of these options should be standard in most games but implementing them in unity without my system is a huge amount of work per game, so I'm hoping that when the new system comes, it has all of this stuff AND is easy to implement - it's only partway helpful having accessibility features but if developers have a hard time implementing them then some will skip it and many players won't benefit.

Also, I've not looked into it for a while but being able to integrate with mobile accessibility features to make games & interfaces blind-accessible without having to write our own implementations of them would be especially cool

As for the editor I don't have any real accessibility issues with it myself that I can think of, except that over the years the editor seems to have become a lot more suited for teams than solo developers? All the new additions are cool but require a lot of time and in-depth knowledge to set up, my development time has gotten a lot slower over the years and I don't think the main reason is that I'm getting older

Anyway I just want to say thanks for reaching out about this stuff, I'm excited to see what improvements are made

 

There are a lot of accessibility features built in to the OS that are quite difficult to gain access to, through Unity. Having to write iOS and Android plugins, and figure out which MS libraries are or are not compatible with Mono, is extremely time consuming, especially considering I’m primarily a Windows developer with limited access to a macOS computer to test iOS builds.

While those native APIs are of course not equivalent in interface across systems, it would still be nice if Unity provided a namespaced, thin wrapper over them, just as an early stop-gap solution. It would make it a lot easier to write a higher-level, custom, purpose-specific wrapper around those APIs, rather than having to wait for a complete, fully-capable, unified API provided by Unity. That would certainly be great, too, but it’s no easy task and it seems like it’d be a lot quicker to provide this sort of escape hatch than to wait for a full—potentially huge—system.

I see this as very similar to how a lot of the native UWP input and speech recognition is available in Unity, for support of HoloLens. Similarly having every native API exposed, regardless of feature disparity, would take a huge chunk of time and testing out of my day.

 

We at Laerdal Copenhagen have been working on accessible medical simulators in Unity for over a year. We've tried various approaches to accessibility, all involving some kind of HTML. I've skimmed this thread, and will be reading all the comments in more detail soon. I look forward to further correspondence on this topic, either here, or by private message.

I happen to like HTML very much, and it is very good for some of the document-centric content found in our simulators. (e.g medical records and feedback - lists and tables). It also does a very decent job of representing semantically explicit GUI controls. But we also have to represent a 3D scene with nurses and patients and whatnot, which is very much Unity's force. And that's why we are using Unity. Also we want to target platforms outside the browser (chiefly iOS and Android), but because of accessibility, at the moment we can't see a pathway that doesn't include some kind of webview, or platform-specific accessibility sidecar - a second class citizen, in other words.

The lack of access from Unity to the underlying accessibility APIs on those platforms is a huge handicap. This is especially frustrating because I know those accessibility APIs are quite sophisticated - especially on iOS. So near, and yet so far.

I don't regard third-party plugins as a viable solution. Some of our products are intended to be in use for many years, and having to rely on multiple vendors for supporting the core architecture is too great a risk. Unity, iOS and Android will all grow and change over time, and I am not confident that the plugin vendors will keep up. It multiplies the possible points of failure unacceptably in a situation where we are aiming to help save lives.

If I should point at the greatest weakness in the 2d part of Unity (which we might have used - and indeed tried to use - to draw the GUI) it is the poor semantic model.

Unity's 2d primitives are (pretty much) a semantics-free zone. To make a heading, you turn up the font-size and put it at the top. It might look ok, but unless you explicitly tag it as a heading somehow, it's not 'really' a heading, it's more like a 'cargo cult' heading. A heading is not just "big text at the top". It means something special in relation to the content as a whole. That's semantics. Unity can make buttons 'disabled', but most disabled users won't know because the Unity runtime will only express that disabled state using purely visual means, implicitly, not explicitly. If the users have poor vision, that button state is written on the wind.

Conversely, WAI-ARIA provides a maturing and well-tested, well-discussed model, with a public roadmap, already followed by the major browser and assistive tech vendors. They've taken great pains not to tie it down to HTML, or to the browser. It's not perfect, but frankly, it's the only game in town where following the rules and conventions will get you anywhere close to passing a WCAG audit.

And there is a legal dimension which will (currently) rule out Unity in many cases. North America, the EU and other jurisdictions now require WCAG compliance (or something comparable) for public sector procurement, with requirements for the private sector on the roadmap for the near future. If Unity technologies hope to see their technology used in the public sector now, and in the private sector tomorrow, they certainly must prioritize accessibility for end users of the runtime. It's literally a dealbreaker.

My own bias is for accessibility features in the runtime, so I would certainly prioritize that, but as this thread shows, making the authoring tool more accessible would also have some value.

One final comment: Semantics is really not that hard, unless you don't consider it. But first you have to know what it is.

 

once I tried to make unity editor more accessible for a customer of mine which became blind.
I could add some stuff easily using NVDA screen reader's scripting mechanism. what I did was basically tracking active selection and sending it to NVDA to be read.

There are however issues which if resolved can help a lot with accessibility and some of them are not that hard to implement properly. namely

- being able to use shortcut keys to focus project view, inspector, hierarchy and any other important window without doing a click.
- make tab capable of going to next component when moving between fields in inspector.
there is another thing which is much harder to develop probably but still, if unity could report to windows magnifier/osx's zom feature that where it should focus when users move between fields in inspector by using keyboard (tab key) or in project view/hierarchy , that would be great as well.

 

I was chatting with my former counselor from college, and he was giving me tips on how to handle interviews and what not. He is a mid 40's man and is blind. He asked me what is a UI/UX developer - I answered his question- and he told me that actually is really important especially for b=people with visual disparities. He uses shift in order to listen where he is in the computer in order to type in handle office tasks. My question here is, is there any way to use that functionality in the editor?