Demystifying CVAA

CVAA is accessibility legislation that affects games sold in the USA, including through digital storefronts like Steam. CVAA requires communication functionality (which it defines as text/voice/video chat) to be made as accessible as reasonably possible to people with disabilities.

After being signed in back in 2010, the compliance date for the CVAA communications accessibility legislation was set for 2012. Through negotiations between the ESA and FCC the games industry was granted a series of extensions to this, to allow extra time for R&D and implementation. The final extension for game software expired on Dec 31^st 2018.

Even though we’re now past the compliance deadline there is still a huge amount of uncertainty and misunderstanding around what CVAA does and doesn’t mean. This post aims to help with that.

As well as covering the basics of how CVAA works I’m also covering some of the more specific and in-depth concerns and questions that devs have been voicing. This isn’t a short post, but there’s a quick summary available too if that’s what you’re after.

First a disclaimer:

While this content is accurate to the best of my abilities, I am not a lawyer, and this post cannot be taken as qualified legal advice. It is the result of conversations with a number of FCC staff, up to and including Karen Peltz Strauss (a key author of and driving force behind CVAA), but equally cannot be taken as an official FCC perspective.

So, what even is CVAA anyway?

Americans with disabilities have had a legal entitlement to use communication technology since the Americans with Disabilities Act was signed in 1990. That entitlement is, for example, the reason why phone networks are required to provide telephone relay services for people who can’t speak or hear.

The 21^st Century Communications and Video Accessibility Act 2010 came into existence because the way technology is used had changed since 1990. It contains two parts:

Does CVAA apply to me?

CVAA’s communication article (#1 above) covers communication services in all industries, including communication present in games. If you’re providing player to player communication via text (messages sent between individuals in text form in real/near real time over communication networks), voice (voice over IP) or video (interoperable video conferencing) in a game for release in the US market, that functionality falls under CVAA.

CVAA is a law relating to communication, not relating to games. So it does not require accessibility of gameplay in general, it starts and finishes with communication.

To what degree CVAA applies also depends on achievability. That means only criteria that fall within reasonable expense and effort, with “reasonable” defined as a balance of what extent of work would be required and what kind of impact that work would have on your product or business (financial, technical, whether it would require fundamental alterations to the product). Also, what kind of company you are and what equivalent products you have available, although those two are less relevant to games. And one temporary; if your game is launching after Jan 1^st 2019 but started development before the deadline, how far through development it was at Jan 1^st can be taken into account.

Of course the reason for considering accessible communication shouldn’t just be CVAA compliance. Communication isn’t just an important aspect of your gameplay, the access it provides to culture and socialising can make a huge impact on people’s quality of life. The benefits go way beyond the immediate groups too. E.g. decent contrast is great for sunlight on screens, being able to communicate by text is great when you’re trying to not wake the baby.

What does compliance look like?

CVAA isn’t specific to games, it also covers things like consoles, distribution/gameplay networks (e.g. Steam/XBox Live), and support channels. But for this post I’m concentrating on games.

Compliance covers three areas;

1. The criteria

2. Some mandatory process

3. Some mandatory reporting

Criteria & example solutions

Briefly, CVAA requires EACH communication service (if you have text chat and voice chat each of them must independently meet all of the requirements) AND any UI or information needed to navigate to and operate the communication functionality to be accessible as reasonably possible to the following groups:

There are two extra requirements that don’t apply to chat itself but do apply to any information needed to use the functionality (instructions, prompts, button labels etc):

There are a few other requirements too, like compatibility with hearing aids. But those aren’t relevant to games, they’re for hardware manufacturers.

External information is also covered, e.g. if you’re providing instructions on website on how to use the comms features those instructions must also be accessible (web accessibility is relatively easy, your front end dev/s should already be familiar with how it works).

You’re free to choose the approach that works best for your own game, but you must validate your choices with the audience. E.g. you might not think free text entry would work for your FPS so consider a chat wheel instead, then speak to deaf gamers about it, and get feedback from them that while a chat wheel is helpful for frantic moments you still need to include free text entry alongside it to allow full communication in slower moments.

The approach you go for doesn’t have to be a one size fits all, modes can be used. E.g. Battlefield v’s options for chat window scale.

You don’t have to do everything in-game either, compatibility with third party accessibility tools is fine so long as the tool is available at nominal cost. This primarily means providing text to speech through compatibility with external screen-reader software, software that blind people already use to access tech.

Below is the full list of all requirements relevant to game chat and related UI, as worded in the text of the legislation. Beneath each item are some examples of the kind of considerations that can help.

But I must stress that these are only examples. CVAA doesn’t require any specific features, it only specifies the end goals.

(1) Input, control, and mechanical functions shall be locatable, identifiable, and operable in accordance with each of the following, assessed independently:

(i) Operable without vision. Provide at least one mode that does not require user vision.

Examples: Text to speech for chat-related UI and for text chat messages. Digital UI navigation (move highlight a UI item at a time, rather than move a cursor).

(ii) Operable with low vision and limited or no hearing. Provide at least one mode that permits operation by users with visual acuity between 20/70 and 20/200, without relying on audio output.

Examples: Large/scaleable UI. High contrast.

(iii) Operable with little or no color perception. Provide at least one mode that does not require user color perception.

Examples: No reliance on color alone to communicate or differentiate information. Testing for contrast issues for common types (e.g. red text on dark background is difficult for people who have difficulty perceiving red).

(iv) Operable without hearing. Provide at least one mode that does not require user auditory perception.