About Section 508

NOTE: This article is out of date following the 2018 section 508 refresh (which brought section 508 in line with WCAG 2.0) and will be replaced. if you’re interested in helping out with this please get in touch!

Author: Ben Sawyer

Ben Sawyer is one of the cofounders of DigitalMill and is active in the Serious Games arena. He is a speaker at the Serious Games Summit at GDC 2004 and will be speaking on this subject at other conferences.

Ben has written an interesting article on the subject of game accessibility and has kindly allowed us to include as part of this white paper.

You can view further information about Ben and his projects at http://www.dmill.com/about/staff/sawyer.html

About this version

The following paper is a draft summary of issues related to Section 508 compliance capabilities of games and game technology. While it makes an argument that games may not be able to comply perfectly with the guidelines as easily as other software may be able to this in no way represents a desire by the industry, or the author(s) of this document to absolve themselves from the goal of making their technologies or products as accessible as possible.

Over the next few months The Serious Games Initiative will be working on a number of efforts to resolve all the issues contained in this document and bring about the best, most informed opinions on the subject of 508 compliance by games for use by organizations and agencies which necessitate 508 compliance. Until that work is complete all opinions and facts in this document remain in draft form.

Accessibility and Games

Abstract

The purpose of this paper is to bring further clarification to how Federal 508 standards which govern the accessibility of software affect the use of games in organizations which must or seek to be compliant with 508 standards. The author argues that the standards were never written with games in mind, and that as such games as a category need some level of exemption. The author provides reasons for this, but also provides guidance where 508 compliance can be at least partially achieved.

It is hoped that this first take will provide the clarity needed for some projects to proceed within reason relative to this sensitive and important issue.

Introduction

When it comes to making videogames rarely does the issue of accessibility come up. Unlike most software, games are not subject to much use in places where accessibility is a requirement. This doesn’t mean game developers aren’t somewhat cognizant of the issue, there are some efforts within the industry to improve accessibility. However, because so much else is required of their products, including tight budgets and schedules, the lack of a requirement for accessibility makes it an easy item to ignore.

This entire problem is further compounded by a couple of critical issues. First many core game technologies themselves are not infused with accessibility technology, and second many games are designed for manual dexterity which of course can render them the antithesis of accessible for people who’s disabilities makes them less dexterous then the average 15 year old, or even 30 year old.

A critical trait of many games is that their interfaces use “non-standard” elements. Most application programs draw all of their interface elements using standard controls supplied by their native operating systems. Games do not do this most of the time. The result is that built-in functions such as screen readers, font enhancement technologies, and more will not always work with many computer games.

Furthermore, games also tend to miss the mark when it comes to accessibility issues related less to handicaps and more to general aging elements. This includes the size of text and interface elements, and the general speed at which game decisions are required.

The saving grace here though is not every game is a dexterous adventure, and many games are mental challenges not physical ones. The gray area here are so-called “Real-Time Strategy” titles which combine mental acuity with a bit of physical acuity. Since the decisions in the game must be executed in a timed manner it can present a real problem to the player who isn’t able to highlight five units, and give three different sets of orders inside a 10 second time-frame. As games have moved more from a turn-based environment to a real-time environment even strategy titles have moved away from basic gameplay elements that are more accessible.

Where does this put things?

There are two major issues this situation puts games in relative to their use in policy, governmental, educational use. First, there is the distinct issue of making games and gameplay more accessible, if not directly compliant with accepted standards and regulations. Second, it is also a matter of providing information that can provide acceptable means for waivers being granted to games because there are unique issues related to accessibility issues. I will attempt to tackle both issues here.

Waivers

The first issue to deal with here is why should games be granted waivers for failing to comply with federal, state, local, or even “de facto” accessibility issues?

The most overriding reason is because in some cases the type of game being constructed, and the way it must be constructed, create an impossible situation to provide fully compliant accessibility. Consider for a moment that the majority of Web and software accessibility standards are written for software that aren’t games.
The majority of Web sites are a combination of text and static graphics. A combination of smart captions, and screen reading software coupled with sites that are properly designed solves this problem without much fuss. Traditional application software is also fairly compliant because built in accessibility feature, lack of animation, action, etc. makes it fairly easy to use with screen readers, etc. Even then some application software fails because developers make mistakes in how they design the interface for it.

Games on the other hand are fast moving, graphically rich products which at times can require precise responses much like driving a car or operating a piece of machinery. The general animated imagery of games may also not allow typical means of interacting with software such as screen readers. A screen reader recognizes text and standard interface elements such as buttons rendered through generic operating system API calls. How can a screen reader discern that in the left hand corner of a game sits a tree, vs. a wall, or a bird in the sky? If text is rendered as a graphical image (as opposed to a text object) which most games do a screen reader is going to be ineffective.

In terms of interface elements games usually depend on precisely tuned interfaces which won’t scale so easily if, for example, the point size on interface text is automatically increased by 50%.

