I agree. I'm in a somewhat unique position here as not only am I a
gamer, like everyone else, I also have spent some time in the public
sector as a programmer. I can say from firsthand that the way
programmers generally produce a software product is a lot different
than the way I run USA Games. There are design proposals, budgets, etc
all factored into the mix long before the programmer actually sits
down at his/her compt to write it. For example, a professional game
company would probably do the following.
1. Write up a design proposal of the game. It would include the name
of the game, basic storyline, game characters as well as technical
specifications regarding the product.
2. Assess the time and cost factor involved in producing this software product.
3. Appprove the design proposal, approve the funds, and give the green light.
4. Purchase sounds, music, and have a graphics designer create the
graphics for the game.
5. Write an initial draft of the program.
6. Debug/test it.
Based on this list of steps from concept to finished product
accessibility would have to be somewhere right at the top. After the
schedule has been written, funds allocated, and a design proposal
adopted everything is pretty much set. If you come knocking on their
door three months into the development process asking about
accessibility they are going to turn you down on principle as much as
anything else. They've already written the design docs, allowcated all
the money they are going to spend on the project, etc and adding
accessibility would likely throw a big monkey rench into the
development process blowing their release schedules, add money to the
project that wasn't allowcated, etc. So if a developer of company x
does a poll to find out if gamers want character x in the next game
you can pretty much guess they already have it in the design docs and
have budgeted for that eventually. As you said by the time the public
knows anything about an up and coming game title it is wel on its way
to being done.
If I go out to do a contract job my methodology really isn't that much
different from the one listed above. If I am hired by company x to
write some inhouse piece of software I'd write a design proposal of
the intended software product to be created, specify the programming
language that will be used, the purpose of the software, describe the
user interface, and of course assess the time and cost of the project.
Unlike a sighted programmer I need really good accessibility to use
the software I create so accessibility ranks really high in my early
design proposals. A sighted developer can take it or leave it, and if
it saves time not including accessibility that's exactly what they
will do. I don't have that option as a blind developer.
Then again, education, or the lack there of, plays a large part too.
If you take an online course on a programming language or attend
regular classes the instructer is going to breeze through the course
material with very little time to discusss accessibility concerns.
Most of the time if you use the defaults in something like .NET you
will get a fairlya ccessible product. However, I've had ocations where
I changed the size and style of a button because it looked better, but
Jaws and Window-Eyes had difficulty with it. It is possible a
developer might not even know doing something like that might break
accessibility, and have no immediate way of testing it as they don't
have Jaws, Window-Eyes, NVDA, etc sitting right there to test it.
Point being, accessibility is a universal problem because we don't
start with educating them when they start out and acccessibility fixes
usually end up being bolted on afterwards at some point.
On 11/29/10, neoph...@inthecompanyofgrues.com
> Hey all,
> While I can't believe how many issues of Audyssey pile up in an inbox over
> just a few days, I have caught some of the conversation about
> accessibility and mainstream companies.
> You may not know, but for three years I worked for one of the major
> publishers, THQ, and I'm still friends with quite a number of people in
> the industry, mostly PR, but a few game devs such as 5th Cell (who created
> Scribblenauts) and BlueTongue (who are working on de Blob 2).
> Getting accessibility features into a game is not as simple as banging on
> a door and saying 'Hey, what about this?' In fact, usually, by the time
> you've heard about a game being in development, the features list has
> already been 80% established, and that includes the major gameplay
> elements. The addition of a character because of so-called player support
> is often fictional. They would have already assessed whether or not it was
> viable to put the character into the game and potentially done concept and
> model development. Trust me: you can't just plug a character into a
> game--especially a fighting game--as you have to make sure it's 100 per
> cent balanced against every other character. Anyone who's big into Street
> Fighter IV would be aware of that.
> Accessibility is something that has to be considered right at the
> beginning of a game's development in order for it to be fully implemented.
> And, yes, you're right sometimes it comes down to money. Sometimes it's
> about resources. How much time do you work on accessibility features
> before you realise that you've just burned up a huge number of dev hours
> that really needed to be spent on ensuring the game controlled properly.
> Independent development is definitely the best and most direct way to
> ensure there are accessible games. Working with game dev studios to
> produce quality games is another. (And I don't mean to try starting with
> Valve or Sony's internal studio, I mean find a smaller developer who
> doesn't mind doing the occassional experimental game.) Education is
> important, too. Sometimes there are a few small things developers can do
> that dramatically improve accessibility. I discovered that with
> interactive fiction. Just removing the status bar and recoding the command
> prompt made games 50 per cent more enjoyable straight away.
> Lastly, there are other means. One idea I had while I was researching was
> to create a not-for-profit organisation that could take donations. Those
> donations would pay authors and programmers to create games for the blind
> and VI community. There's some strong evidence to suggest that it would
> contribute positively. I even spoke to a few people who ran similar
> Anyway, my point is: you're not alone. No gamer off the street will ever
> make a change by banging on the front door. Trust me when I say that game
> companies have to deal with a lot of scary fanboys and fangirls. They keep
> those doors closed for a reason. But that doesn't mean giving up. Get
> smart. Have a clear idea of what you'd like to see changed, and think
> about the best way you can make that happen. If it's a good idea, with
> considerable appeal, most people will sit up and listen. Just think about
> it from the company and dev's point of view first.
> Hope that helps.
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
All messages are archived and can be searched and read at
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.