Re: [SEC508] Flash Games test

[Peter Korn <Peter.Korn@Sun.COM>]

Hi Andrew,

This is a neat test.  It points up a lot of the challenges someone 
writing a Flash application (or any applications which runs in a plug-in 
in a browser) has in accessibility.

A browser is to some real extent a "platform" or "operating system" of 
its own, in which the plug-in application runs.  So:
1. How do you comply with 1194.21(d)?  The DHTML accessibility work is 
still in development, and while Firefox mostly supports it, IE doesn't.  
So is the only way to supply identity, operation and state information 
of each UI element to use an unratified spec., and require Firefox?  And 
what if the AT doesn't support Firefox to obtain that information.  Is 
that the plug-in application's fault?
2. How do you comply with 1194.21(g) (which we at least at Sun 
interpret to mean supporting the desktop theme for color, contrast, and 
font size)?  If the browser doesn't convey that information to your 
plug-in application, how can your plug-in application respect it?
3. In the case of this hangman application, do we consider this also 
some sort of electronic form such that 1194.21(l) should apply?
Or since this application is delivered via the web, do we say that 
1194.22 is the only thing that applies?  (in which case the Adobe Reader 
stand-alone application has a completely different set of rules from the 
Adobe Reader browser plug-in, though they are otherwise very similar 
applications with very similar functionality - likewise a Flash app 
running in a standalone Flash player)

To me, this example suggests some current Section 508 standards 
deficiencies:
1. There isn't a good recognition of the special situation of web 
applications that run inside a browser.  These have gotten a good deal 
more complex in the last few years, with "the web" being something of 
its own operating system, running inside of another operating system 
(maybe "platform" is the better word here).
2. There is no statement of what an AT must do (or must not do).  The 
application (web app or otherwise) is penalized even if it is using (for 
example) the best current techniques for exposing its accessibility 
information (e.g. DHTML accessibility), if the browser or AT being used 
fails to take advantage of that.


Separately, I would think the alphabet is closer to a radio-button group 
(especially in the second hangman example), and I would want to use 
arrows to go between the letters, with tab simply going to/from the group.


Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

P.S. have you taken a look at the WGBH/NCAM CD-ROM Access project?  See 
http://ncam.wgbh.org/cdrom/prototypes.html  While not focused on web 
apps running in browsers, it does tackle the issue of making games and 
other multi-media content accessible, using Macromedia Director and 
Java/Swing.



> Hi,
> Net Systems Solutions (http://www.n-syst.com) has created a couple of
> versions of a Flash game.  I'm interested in gathering some opinions
> about which version people prefer, and why.  I'll share any results from
> this non-scientific study -- the general idea behind this is that rich
> internet applications are challenging to make accessible, in part
> because we need better information about what screen reader and keyboard
> users prefer.
>
> Example 1.1: http://www.n-syst.com/hangman1.htm
> Example 1.2: http://www.n-syst.com/Hangman2.html
>
> I wrote this up on Adobe's Accessibility Blog - feel free to send
> comments to this list or add comments to the Blog entry.
> http://blogs.adobe.com/accessibility/
> http://blogs.adobe.com/accessibility/2006/08/two_accessible_flash_games_
> whi.html
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Corporate Accessibility Engineering Lead
> Adobe Systems
> akirkpatrick@adobe.com
>  
> _______________________________________________
> SEC508 mailing list
> SEC508@trace.wisc.edu
> http://trace.wisc.edu:8080/mailman/listinfo/sec508
>