[games_access] RetroRemakes 2006 Q&As: Accessibility logos andicons?

Sun Jun 4 08:16:07 EDT 2006

Hi,

Most of you know how I feel about signs'n'symbols, so I'm not going to repeat myself on that. However, in this thread I sense that there our two ideas out there, which I think would be best to take apart for the sake of clearity:

- logo/sign/symbol to indicate that a game features a certain accessibility feature that makes a game *more* accessible for a gamer with a certain type of disability;

- logo/sign/symbol to indicate that a game is completely accessible for a gamer with a certain type of disability.

Barrie's post entitled "Existing symbols for access" sums up pretty much the most conventional signs/symbols for disabilities out there (or see: http://www.vsartsnm.org/disability_access_symbols.htm ). However, as you may notice, these too are about "accessibility features" (such as braille and closed captioning) and "accessible for x" (like the wheelchair symbol - not very clear without the right context, usually means wheelchair access in the real world).

If you plan to incorporate signs/symbols in the product (box, splashscreen, etc) then it's best to FIRST decide what you want these signs/symbols to communicate: that this is an accessible product for all (all disabilities), that this is an accessible product for some (the blind), that this product features accessibility features that make it completely accessible for all (everyone!), that this product features accessibility features that make it completely accessible for some (deaf), that this product features accessibility features that make it more (but not completely) accessible for some (large print - for people with visual disabilities), etc. This may sound very over the top and I guess some of you might be thinking "I just want to show that this game has closed captioning".

Therefore I suggest to "Stick with signs/symbols for accessibility features only". If you try do develop a sign that indicates that a game is accessible for the blind, it means that there will be about 10 features in the game that try and make it accessible. However, and here is my main point: signs indicate something, and it should be possible to test this "something" *on its presence*. So if a sign indicates that a game is "accessible for the blind", than it should be possible to validate this "accessibility for the blind". For this you need testing standards, maybe games should be tested prior to getting a symbol/sign etc. etc and enter WCAG*! 

You avoid this problem by saying (with a sign): "this game features audio descriptions of what can be seen on screen". Whether or not this makes a game accessible for the blind (which I doubt ;) ), you can't go wrong since you simply that a certain feature is present in the game. You simply have to run the game and sense the feature in action (although there are problems with this as well see below**). To what level the game becomes more accessible is not an issue then.

Get what I mean? This is actually the same as I suggested a couple of years ago with referring to http://www.kijkwijzer.nl/pagina.php?id=2 (press the english flag on the left for english). This is a parental recommendation system for dutch media. Instead of saying "this movie is for 18 and up", it simply states a recommended age and then the reason why (sex, drugs, etc.). This way people can decided for themselves what they think is harmful. Turn this around and appy it to accessibility, and you get a system which indicates that "this game features subtitles and auditory descriptions of visual events", and you can decided for yourself if you think it is accessible enough for you to play. This way people still can't sue game developers if the game is not completely accessible for them, but you make it more easy for game developers to make their game "MORE accessible" (also see my previous post on WCAG 2.0 - I think 'more accessible games' is better than 'accessible games')... 

So now only one issue remains... if you try and make an universally accessible game, which uses 30+ features, you might end up putting these all on the box. Although logo's might be a selling point, having 30 logo's on your box might ruin the visual appeal of your product in a store. Therefore you could add a parallel system: logo's that indicate the number of accessibility features, maybe combined with a certain disability. For example, a game that features subtitles, closed captions and sign language is aiming its accessiblity primarily at gamers with a hearing impairment. Therefore you could put on a logo indicating : "3 accessibility features for gamers with hearing impairments".

However, this is a bit tougher when someone implements 8 very different accessibility features.

However, I don't think it will come to that very soon (having 30+ features on a box). So let's go with the features first and let's see how that goes. For the Game Accessibility project I was already working on some signs/symbols for the Top 10 lists on the G-A.com website and also for Game Accessibility Features (like the sign for remappable controls: http://www.accessibility.nl/games/pics/filler_controllers.jpg - needs redesign though ;) ) . I'm happy to graphically work out the ideas and I might get some funding for it too. Partners, anyone? 

K, that were my ideas...

Greets,

Richard 

* or any other accessibility standard of your choice!
** when a developer says "Hey, I got closed captionioning in my game" and he wants a logo on his box, how does this work? Let's say IGDA and Accessibility (and other partners) team up a provide the logo's for free through our websites. It's simply a vectorgraphic and people can download it, tadaa. Do we need to check whether or not the developer REALLY has a feature in his game? For example, only the first level could feature closed captions, but the other 349 levels don't. Technically the game features closed captions, but only in a very small part. One could claim that his Main Menu, of which every item is also spoken by a male voice, is also "captioned". So what would we do then? If we do not check, that means that everyone can abuse the symbols for all we know. So it is better to check and have regulations***, in my opinion. But do we do that before the game is launched without a logo or do we validate the feature after the game has already got its logo? There are benifits to checking afterwards - it becomes a bit more self-regulating. For instance, a developer says: "I want to put a cc logo on my box since my game features cc". Without checking we give him a logo. The developer needs to sign a contract/disclaimer that he complies with the regulations*** for this logo. Having a logo means that we have a special page for this game on our website which gamers can use to complaint. Whenever we receive a complaint, only then we check the game. If the complaint is valid, then we point this out to the developer who either has to create a patch that fixes the problem or remove the logo from their product. Or something like it... By checking before release we would simply give logo's that comply with our regulations***
***Regulations: in order to check, you still need to have a standard for what you are checking. How much captioning is enough? Would Sin Episode 1 still receive a logo while not everything is closed captioned? How do we test the quality of the auditory descriptions - although the game features descriptions of visuals, to what extend are these useful for gameplay? Etc. etc.

  ----- Original Message ----- 
  From: Barrie Ellis 
  To: IGDA GA mailing list 
  Sent: Sunday, June 04, 2006 11:17 AM
  Subject: [games_access] RetroRemakes 2006 Q&As: Accessibility logos andicons?

  Wondering what people think to this thread: http://www.retroremakes.com/forum2/showthread.php?t=6623

  I've posted my suggestions, although a little vague in parts...

  Barrie
  www.OneSwitch.org.uk
  www.igda.org/accessibility

------------------------------------------------------------------------------

  _______________________________________________
  games_access mailing list
  games_access at igda.org
  http://seven.pairlist.net/mailman/listinfo/games_access
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist7.pair.net/pipermail/games_access/attachments/20060604/2b45efda/attachment.htm>