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 31st 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 21st Century Communications and Video Accessibility Act 2010 came into existence because the way technology is used had changed since 1990. It contains two parts:
- The communications article, which ensures that voice over IP, communication between VoIP and phone networks, electronic messaging, and video conferencing are all accessible.
- The video article, which ensures accessibility of streamed broadcast video (not relevant to games, as games generally do not include content previously shown on TV).
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 1st 2019 but started development before the deadline, how far through development it was at Jan 1st 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:
- Low vision
- No colour perception
- Limited manual dexterity
- Limited reach and strength
- Unable to use time-dependent controls
- No speech
- Limited cognitive skills
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):
- Avoidance of common epilepsy triggers
- Ability to pause any moving text
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.
Examples: Allow text input/output for voice chat through text-to-speech and speech-to-text. If anything related to chat is communicated solely through audio cues (e.g. audio ping for a new message arriving), also communicate it visually. Customisable quick chat system for when typing is not feasible
(v) Operable with limited manual dexterity. Provide at least one mode that does not require user fine motor control or simultaneous actions.
Examples: Digital UI navigation (move highlight a UI item at a time, rather than move a cursor). Avoid simultaneous inputs (pressing two things at the same, holding down one thing while pressing another, etc).
(vi) Operable with limited reach and strength. Provide at least one mode that is operable with user limited reach and strength.
Examples: Digital UI navigation (move highlight a UI item at a time, rather than move a cursor). button remapping.
(vii) Operable with a Prosthetic Device. Controls shall be operable without requiring body contact or close body proximity.
Examples: This is referring to skin contact, i.e. capacitive touchscreens. So avoid reliance on PS4 controller/Switch handheld capacitive touch for chat functionality or related UI. On mobile devices this requirement is already met by operating system accessibility functionality.
(viii) Operable without time dependent controls. Provide at least one mode that does not require a response time or allows response time to be by passed or adjusted by the user over a wide range.
Examples: Ensure no interaction or input request has any timeout or time limit
(ix) Operable without speech. Provide at least one mode that does not require user speech.
Examples: Allow text input for voice chat through text to speech
(x) Operable with limited cognitive skills. Provide at least one mode that minimizes the cognitive, memory, language, and learning skills required of the user.
Examples: Text to speech for chat-related UI and for text chat messages. Speech to text for entering text messages by voice. Allow text input for voice chat through text to speech. Customisable quick chat system. Non-verbal messages, such as emotes/emojis/pings. Possible to pause text message feed and scroll back through.
(2) All information necessary to operate and use the product, including but not limited to, text, static or dynamic images, icons, labels, sounds, or incidental operating cues, [shall] comply with each of the following, assessed independently:
(i) Availability of visual information. Provide visual information through at least one mode in auditory form.
Examples: Text to speech for chat-related UI and for text chat messages.
(ii) Availability of visual information for low vision users. Provide visual information through at least one mode to users with visual acuity between 20/70 and 20/200 without relying on audio.
Examples: Large/scaleable text/UI. High contrast.
(iii) Access to moving text. Provide moving text in at least one static presentation mode at the option of the user.
Examples: Possible to pause text message feed and scroll back through.
(iv) Availability of auditory information. Provide auditory information through at least one mode in visual form and, where appropriate, in tactile form.
Examples: If anything related to chat is communicated solely through audio cues (e.g. audio ping for a new message arriving), also communicate it visually.
(v) Availability of auditory information for people who are hard of hearing. Provide audio or acoustic information, including any auditory feedback tones that are important for the use of the product, through at least one mode in enhanced auditory fashion (i.e., increased amplification, increased signal to noise ratio, or combination).
Examples: If anything related to chat is communicated through audio cues (e.g. audio ping for a new message arriving), provide a separate volume slider for chat audio cues.
(vi) Prevention of visually induced seizures. Visual displays and indicators shall minimize visual flicker that might induce seizures in people with photosensitive epilepsy.
Examples: Avoid established flash and pattern thresholds for reasonable risk, testable using the Harding PSE tool.
As you can see there’s quite a bit of repetition. So all together, a featureset for a game that provides both text chat and voice chat might look something like the following. Emphasis on “might”! There are other ways to be compliant, and the approach that is right and reasonable will depend on your mechanic and your finances. So this is not a compliance checklist, just examples.
For chat messages themselves:
- Allow text input/output for voice chat through text-to-speech and speech-to-text
- Customisable quick chat system
- Non-verbal messages, such as emotes/emojis/pings.
- Speech-to-text for entering text messages by voice
- Text-to-speech for text messages
For UI and information used to navigate to / understand / operate chat functionality:
- If anything related to chat is communicated solely through audio cues (e.g. audio ping for a new message arriving), also communicate it visually
- Avoid simultaneous inputs (pressing two things at the same, holding down one thing while pressing another, etc)
- Avoid reliance on PS4 controller/Switch handheld capacitive touch for chat functionality or related UI. On mobile devices this requirement is already met by operating system accessibility functionality.
- Button remapping
- Ensure no interaction or input request has any timeout or time limit
- Possible to pause text message feed and scroll back through
- If anything related to chat is communicated through audio cues (e.g. audio ping for a new message arriving), provide a separate volume slider for chat audio cues
- Digital UI navigation (move highlight a UI item at a time, rather than move a cursor)
- Text-to-speech for chat-related UI
- Large/scaleable text/UI
- 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)
- Avoid established flash and pattern thresholds for reasonable risk, testable using the Harding PSE tool.
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.
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.
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.
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.
CVAA is fairly unique in the broader accessibility legislation landscape in that it does not just require an end result; it specifies how that end result must be met.
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”.
This is always important when working on accessibility, but particularly so for CVAA due to the way it is set up. As you’re free to choose whatever approach works best for your game, that consumer involvement is essential for informing and validating that choice of approach.
CVAA requires records to be kept of the efforts you have made to comply with CVAA, including efforts to consult with disabled gamers. These records just need to be kept, they do not need to be submitted unless a consumer raises an issue.
Some companies (e.g. EA, Crystal Dynamics, Microsoft Studios, Ubisoft) have started put information on what they have implemented online for players to see. While players having information on accessibility is useful, this is not required by CVAA.
Technical and economic achievability is also handled through record keeping. Burden of proof is on the developer, if there's a complaint and the records of achievability analysis are not compelling enough for the FCC the FCC may find against the developer.
So there is a degree of risk involved, the FCC makes the final call on whether your achievability analysis is acceptable.
But that doesn’t have to translate into uncertainty for you. CVAA’s video title specifies that an achievability analysis can be sent to the FCC at any time - I haven’t been able to confirm at time of writing due to the US government shutdown, but I assume the same applies to communication; meaning you can get check with the FCC before you start work, rather than risking waiting until an issue is raised.
The final required aspect is annual certification, due by April 1st of each year. This is the only thing you’re actually required to send over, and is very light touch. You enter up to date contact details for whoever at your company should be contacted about CVAA issues (these are the ones publicly searchable on the FCC website), confirm that you are keeping the required records, and submit. The forms aren’t currently available due to the ongoing government shutdown, but once that’s out of the way you can register and submit here.
The record keeping obligations live outside of the ‘reasonable effort and expense’ leeway. If you’re providing a communication service, you must fulfil the record keeping obligations.
What if there’s a complaint?
This process is very different to most other legislation; enforcement takes place solely within the boundaries of the FCC, rather than being subject to courts and lawsuits.
The first step is optional, a consumer contacting the company directly. Companies can be contacted via the contact details registered with the FCC, which are freely searchable by the public.
The second step, which can take place instead of or after the above direct contact, is for the consumer to make what’s called a request for dispute assistance. They contact the FCC with details of the issue they are facing and what might fix it; the FCC then opens a three way discussion with them acting as a mediator, with a 30 day window for the issue to be resolved. At this point they will ask you for your documentation, so you can prove what efforts you’ve already made to address issues and engage with the community, and what wasn’t possible and why (including any achievability assessment). If you have not kept documentation you’re already in clear violation of CVAA, so always make sure you’ve documented properly.
Once this 30 day period expires, the consumer has three options; 1. Close the issue 2. Authorise an extension to the initial window (for example if a fix has been agreed but isn’t possible to implement within the 30 days), or pay a fee to escalate it to a complaint, which is a full investigation over up to six months.
CVAA has been around since 2010, with most industries having to comply since 2012. Between 2012 and 2018 there were around 70 requests for dispute assistance. Every one of those was resolved (fixed or dropped) through the mediation process, to date none have progressed to a complaint.
However this does not mean CVAA should not be taken seriously. The FCC has a number of means of persuading businesses who are choose not to play nicely, including impositions of fines of up to $100,000 per day, to a maximum of $1m per violation.
So on to the last section; getting to the bottom of some of the things people have been scratching their head over. The following are all questions posed by developers, some from recent weeks, some over the past year, some going back further still.
My game can’t be played by people with disabilities. So if gameplay isn’t accessible, why should the communication be accessible?
CVAA covers conditions like colourblindness, deafness, dyslexia. There is no reason why any of those people should not want to or be able to play your game. People who are blind can also play your game; people who pass the legal threshold to be classed as blind still usually have some degree of residual vision, which may mean you can see well enough to play a game, but can’t see well enough to read chat text. There are even gamers who are completely blind, (i.e. no sight at all) playing GTA, Titanfall, COD, WOW, Forza. And people who can’t play independently playing with assistance from hardware, or other gamers, using Xbox co-pilot for example.
So while you could theoretically plead unreasonable expense to consider a certain demographic, you would have be very sure that demographic you’re talking about categorically cannot play. And that’s a very hard thing indeed to be certain of.
But we’re a small indie, we can’t afford this
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.
So small indies are effectively exempt?
Kind of, but not entirely. Even if you’re on slim margins you still have to keep a record of which considerations aren’t achievable and why. And there’s a good chance some would be achievable, for example avoiding reliance on capacitive touchscreens or reliance on colour alone to differentiate/communicate are very easy to achieve. Covering those basic ones is a good demonstration that you aren’t shirking.
But our game is mobile / VR / smartwatch / etc
CVAA is not platform