At Unity, we want our product to be usable by people of all abilities. To that end, we are focused on improving the accessibility of the Unity Editor, the Unity Player, and services.
We invite you to:
share your current experience with the product;
share any early concepts or ideas; or
start a discussion about your needs from software generally.
Our hope is to start a respectful discussion around inclusion and productivity where all users feel valued and heard. Although we evaluate Accessibility against guidelines and checklists, the best improvements come from listening to users. We know there have been many comments on various parts of the forums about these issues, and we hope that providing an official channel via this thread will send a clear signal that we are listening and ready to learn.
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.
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.
I completely agree. We are aware and have been looking into this for a few months. I don’t have a timeline yet. For 19.3 we have worked to make some of the smallest text a bit larger so that the font is always 11px or larger. This is a very small step and we know it’s not enough. 11px is TINY but this is much larger than the previous 6px text in some areas! We are taking tiny steps in the right direction. This is a very good comment highlighting an important need for sure.
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: Unity: Not Quite So...Unified?
We also discussed to some extent and gathered some information about these things here: FCC / CVAA discussion
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 - Yellow Subs Machine by Gritfish.
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.
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.
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.
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.
The wording of @maryllu '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.
