[gui-talk] [SEC508] Flash Games test

[Andrew Kirkpatrick]

Peter,
Thanks for the comments.  

>  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?

In the case of Flash, our accessibility information is channeled through
MSAA.  In this example the controls are mostly buttons and images,
although as you point out arguments can be made for reclassifying some
collections of buttons as other controls instead of individual buttons.

>  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?

It is a problem.  This is something that needs more attention. A Flash
developer can implement color/contrast switching funcionality that
operates independantly, which is the current best practice.

>  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?

21d and 21l are substantially the same.  I wouldn't call this a form,
but the definition of "form" has always been murky in 508.

> 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)

I'd call this an application, not everyone would agree.

>  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.

It is a problem, and it fits in with what the role of the functional
performance criteria is in an evaluation.  An application that is
sending information via an accessibility API can pass 21 or 22, but the
troubles come in with 1194.31.  

> 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.

Sure, I can see that as a possibility.  

> 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.


NCAM?  I think I've heard of them... ;) I am familiar with these sample
application.  I find that there is a lot to learn from many different
sample applications - what was compelling to me about the hangman game
was that we have two versions that operate differently which I thought
would be a good way to stimulate conversation.

Thanks,
AWK