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 since 1990. It contains two parts:

1. The communications article, which ensures that voice over IP, communication between VoIP and phone networks, electronic messaging, and video conferencing are all accessible.
2. 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 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:

• Blind
• Low vision
• No colour perception
• Deaf
• Limited manual dexterity
• Limited reach and strength
• Prosthesis
• 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

For both:

• 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.

Process

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.

Reporting

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 1^st 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.

Q&A

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 specific, if you’re providing text/video/voice messaging the requirements apply

But CVAA compliance would break my game mechanic

This would be very rare, but may happen. If so you’re likely covered by the achievability analysis; one of the criteria for the work not being under the banner of ‘reasonable’ is the impact that doing the work would have on your product of company. That includes if it was to “reduce substantially the functionality of the product, to render some features inoperable, to impede substantially or deter use of the product by individuals without the specific disability the feature is designed to address“. But you need to be very sure, if a consumer raises an issue the FCC will check your analysis and can reject it.

Are emotes covered? How about predefined chat wheels?

The only things covered are text chat, voice chat and video chat. Those names are just my shorthand though, “text chat” is actually “electronic messaging service”. Which CVAA (and congress in general) defines as this:

“The term electronic messaging service means a service that provides real-time or near real-time non-voice messages in text form between individuals over communications networks.”

So if emotes are just icons or animations, they are not covered. For emotes to be covered they would also need to be represented as text.

Pre-defined chat wheels are covered by CVAA – text messages between players are covered regardless of whether they’re typed or selected from a menu.

Would CVAA apply to single player games where there is communication between a player and a bot / chat bot? Or for example voice command based single player?

No, to be covered by CVAA voice chat must be VoIP, and text must be between real humans over a communications network.

How about a game like Dark Souls, where notes are left in the world for other players to read?

CVAA applies only to real/near real time messaging in text format between individuals over a communication network, voice over IP, and interoperable video conferencing. Leaving in-world messages would not be covered because they are not addressed to a specific individual / group of individuals. To use some examples from other industries; email is covered, forums are not. Facebook messenger is covered, Facebook status updates are not.

How would a game like journey might be affected? A game with no direct communication involved, but still a means of developing communication between players online

Again if no text / voice / video communication is involved, CVAA does not apply.

If I drop text chat and just go with voice chat instead, does that mean I no longer have to think about text to speech?

No. People who rely on text to speech still must be able to navigate to and operate the voice chat functionality and people who can’t hear or speak still need to be able to send text messages to the voice chat service. Realistically text to speech is going to be required for both things.

If I provide text chat does that mean I’ve made my voice chat accessible?

No. Each individual communication service you provide must meet as many of the requirements as reasonably possible. Players must be able to choose which of the available communication services they want to use; having a separate text chat service available isn’t much use if you’re deaf and all other players are using voice.

I’m not based in the USA, is CVAA relevant to me?

As with any domestic legislation, such as GDPR or Belgium’s lootbox legislation, it isn’t where you’re based that matters, it’s where you’re selling your product. If your game is for sale in the US market it falls under CVAA. As far as enforcement goes, I don’t know for definite if this applies to CVAA but for other areas of regulation the FCC have exercised powers to block products and services from being on sale.

What if I make my chat region specific, remove or block it for the USA but keep it for other countries?

CVAA then would then not apply. Though obviously this isn’t a solution that would make your players happy at all.

Will I now be subject to ADA-style rent-seeking lawsuits?

No. Lawsuits cannot be brought for CVAA issues, enforcement happens exclusively through the FCC’s internal processes.

Won’t the industry just set their lawyers on getting this overturned?

The period of lawyers and lobbyists (on the side of people with disabilities too) being involved has already come and gone. Hence the series of waivers.

Why doesn’t CVAA require specific features?

The legislation covers all industries, so a specific list wouldn’t be very practical. They have also said that they don’t want to micromanage people’s implementation decisions.

It’s a bit of a double-edged sword, on one hand a clear fixed target would be nice; on the other hand there’s wiggle room to choose the implementation that works best for your game.

CVAA mentions hearing aid compatibility. How do I go about implementing that in my game?

You don’t need to, criteria B2 VII, B2 VIII, and B2 VIX are only relevant to hardware providers.

Cursor based navigation for console games has been slowly spreading since the first Destiny game. Is this compliant?

If required for any chat functionality or any UI used to navigate to or operate chat functionality, no. Compared to regular digital UI navigation it increases barriers to precision, strength and executive function, while being close to impossible for people with no sight to use. So there could be consumer complaints for failing to meet a number of CVAA performance objectives. The solution would likely be to offer traditional digital menu navigation in addition to analogue cursor, in much the same way as PC games allowing menus to be navigated by either mouse or keyboard/controller.

On the topic of Destiny-style UI, holding down a button for a few seconds to select increases barriers to strength, again failing a CVAA criteria.

Can I address colourblindness by using post processing filters?

No, filters only address the most well known about types. CVAA requires accessibility to people who have no colour vision at all; their needs can’t be addressed by filters.

Even the best cloud speech to text services are far from perfect, and using them will result in some latency for deaf gamers. Am I subject to complaints about that?

No. You’re only required to implement what is achievable within reasonable effort and expense.

Are there any tools available that can help?

• The Harding Flash Pattern Analyser can test for epilepsy reasonable risk thresholds
• Color Oracle can simulate common forms of colourblindness
• Most operating systems have system level text to speech functionality
• The Xbox SDK includes a text to speech API and a free realtime text <-> speech transcription API
• Various cloud services are available for speech to text, sometimes with an initial low volume free usage threshold
• Michelle Martin has released an accessibility plugin for Unity that covers both text to speech and UI interaction for blind gamers on mobile devices