While one can make the argument some of these issues can be overcome with things like captioning systems, and special design considerations it is not a realistic case to expect every type of game can fully comply the way you could expect 99% of all application software and Web sites to comply. Even the closest visual media to games, video benefits from the fact it’s a passive medium. It’s impossible to consider every game could utilize captioning and scene description to enable visually impaired people to play because the player must respond to various visual elements perhaps dozens of times in a 60 second span. The circumstances of a game will change on the fly and thus audible descriptions must change on the fly to and the technology is just not capable of such. Suffice to say this is why visually impaired and physically disabled people aren’t able to operate all forms of machinery. Games have to be seen in the same light.

The result is if were going to use games and game technologies in projects within and/or funded by government we must use common sense and provide properly positioned exemptions from full compliance to Section 508 standards.

At the same time this shouldn’t include carte-blanche exemption from them. In fact, many games offer some ideas for accessibility that other software doesn’t. For example in his article “Game Accessibility” Thomas Westin points out how games tend to have multiple levels of play to tailor them to a wider swath of player capabilities:

“Now you may consider implementing a setting of difficulty levels in your game, if you have not already. This is actually an accessibility feature that the game industry has developed, which is very seldom replicated in other kinds of software! I would love an advanced 3D modelling program to be cleaned from all the super-user features leaving only the basic functions for modelling lamers like me, so I can gradually learn using the software.”

This means we must start the overall process of game accessibility relative to Section 508 by defining precisely what games can do relative to accessibility both in general and in response to specific 508 standards. From this we can define a series of 508 standards that can be realistically met, and we can define some potential workarounds for common accessibility situations.

Current State of Accessibility

The current state of accessibility in games involves three major development areas:

An accessibility SIG (special interest group) developed by the IGDA (International Game Developers Association) is working to rally industry support for accessibility in games and various accessibility solutions for games. This group can be found at
<igda-gasig.org>
There are a variety of hardware devices including specialized equipment to move on-game objects through head movement, breathing apparatus, and brain waves. Coupled with increases in speech recognition products, these devices offer the ability to adapt the input portion of many games so those with physical impairments or handicaps can play games.
Increased awareness by the industry of accessibility issues. As games are being proposed for wider use as “application tools” in various education, governmental, and public interest settings there is a greater realization that some (if not all) accessibility issues need to be better addressed.

The state of game accessibility requires three issues to be better addressed. In terms of entertainment oriented releases the general development of games explicitly aimed at those with various disabilities and impairments is improving especially among the independent community where a number of games including some award winners have been created.

However, beyond these efforts the industry also needs some action on the operating system level to extend common operating-system level accessibility functions to game libraries, and for console system engineers to also consider accessibility issues as well. Finally, game developers must look at ways they can otherwise configure their games to offer as much compliance as realistically possible with their current offerings.

Current Software Accessibility Standards

The current accessibility standards for software are outlined in Section 508 of the Rehabilitation Act Amendments of 1998. This rule states that federal agencies are required to ensure the accessibility of their electronic and information technology including web-based intranets and internet sites. This law is further extended to stats because Federal law also insist that any states receiving federal aid must comply with Section 508 standards. This includes many state and federal universities which receive federal aid.

There are about a dozen specific regulations related to software accessibility. I have listed each one here but also included a specific analysis of the reality of games complying with these standards:

