A blog post over on Gamasutra by accessibility specialist Ian Hamilton outlines some of the rules and regulations on the 21st Century Communications and Video Accessibility Act 2010, as well as more details on how it will affect developers for games made after January 1st, 2019.
The post goes through how games containing advanced communication systems for multiplayer games will need to comply with the CVAA or run the risk of being reported, which can potentially end in some hefty fines at up to $1 million.
The point of it is to ensure that games containing multiplayer chat or text chat are accessible by those who are blind, have low vision, no color perception, who are deaf, have limited manual dexterity, limited reach or strength, have a prosthetic, or slow movement.
We cover the nitty gritty of the CVAA in a separate article, but the Gamasutra post attempts to cover more of the questions and concerns raised by developers (mostly indie devs since implementing accessibility solutions such as text-to-speech for the visually impaired or speech-to-text for the hearing impaired can be costly and detrimental to the developmental roadmap for smaller projects.)
There are a few sections in particular, however, that some indie devs may have trouble with.
For instance, in one section it states…
“The requirement people have the most trouble getting their head around is how you would approach accessibility for people who are blind, but it’s reasonably straightforward. Allow players to navigate UI elements digitally (e.g. press right to move to the UI element to the right) rather than using a cursor as blind people can’t see where cursors are, and offer/support optional text-to-speech so the labels of UI elements can be spoken out as they’re highlighted.”
There’s a fundamental problem with this: not every game has a horizontally/vertically linear layout. Some times games have a mixture of design layouts for the options menus, such as Super Smash Bros. Ultimate or Super Indie Karts.
In the case of Super Smash Bros. Ultimate, the options menu is radial.
In the case of Super Indie Karts, the game menus are floating.
Both games have multiplayer features.
Does this mean that games using radial or floating menus also need to change the way they’re setup so that they have a more linear UI layout, sort of like classic games like DOOM, Mario or Sonic where the menus are static and linear? Or is floating menus and radial menus okay so long as they can be accessed via a digital pad?
According to Hamilton, he notes via Twitter that regardless of the menu setup or layout, they simply must include a digital option since cursors are not viable for legally blind individuals.
CVAA requires accommodations for people with limited dexterity and no vision. Steering a cursor around with a mouse/analogue stick is pretty much impossible for people with no vision, and analogue stick cursors can present pretty big barriers for people with limited dexterity.
— Ian Hamilton (@ianhamilton_) February 3, 2019
Hamilton also suggests offloading the brunt of the work onto game engines, noting that widely used engines could add text-to-speech options for blind users at an engine level, writing…
“Text-to-speech has some cost and technical issues; it could be handled at a cross platform level by engines by default, but currently is not, resulting in unnecessary costs to developers. Feature requests have been made for the past 10 years, but with no result; more devs need to ask for it.”
This, however, doesn’t address games made on custom frameworks, or smaller engines from companies like Kadokawa or YoYo Games, or independently made engines like the one that powers Univoyager, which would have to design these features from the ground up to be compatible with their frameworks.
Hamilton does address this conundrum for mobile multiplayer games in particular, noting that due to the current limited functionality of mobile devices, this could pose a problem for developers…
“It makes mobile in particular really problematic. Blind accessible mobile UI interaction is normally handled at platform level, by overriding how gestures work. So until engines start exposing their UIs in a way that platforms can work with, the only options at the moment are to replicate the platform level functionality in-game (a huge amount of work), to use a plugin which does that replication for you (Michelle Martin’s Unity Accessibility Plugin), forgo engines and build as native apps instead, or skip chat entirely.”
Another major issue that many games will run into is speech-to-text.
Now at the moment, almost every major VR multiplayer game relies on voice chat. Speech-to-text is already a rarity in most major games and is practically non-existent in the VR space.
[Correction: The previous version of the article stated that only the Xbox SDK was available as a speech-to-text middleware solution for game developers, but Ian Hamilston states that other cloud services also offer speech-to-text, but whether or not they are compatible with a game in development will require the developer to investigate on their own]
Hamilton notes that there are various cloud services afforded to developers to tackle speech-to-text from a middleware perspective, with Microsoft’s Xbox SDK specifically being made avialable for games, writing…
“One of the other considerations has some trickiness; speech-to-text, which is not feasible for a developer to build themselves, so instead requires use of a third party cloud service. Xbox currently provide a cloud speech to text service for free for Xbox and PC games through the Xbox SDK (along with other services such as text to speech API for UI). Speech to text transcriptions aren’t 100% accurate and incur latency on the player who is using them, but that’s better than not being able to communicate.”
Obviously, this means games like Star Trek: Bridge Crew – if it were being made after January 1st, 2019 – would need a serious overhaul given that the entire multiplayer VR component relies heavily on voice chat and it does not have a speech-to-text component. So if a newer game was to be made, they would have to find some way to implement that visual experience for deaf gamers without obstructing the viewspace of the VR game.
This would also really hamper games like Sariento VR, or Trickster VR or any other number of VR games with multiplayer communication functionality where teamwork and timing are key to success. Also how about future projects based on concepts like VRChat? As popular as that app is it definitely doesn’t comply with the CVAA, since it has voice chat and text chat but no text-to-speech or speech-to-voice options, as demonstrated in Jameskii’s video.
As Hamilton notes, if developers are unable to find a solution to make their game compatible with CVAA, they will likely need to simply avoid adding chat functionality to the game or relying on a third-party service for voice/text chat. [Correction: Hamilton states that if the the criteria isn’t achievable, then the criteria doesn’t have to be met.
“As Hamilton notes, if developers are unable to find a solution to make their game compatible with CVAA, they will likely need to simply avoid adding chat functionality …” – I noted no such thing. If it is not achievable to meet a criteria, that criteria does’t have to be met.
— Ian Hamilton (@ianhamilton_) February 4, 2019
As noted in the post, developers considering voice chat or any form of advanced communication systems in their game after January 1st, 2019 will likely need to abide by the CVAA standards, which Hamilton states…
“The first requirement is that accessibility must be considered from the early stages of development. Like most things in software development accessibility is much harder to consider later, having to go back and unpick decisions that have already been made and systems that have already been put in place. Considering early means you can do a much more effective job for a much lower level of investment.
“The second requirement is that people with disabilities must be involved in the process. Although the FCC has previously voiced support for user research, CVAA does not specify how people must be involved. It could be user research, consultancy, alpha/beta participant survey questions, social media feedback and so on. But the dialogue must happen, records must be maintained of “efforts to consult with individuals with disabilities”.
It’s also noted that if you plan on implementing multiplayer communication systems in your game, you will need to record keep for annual certification. This is done through an application submission put through the FCC compliance certification contact registry, which you can access over on the FCC.gov website.
Disputes and complaints are supposed to take place between the customer and the developer (or publisher) first and foremost. The information in the FCC database is supposed to be the point of contact for complainants.
If that fails, then a mediation period begins with the FCC, and if consumers continue to have an issue with the game, they can pay a fee to escalate the complaint, for which an investigation may ensue for up to six months.
In the FAQ at the bottom of the article it reiterates that if you plan on including voice chat or text chat or any mixture of the two in your game, you will need to register…
“Unfortunately, unlike some other accessibility legislation, CVAA doesn’t have a blanket exemption for small companies. If you’re providing a communication service, you must register on the FCC site and meet the record keeping obligations. BUT you are only required to make accommodations that are achievable within reasonable effort and expense; you submit a case of what is unachievable and why to the FCC, and they make a call on whether that’s reasonable. To avoid any shocks further down the line you can submit your achievability analysis for confirmation early in development.”
If you don’t have any communication systems in your multiplayer game then you’re clear. And while the CVAA is based in the U.S., the FAQ notes that if you plan on selling your game in the U.S., you will need to comply with the CVAA.
Now there is a way around this if you’re a foreign studio making a game you plan to sell in the U.S: You can regionally disable the voice/text/chat options for U.S., gamers to get around that issue.
Another upside is that it states that no lawsuits can be brought against studios for failing to comply with the CVAA. All disputes are resolved through the FCC.
So what if you want to keep voice chat because it’s a necessary component of your game (i.e., asymmetric multiplayer cooperative games like Daemonical, Dead By Daylight or Friday The 13th) and you decide to defer the feature to third-party communication services? Well, according to the FAQ, we won’t know how the FCC sees this until it’s put through its paces. It states…
“The grey area between is if you’re instructing players to use a specific third party, e.g. “communicate through Steam chat”, “find party members though Discord channel [X]”. Who liability lies with in those kinds of situations won’t be decided until it is properly put to the test through an FCC complaint, so until then it’s probably safer to err on the side of caution and assume liability would fall on you.”
So what if you decide to say “screw it!” and just do your own thing and completely ignore the CVAA by not registering or not removing your multiplayer chat feature, or not implementing proper accessibility features? Well, if the FCC fines you in fault of not complying with the legislation, you could end up facing fines of anywhere between $100,000 and $1 million per violation.
More than anything, I can imagine smaller developers likely avoiding the hassle and heart ache by just removing multiplayer chat from their games altogether.