More could and should be available. For example if you’re developing a native windows/iOS/Android app, making your UI blind accessible just means adding a bit of metadata; that metadata is then exposed to the system level screenreader software which handles interaction and text to speech. All just works, by default. To the extent that natively developed games are sometimes completely blind accessible by accident.

Supporting voiced UI in engines like Unity or Unreal should be just as easy, but it is not. Instead devs have to implement their own bespoke in-game solution or worry about how to get their UI to render out according to each different platform’s approach to it. That’s exactly the kind of thing that engines are there for, they should be handling it out of the box. Whether they will in future depends on whether devs tell them it’s a priority.

Can I just use a third party for communication and no longer have to worry about CVAA?

You cannot delegate your liability. If you integrate a third-party comms service in any way the liability for its accessibility falls on you, not the third party. If a consumer makes a complaint about an accessibility issue with the service, it’s you who the consumer has the relationship with for that product and you who made the decision to rely on using that service.

But if consumers are freely choosing for themselves to use an entirely separate third party service, e.g. your game has no voice chat functionality but players choose to team up via Discord, the liability then falls on Discord.

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.

I’m developing for a platform that currently has no accessible platform level solution available. Am I exempt?

No. The obligation falls on the game, regardless of what is available at platform level. Even if platform solution is coming but hasn’t been provided by the compliance date, the only way around it is to have an achievability analysis that the FCC would be persuaded by in case of a complaint. I.e. being able to demonstrate that it is too expensive (tough argument for larger companies) or too technically difficult (tough argument as Microsoft have demonstrated real-time text <-> speech) to implement an interim game level solution.

Products that have a substantial update after the compliance data become liable. What does “substantial update” mean?

Substantial means any update that provides a natural opportunity to work on CVAA requirements, which “may include, for example, the redesign of a product model or service, new versions of software, upgrades to existing features or functionalities, significant rebundling or unbundling of product and service packages, or any other significant modification that may require redesign.”

If you’re pushing out a substantial update you need to redo your achievability analysis – “new versions of software or services or new models of equipment must be made accessible unless not achievable and that this burden is not discharged merely by having shown that accessibility is not achievable for a previous version or model.”

The FCC aren’t game developers, why do they get to decide what’s achievable?

They are not game developers but they are experts in communications accessibility. There must be some kind of a check in place, or comms providers could just make whatever claims they wanted. The legislation would then have no teeth.

Can I just apply for a waiver instead of bothering with the whole achievability thing?

Maybe. Waivers are hard to obtain, require a significant amount of evidence gathering and are for the specific circumstance of a developer claiming that communication is not important to their game, e.g. could be removed without any impact on the experience.

How do you think this is all going to pan out?

Currently a range of approaches are being employed.

Some developers are going all out, meeting all CVAA requirements and taking that as an opportunity to go above and beyond and improve accessibility across the game as a whole. Even taking it as a cue to significantly up their accessibility game across all their products.

Some developers are treating purely as compliance, doing what they need to do to avoid complaints.

Some developers are moving more towards third party solutions.

And some developers are planning to remove chat functionality, either on a geo basis or completely.

I suspect what we’ll see is an initial reduction in in-game communication provision throughout 2019. But it won’t take long before good solutions hit the marketplace. These early examples should have a few different effects:

• Serve as an illustration of how compliance works; i.e. the first wave taking the R&D hit for the rest of the industry
• Kick off wider scale community and industry discussions of the solutions, resulting in better solutions
• Demonstrate clear opportunities for avoidance of needless duplication of work between games, resulting in the production of better third party / engine level solutions.

So as with any legislation although it’s likely to be messy and difficult at first, it should get better in future. Particularly if devs can band together to put pressure on middleware developers, e.g. getting Unity to handle interaction with the various platforms’ approaches to text to speech.

I’ll close on a quick story about the progression of legislation.

CVAA is unlikely to be the last time legislators impact the games industry in this way. But something interesting happened in the UK when the Equalities Act was enacted in 2010. The TV industry said to the legislators “we don’t need to be covered by accessibility legislation. We already have it covered, we effectively self-regulate, we don’t need more regulation on top of that”. The legislators said “fair enough, that’s demonstrably true”. So, the UK TV industry was granted a blanket exemption from the regulation.

That’s where I’d personally love to see games get to. At the inevitable point in the future when some accessibility legislator in some country turns their eye towards gameplay, the industry to be able to say “we already have it covered”. Demonstration of intent goes a long way, the best defence is a good offence, and in terms of accessibility a good offense simply means games being a better experience for more people.

Further viewing & reading:

About CVAA
– IGDA Game Accessibility SIG

The CVAA: What It Means For Gaming Access
– Karen Peltz Strauss, FCC

Communications Accessibility in Games: What Game Developers Need to Know
– Kelly Drye & Warren LLP

The CVAA And Gaming: Your Legal Responsibilities
– Bill Curtis-Davidson, Level Access & Mark Barlet, AbleGamers

CVAA For Fostering Innovation And Change
– Sarah Horton, The Paciello Group

Panicking about CVAA?
– Ben Bayliss, Dualshockers & Ian Hamilton

CVAA consumer guide
– FCC

Twenty-First Century Communications and Video Accessibility Act of 2010
– FCC

CVAA Final Report And Order
– FCC