(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.

This is a problem because many games do not return any text in response to a keyboard. Now in some cases this could be adapted to do so but in many cases say of navigating a person through a warehouse infected with a chemical substance vs. a game about a state budget this would be nearly impossible.

(b) Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer.

By the very nature of DirectX libraries this is nearly impossible. In order to get very fast graphics, input and other common game aspects a game almost always uses the DirectX libraries from Microsoft which can be seen as disrupting activated accessibility features. While it’s true that properly written these games do not disable the features in respect to their use with other active apps, within the game screen readers, text enlarges, etc. will not work. The game application must be exited in order to get back to these functions.
Part of the solution here may be to not use DirectX technologies but this makes it very hard to render many types of important game visuals.

(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.

This may be possible with some special programming relevant to each game. However, game developers not using standard OS controls won’t benefit from built in functionality that most operating systems provide here.

(d) Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.

(e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application’s performance.

This is pretty much a design issue that many games follow but using some text based bubble help may be possible with some special programming relevant to each game. However, game developers not using standard OS controls won’t benefit from built in functionality that most operating systems provide here.

(f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes.

This standard is a huge problem for games as the standard ways of displaying text in games is not through generic operating system functions.

(g) Applications shall not override user selected contrast and color selections and other individual display attributes.

Again from a standards issue games do override these issues although in fairness to games many provide gamma correction options for improvement in contrast. However, changing the colors of a game is never an option.

(h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.

Again, this is a standard that just goes against the normal operating procedure of most games. While there are a number of game types that might be able to comply with this because of their inherent designs there are equally if not more so many that would not.

(i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

This is a problem for many games which do rely on color as a critical element in conveying information as part of their interfaces. A small amount of re-engineering could be created for most games to comply so I wouldn’t characterize this as heavily anti-game as some standards.

(j) When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided.

This is sort of a moot issue relevant to how most games handle color selections. Games which do offer anything close to this functionality (a small amount) should have no problem complying with the standard.

(k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.

It is assumed this refers mostly to blinking interface elements and text such as the infamous <blink></blink> tag in HTML. However, games use flashes and blinking elements and the frequency range may be a problem here especially with the high refresh rates many games achieve.

(l) When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

This is a programmatic issue that should be able to be complied with but again, as with many games that don’t use standard OS controls to render normal interface elements this can not be achieved by allowing default OS controls to do the work for them.

Summary of Standards

As written the 508 standards are clearly aimed at important access to everyday applications (e.g. Microsoft Office) and information (i.e. Web sites, intranets) and were never written with regard to the use of games in the workforce or in the general public as an information, and/or training tool.

Where to draw the line though? In examining the standards above and understanding keenly the technologies and design structures used by games I offer the following basic guidelines:

When developing a game idea that doesn’t need high-end visuals which require using technologies like OpenGL, Direct3D, GameSprockets, or DirectX then it should seek to use as many common OS interface standards as possible because that alone will offer a strong degree of compliance with 508 standards.]
Games which render text in game must provide an acceptable means for audio to be properly triggered and controlled by the user. Regulators must accept that this method may be incompatible with commonly used screen reading software.
Regulators must realize that games using sophisticated graphics libraries can not comply with some regulations in 508 such as A) above especially if the underlying technology developers (e.g. Microsoft) do not extend accessibility means into these libraries.
All games should provide or not interfere with basic contrast controls. Regulators must exempt games from having to comply with color issues related to the ability to change them. At the same time developers should seek to create modes of their game which can be played by those with visual impairments related to color perception.
Games should be exempted from F) above. Although it is probably some games can comply with this many games simply can not offer this. At the same time it is possible for games to offer an alternative substitute for text displayed in game to be accessible to visually impaired users provided the gameplay itself isn’t prohibitive.
Regulators must realize when certain gameplay elements make Section 508 unenforceable. Developers however should pursue designs that solve problems which can be the most compliant to 508 issues.
Regulators must consider that hardware options may allow for compliance where software might fail. Input systems may be able to help make a game that is otherwise not accessible to a user without use of the hands actually usable.
Regulators should consider that in some cases games might offer compliance to some extent through team play. For example, a game which doesn’t allow for perfect participation by a single user who is visually or physically impaired may work with a partner. This player might provide strategic ideas to a player who is able to physically implement the commands. In many cases such games might actually be more like how such work happens in the real world. For example, a physically impaired manager might not be able to hike 50 miles and dig a trench in a real forest fire but certainly can command others from a secure headquarters. We would thus STRONGLY argue that because many games (even so-called single player games) are played in team like manner that this form of play be consider a “work around” to some of the hardest compliance issues.
Developers should submit a 508 compliance treatment prior to the creation of a game which may explicitly fall under 508 regulations. This document should explicitly outline four areas of compliance and non-compliance:

Standards which can be 100% complied with.
Standards which can be applied with if specific outlined changes and functions are added to the game design
Standards which can’t be 100% complied with and why this is
Standards which can be complied with 100% or partially there of through alternative means such as hardware or team play.

At the heart of this issue is the dilemma that games can offer a unique way to solve a problem such as how to train people for disaster relief. Yet the very strengths a game may offer such as incredibly strong visuals, interactivity, ability to simulate the stress of real-time decision making, and non-traditional interfaces can sometimes fly-in-the-face of perfect compliance with 508 standards.

This requires some tough decisions on the part of the client and the development team and it is highly recommended that one be wary that strict compliance to 508 standards may sap a game design of its most useful strengths which may be what drew one to the idea of using a game approach in the first place.

Conclusions

The issue of using games in situations where they must comply with 508 standards is completely new. The standards were never written with games in mind, and common technologies used for games don’t offer much independent compliance making inheritance of such almost nil.

While it is probable that the introduction of more games into such situations will improve things considerably it is foolish to think compliance will be perfect, fast, or easy.

The result is games must be somewhat treated on a case-by-base basis and some will have to be exempted from perfect compliance with the 508 standards as written.

This document is meant as a first step in improving the understanding of how games can and can’t be made compliant to 508 rules. Over time it may be possible to further refine the thinking here to provide more explicit interpretation of the 508 rules, and provide further guidance on how most, if not all games can be made as compliant as possible. However, it seems more logical to define a subset of 508 as well as a superset of more flexible rules that are specific to games and provide a better black-and-white framework so that approval of a game isn’t subject to uncertain or unrealistic interpretation.

Follow up

I invite anyone concerned about accessibility of game software both in general and as a potential impediment to wider use of games by 508 compliant institutions to contact me with further suggestions on this topic. I also encourage people to participate on accessibility issues with the IGDA’s accessibility SIG which is working to provide solutions to current technological hurdles relevant to game accessibility.