E-mail List Archives
Thread: Testing a flash movie
Number of posts in this thread: 12 (In chronological order)
From: ben morrison
Date: Mon, Nov 13 2006 5:00AM
Subject: Testing a flash movie
No previous message | Next message →
Does anyone know of any guidelines or procedures for testing to see
wether a flash movie is accessible?
ben
--
Ben Morrison
From: Gian Sampson-Wild
Date: Mon, Nov 13 2006 5:00PM
Subject: Re: Testing a flash movie
← Previous message | Next message →
Hi Ben
1. Turn off Flash and see if you can access the same information /
interaction.
2. See if you can interact / understand the Flash movie with a blindfold on.
3. See if you can interact / understand the Flash movie with the sound off.
Cheers,
Gian
ben morrison wrote:
> Does anyone know of any guidelines or procedures for testing to see
> wether a flash movie is accessible?
>
> ben
From: Bob Regan
Date: Mon, Nov 13 2006 5:30PM
Subject: Re: Testing a flash movie
← Previous message | Next message →
Asking whether a Flash movie is accessible is more akin to asking if a
desktop software application is accessible. It depends on how complex
the application is and what it is doing. Take a relatively simple
application used to display video that contains a simple play and pause
button. Here I will ask:
* Are captions for the audio displayed?
* Does the audio play on load and thus interfere with the screen reader?
* Is the button labeled for a screen reader?
* Is the change in the button's function (play v. pause) reflected as
the user interacts with the app?
You can find a whitepaper on creating accessible Flash at:
http://www.adobe.com/resources/accessibility/best_practices/best_practic
es_acc_flash.pdf
This should give you a head start. Obviously, as the application gets
more complex, so does the evaluation of its accessibility.
Measuring accessibility of the Flash app is more than turning off the
Flash object to be sure, especially if you are assuming that the end
user will actually interact with the Flash object itself.
Feel free to send additional questions.
Cheers,
Bob
---------------------------------------------------------------------
bob regan | adobe | 415.832.5305
From: Vivek Gaikwad
Date: Mon, Nov 13 2006 10:20PM
Subject: Re: Testing a flash movie
← Previous message | Next message →
Hi,
There are so many things we can consider to make a flash application
accessible. I think in flash it's all about finding alternatives for things.
It really depends on us, up to what level we are looking for accessibility.
The following things can be checked for the accessibility of flash movie:
* See if the focus is moving to the desired control on click of certain
object or control.
* Check the reading order of the content.
* When not needed, are the controls made inaccessible for screen reader?
* Are the colors used for the application are accessible?
* When certain event occurs is the feedback provided for alternate
disabilities?
Check out our accessible hangman game developed in flash. You will get some
ideas to start with.
http://www.n-syst.com/Hangman2.html
Thanks & Regards,
Vivek Gaikwad - Accessibility Developer
Net Systems Informatics (I) Pvt. Ltd.
Tel: 022-26860485/6 Extension: 24
From: ben morrison
Date: Tue, Nov 14 2006 2:50AM
Subject: Re: Testing a flash movie
← Previous message | Next message →
On 11/14/06, Bob Regan < = EMAIL ADDRESS REMOVED = > wrote:
> Asking whether a Flash movie is accessible is more akin to asking if a
> desktop software application is accessible. It depends on how complex
> the application is and what it is doing. Take a relatively simple
> application used to display video that contains a simple play and pause
> button. Here I will ask:
>
> * Are captions for the audio displayed?
> * Does the audio play on load and thus interfere with the screen reader?
>
> * Is the button labeled for a screen reader?
> * Is the change in the button's function (play v. pause) reflected as
> the user interacts with the app?
>
> You can find a whitepaper on creating accessible Flash at:
>
> http://www.adobe.com/resources/accessibility/best_practices/best_practic
> es_acc_flash.pdf
>
> This should give you a head start. Obviously, as the application gets
> more complex, so does the evaluation of its accessibility.
>
> Measuring accessibility of the Flash app is more than turning off the
> Flash object to be sure, especially if you are assuming that the end
> user will actually interact with the Flash object itself.
>
> Feel free to send additional questions
I am not developing the flash application, it already exists, I was
asked to see how accessible it is. I couldn't find much information
available on the net for testing accessiblity of flash. I tried
keyboard navigation, which didnt work very well and I ended up
downloading a Windows Eyes Demo - the application I was testing had no
information at all for the screen reader.
ben
--
Ben Morrison
From: Andrew Kirkpatrick
Date: Tue, Nov 14 2006 8:50AM
Subject: Re: Testing a flash movie
← Previous message | Next message →
> I am not developing the flash application, it already exists,
> I was asked to see how accessible it is. I couldn't find much
> information available on the net for testing accessiblity of
> flash. I tried keyboard navigation, which didnt work very
> well and I ended up downloading a Windows Eyes Demo - the
> application I was testing had no information at all for the
> screen reader.
I wrote a post on testing keyboard access in Flash and Flex that may
help:
http://blogs.adobe.com/accessibility/2006/06/testing_keyboard_access_in_
fla_1.html
I need to write one that includes SR support, but here's a quick
protocol to try out for SR testing - feedback welcomed!
1) Verify that the SWF is not using WMODE=transparent or WMODE=opaque.
No WMODE setting, or WMODE=default is good. If the wrong WMODE setting
is used, the content is inaccessible to SR users.
2) Using a newer version of a screen reader (JAWS 6.1 or newer or
Window-Eyes 4.2 or newer), bring up the list of controls (ins+f5 in
JAWS) - you should see more than "button" or "checkbox" - the names of
the controls should appear here also.
3) Using a SR, read the flash content from top to bottom - line by line
reading works well.
3.1) Verify that the reading order includes all necessary
content
3.2) Verify that the content reads in the expected order.
3.3) Verify that graphic objects that should have an accessible
name (equivalent to HTML img alt)do and that it is appropriate.
3.4) Verify that the reading order doesn't jump back to the top
of the Flash content - sometimes if there are refreshing elements in the
Flash content this can happen. If it does happen then it is important
to have these refreshes supressed in Flash authoring.
3.5) Verify that actual controls (e.g. checkboxes) and
custom-made controls (e.g. a rectangle that is made into a two-state
button that changes its appearance to look like a checked checkbox when
clicked) are correctly identified and convey correct information to the
user.
4) Using the SR, go to the start of the Flash content and interact with
any controls - this may mean entering forms mode to interact with
controls.
4.1) Controls should behave according to the same rules
specified in the keyboard testing steps listed in the blog entry.
4.2) Interactive elements in Flash content will have many of the
same difficulties that exist in javascript controls in AJAX/DOM scripted
applications. The issue of notification is important to keep in mind -
you may click a button in Flash, but will the user be able to find the
result? Is the change immediately downstream or is it somewhere else in
the app?
This is just a quick start for SR testing, but hopefully is helpful. Let
me know.
AWK
From: ben morrison
Date: Tue, Nov 14 2006 9:00AM
Subject: Re: Testing a flash movie
← Previous message | Next message →
On 11/14/06, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
> > I am not developing the flash application, it already exists,
> > I was asked to see how accessible it is.
>
> I wrote a post on testing keyboard access in Flash and Flex that may
> help:
> http://blogs.adobe.com/accessibility/2006/06/testing_keyboard_access_in_
> fla_1.html
>
> I need to write one that includes SR support, but here's a quick
> protocol to try out for SR testing - feedback welcomed!
>
> 1) Verify that the SWF is not using WMODE=transparent or WMODE=opaque.
> No WMODE setting, or WMODE=default is good. If the wrong WMODE setting
> is used, the content is inaccessible to SR users.
>
> 2) Using a newer version of a screen reader (JAWS 6.1 or newer or
> Window-Eyes 4.2 or newer), bring up the list of controls (ins+f5 in
> JAWS) - you should see more than "button" or "checkbox" - the names of
> the controls should appear here also.
>
> 3) Using a SR, read the flash content from top to bottom - line by line
> reading works well.
> 3.1) Verify that the reading order includes all necessary
> content
> 3.2) Verify that the content reads in the expected order.
> 3.3) Verify that graphic objects that should have an accessible
> name (equivalent to HTML img alt)do and that it is appropriate.
> 3.4) Verify that the reading order doesn't jump back to the top
> of the Flash content - sometimes if there are refreshing elements in the
> Flash content this can happen. If it does happen then it is important
> to have these refreshes supressed in Flash authoring.
> 3.5) Verify that actual controls (e.g. checkboxes) and
> custom-made controls (e.g. a rectangle that is made into a two-state
> button that changes its appearance to look like a checked checkbox when
> clicked) are correctly identified and convey correct information to the
> user.
>
> 4) Using the SR, go to the start of the Flash content and interact with
> any controls - this may mean entering forms mode to interact with
> controls.
> 4.1) Controls should behave according to the same rules
> specified in the keyboard testing steps listed in the blog entry.
> 4.2) Interactive elements in Flash content will have many of the
> same difficulties that exist in javascript controls in AJAX/DOM scripted
> applications. The issue of notification is important to keep in mind -
> you may click a button in Flash, but will the user be able to find the
> result? Is the change immediately downstream or is it somewhere else in
> the app?
>
> This is just a quick start for SR testing, but hopefully is helpful. Let
> me know.
That looks great, ill give it a try, thanks.
ben
--
Ben Morrison
From: John Foliot
Date: Tue, Nov 14 2006 10:20AM
Subject: Re: Testing a flash movie
← Previous message | Next message →
Andrew Kirkpatrick wrote:
>
> This is just a quick start for SR testing, but hopefully is helpful.
> Let me know.
Andrew,
This is *extremely* useful. Thanks!!
JF
---
John Foliot
Academic Technology Specialist
Stanford Online Accessibility Program
http://soap.stanford.edu
Stanford University
560 Escondido Mall
Meyer Library 181
Stanford, CA 94305-3093
From: Joshue O Connor
Date: Tue, Nov 14 2006 3:40PM
Subject: Re: Testing a flash movie
← Previous message | Next message →
Andrew,
Thats a interesting list of guidelines for testing the accessibility of
Flash content.
I have a question (or two) though.
> 1) Verify that the SWF is not using WMODE=transparent or WMODE=opaque.
> No WMODE setting, or WMODE=default is good. If the wrong WMODE setting
> is used, the content is inaccessible to SR users.
Does varying WMODE make *all* of the content of the Flash movie
invisible to the screen reader and if so why?
WMODE relates to making the background of Flash movies transparent
(enabling layering of SWFs),
so how does it turn off the access to the screen reader? Does it
interfere with the OSM?
On the Adobe site [1] it says:
> Using a WMODE value of 'opaque' or 'transparent' will prevent a Flash movie from playing in the topmost layer
and allow you to adjust the layering of the movie within other layers of
the HTML document.
Does the the fact that the Flash SWF will not be played in the top layer
affect the screen readers access to its content?
Can the screen reader only access content on a specific layer (I am
guessing the topmost DHTML layer by default)?
Can this be overridden by varying the z-index of the DHTML layer to
ensure that the layer containing the SWF is by default
on top, even if the settings WMODE=transparent or WMODE=opaque are used?
[1] http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_15523
Cheers
Josh
********************************************************************
NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.
NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI
********************************************************************
From: Andrew Kirkpatrick
Date: Wed, Nov 15 2006 9:20AM
Subject: Re: Testing a flash movie
← Previous message | Next message →
> Does varying WMODE make *all* of the content of the Flash
> movie invisible to the screen reader and if so why?
> WMODE relates to making the background of Flash movies
> transparent (enabling layering of SWFs), so how does it turn
> off the access to the screen reader? Does it interfere with the OSM?
The Flash player doesn't send any information to MSAA in this situation.
This is a shortcoming that we will hopefully address but related to the
difficulties of the player sending MSAA info when displaying in a
windowless mode.
AWK
From: Joshue O Connor
Date: Wed, Nov 15 2006 9:30AM
Subject: Re: Testing a flash movie
← Previous message | Next message →
> The Flash player doesn't send any information to MSAA in this situation.
> This is a shortcoming that we will hopefully address but related to the
> difficulties of the player sending MSAA info when displaying in a
> windowless mode.
Thanks for that Andrew.
Josh
Andrew Kirkpatrick wrote:
>> Does varying WMODE make *all* of the content of the Flash
>> movie invisible to the screen reader and if so why?
>> WMODE relates to making the background of Flash movies
>> transparent (enabling layering of SWFs), so how does it turn
>> off the access to the screen reader? Does it interfere with the OSM?
>
> The Flash player doesn't send any information to MSAA in this situation.
> This is a shortcoming that we will hopefully address but related to the
> difficulties of the player sending MSAA info when displaying in a
> windowless mode.
>
> AWK
>
>
>
>
>
********************************************************************
NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.
NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI
********************************************************************
From: Rebecca Ballard
Date: Thu, Nov 16 2006 1:40PM
Subject: Re: Testing a flash movie
← Previous message | No next message
I think the very fact that you said there's no keyboard access says straight
away that the app is not accessible <grin>
Rebecca
= EMAIL ADDRESS REMOVED =
Sign up for regular tips and tricks at www.withoutamouse.com/newsletter.
Check out my new blog at www.withoutamouse.com/blog
Thinking about Broadband? Check out www.withoutamouse.com/broadband.