[games_access] GAIM 0.02 updated

Sat Dec 15 15:31:16 EST 2007

To me (and I guess to several of the others here) these sort of things are simple. Ok, I asked you guys if you thought this was making things too difficult and you were honest so I respect your answer (except the Arse-bit which was "not amusing" (winkwink) but I forgive you because you remind me somehow of Terry Pratchett who unfortunately, I recently learned, has Alzheimer's). 
But I do absolutely not agree with merely "chipping away at the things that are simple". We are PAST that point already. Yes, we could stick to lingo such as "add sound cues for visual information" and "make games controllable with 1 button" but it simply doesn't work that way. That sort of thinking does not make games more accessible and it is (clearly) not what the industry needs. Game accessibility is a complex thing and let's deal with it as such. I too prefer to keep things simple and I do not want to make something difficult out of something simple (hence my upcoming interactive animation@ http://www2.hku.nl/~mosh/ga/gameaccfield135.jpg ). But game accessibility is complex. Complex, by the way, is not the same as difficult or not easy. It meant that there are simply a lot of facets or parts to it. And these parts of game accessibility should be taken into consideration when discussing it with and to designers. So I don't think we are in a knot here - at all. We're simply discussing formats of how this complex subject (with all its facets) can best be described (in the easiest and most worthwhile format) to the target group of designers and system engineers and others in order to make games more accessible. For this I think it is very viable to discuss options that are out there and not simply choose one. I believe that 10 years of W3C has proven that the format of guidelines is not practical. Eelke's patterns are a really good format of describing practical applications of game accessibility solutions, but I have simply the hunch that patterns alone are not sufficient. 

Do you really think this is "impenetrable academic science"??! Let's turn it around, then. Barrie, your turn:

How would you describe to The People in the Game Industry who are responsible for Games, how to make their games TRUELY accessible - in a way that is practical and still covers game accessibility from A to Z?

----- Original Message ----- 
From: "Barrie Ellis" <barrie.ellis at oneswitch.org.uk>
To: "IGDA Games Accessibility SIG Mailing List" <games_access at igda.org>
Sent: Saturday, December 15, 2007 5:44 PM
Subject: Re: [games_access] GAIM 0.02 updated

> Richard, you are fast in danger of disappearing up your own arse! ;)
> 
> Come on - let's not turn Game Accessibility into some impenetrable academic
> science. Let's chip away at the things that are simple - then go on from
> there.
> 
> You've lots to offer - but you seem to me to be getting yourself tangled up 
> in unnecessary knots.
> 
> Barrie
> 
> ----- Original Message ----- 
> From: "AudioGames.net" <richard at audiogames.net>
> To: "IGDA Games Accessibility SIG Mailing List" <games_access at igda.org>
> Sent: Saturday, December 15, 2007 1:41 PM
> Subject: Re: [games_access] GAIM 0.02 updated
> 
> 
>> Hi,
>>
>> Well written, Eelke!
>>
>> *quote*
>> 1) some of the requirements assume absolute validity but are actually only 
>> applicable in very specific contexts; take the "provide audio cues to 
>> visual information". A requirement as such does not make any game 
>> accessible to the blind automatically.
>> 2) There are too many (requirements);
>> 3) Another thing that I think is lacking with guidelines is that is does 
>> not specify what problem it actually solves, why it works or how it can be 
>> implemented.
>> *quote end*
>>
>> I fully agree. This is why I have been so stubborn with accepting the 
>> requirements/guidelines defined so far. There simply is no link with the 
>> actual practical implementation. I also propose to drop the term 
>> 'guidelines' - which is too fixed in my opinion ;). Patterns are that link 
>> to the practical, but I do think that patterns are only part of the 
>> solution. At the moment (but this may change in the future) I believe a 
>> healthy mix of heuristics and patterns is key. The patterns are (now), as 
>> you say, of a somewhat lower level than the high level game design and 
>> target software engineers. But I think it is important to target all 
>> disciplines within game development. Throughout the development of a game, 
>> decisions are made and it is important that for every decision that is 
>> made, accessibility is taken into account. So this includes targeting the 
>> high level designers (which would be targeted with "accessible game design 
>> patterns"), but also lower level designers (like the interface designers 
>> ("accessible game interface design patterns") and the audio designers 
>> ("accessible audio design patterns") - which would probably overlap ;) ). 
>> And even up the the marketing department ;) . I think that it is possible 
>> that a game designer creates a concept for a game that is very accessible 
>> because of using accessible game design patterns, and that other designers 
>> do not need patterns because of this. A game idea that revolves around the 
>> speech of the gamer, for instance, makes it very accessible for all sorts 
>> of gamers, because there simply is no physical or gestural input needed. 
>> Of course, there will always be the problem of what is accessible for one 
>> is inaccessible for the other ;)
>> If this is possible with patterns, than I'm all for it. I do not have that 
>> much experience with patterns so far, but from what I know I get the 
>> feeling there are limitations/obstacles with patterns. One is that I 
>> foresee that there can be as many design patterns for game accessibility 
>> as there are usability design heuristics and that number would grow as 
>> time progresses. That may not be practical. I also think that not all 
>> problems can be captured in patterns - or at least that it is very hard. 
>> The higher level you go with defining patterns, the less simple it gets. I 
>> think that a big part of game accessibility revolves around 1) input and 
>> output interface problems and 2) game difficulty problems. But there is 
>> still that one other part which is so hard to grab and that is the issue 
>> of trying to keep the game essence in tact and keeping the game fun for 
>> all while implementing different accessibility features. This requires, I 
>> think, the highest level of heuristics or patterns or... .
>>
>> A concept I was recently introduced with and I think that may apply to 
>> this all is the concept of Strategy. There's this hierarchy of (Design) 
>> Goal, (Design) Objective, (Design) Strategy, (Design) Tactic and (Design) 
>> Task. One has a certain Goal (for instance "make all games accessible 
>> (controllable, perceivable and fun) for all players"), which is broken 
>> down in a certain Objective ("make Bejeweled accessible for color-blind 
>> gamers"). The Strategy is the Plan to achieve this Objective, which is 
>> broken down in conceptual actions called Tactics. So a Strategy is a 
>> collection of Tactics in a given context, the Objective. A Tactic is 
>> implemented as one or more Tasks.
>> While the theory of heuristics and patterns and guidelines is not so 
>> easily transferred to this hierarchy, you might say that a Pattern 
>> captures the Tactics and the Tasks. Heuristics would to, but not on a 
>> practical level? However, Strategy is where one designs which route to 
>> take, which Patterns/Heuristics to implement. This is decision making to 
>> and I think it is important to define strategies too. For example, the 
>> problem for colour blind gamers with information that is communicated with 
>> colour communication, can be solved with either alternative 
>> colour/contrast schemes or alternative parallel information communication, 
>> such as distinctive shapes. These would be 2 patterns. A design strategy 
>> would describe the problem and describe the two patterns (tactics), but 
>> also discuss which pattern is best in which context. I guess you could 
>> capture a strategy into a pattern too (since, how I've understood it, you 
>> simply make up your own pattern language to include strategy information). 
>> I consider strategy to be a path which links objectives to 
>> implementation - and I think it is important to define these too.
>>
>> K... I wrote this very quickly and gotta go now so sorry for any vague 
>> lines in there, but I'm interested to hear what you think of this and if 
>> this may lead to something better or if you think this just makes it more 
>> difficult.
>>
>> Greets,
>>
>> Richard
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> games_access mailing list
>> games_access at igda.org
>> http://seven.pairlist.net/mailman/listinfo/games_access
> 
> 
> 
> _______________________________________________
> 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/20071215/5ca8f0fc/attachment.htm>