E-mail List Archives
Thread: flash satay firefox bug
Number of posts in this thread: 17 (In chronological order)
From: Patrick H. Lauke
Date: Sun, May 22 2005 7:37PM
Subject: flash satay firefox bug
No previous message | Next message →
A small heads-up to alert those (myself included) using the flash satay
method http://www.alistapart.com/articles/flashsatay/ of an annoying
variation of an old bug in firefox:
"The flash satay method has become a widely used technique for embedding
flash into valid XHTML documents. However, even current builds of
Mozilla Firefox (at the time of writing, version 1.0.4) seem to have a
problem which can have a serious impact on accessibility: flash content
embedded this way swallows the tab focus, making it impossible to
proceed beyond the movie when using keyboard navigation.
"Of course, the core issue of embedded flash stealing focus is not new,
but the fact that satay triggers this in Firefox - when Gecko based
browsers have, up to now, been known to simply skip flash movies when
tabbing, which was another issue in itself - is a novel and annoying
variation, particularly when flash is used purely for decorative effects
rather than functional page elements."
Check out the example page in firefox.
http://www.splintered.co.uk/experiments/76/
--
Patrick H. Lauke
_____________________________________________________
re
From: Stephanie Sullivan
Date: Sun, May 22 2005 8:03PM
Subject: Re: flash satay firefox bug
← Previous message | Next message →
On 5/22/05 9:38 PM, "Patrick H. Lauke" simply typed the following:
> "Of course, the core issue of embedded flash stealing focus is not new,
> but the fact that satay triggers this in Firefox - when Gecko based
> browsers have, up to now, been known to simply skip flash movies when
> tabbing, which was another issue in itself - is a novel and annoying
> variation, particularly when flash is used purely for decorative effects
> rather than functional page elements."
Does the same issue apply to the FlashObject method by Geoff Stearns I
wonder? I've started to use that recently.
http://blog.deconcept.com/
Stephanie Sullivan
Community MX Partner :: http://www.communitymx.com/author.cfm?cid=1008
Team Macromedia for Dreamweaver :: http://tinyurl.com/6huw3
Co-Author .: "Macromedia Dreamweaver MX 2004 Magic" :. New Riders
"Sometimes I wonder whether the world is being run by smart people who
are putting us on or by imbeciles who really mean it," said Mark Twain.
From: Patrick H. Lauke
Date: Sun, May 22 2005 8:12PM
Subject: Re: flash satay firefox bug
← Previous message | Next message →
Stephanie Sullivan wrote:
> Does the same issue apply to the FlashObject method by Geoff Stearns I
> wonder? I've started to use that recently.
No, the issue does not appear with FlashObject, because the javascript
effectively includes the flash with an (invalid, although working) EMBED
element, rather than a pure OBJECT. The source validates, as the invalid
markup is added client side. Some may call it cheating, or going against
the whole idea of the spec...but I'll leave *that* discussion for
another day...
--
Patrick H. Lauke
_____________________________________________________
re
From: Stephanie Sullivan
Date: Mon, May 23 2005 5:30AM
Subject: Re: flash satay firefox bug
← Previous message | Next message →
On 5/22/05 10:13 PM, "Patrick H. Lauke" simply typed the following:
> No, the issue does not appear with FlashObject, because the javascript
> effectively includes the flash with an (invalid, although working) EMBED
> element, rather than a pure OBJECT. The source validates, as the invalid
> markup is added client side. Some may call it cheating, or going against
> the whole idea of the spec...but I'll leave *that* discussion for
> another day...
K... That's what I thought. I suppose if we wanted to go with the specs, we
just wouldn't use Flash. But I'm not willing to do that. This works for me
for now... Especially since this method shows a static image if Flash is not
available. I like that.
Stephanie Sullivan
Community MX Partner :: http://www.communitymx.com/author.cfm?cid=1008
Team Macromedia for Dreamweaver :: http://tinyurl.com/6huw3
Co-Author .: "Macromedia Dreamweaver MX 2004 Magic" :. New Riders
"Those who stand for nothing fall for everything." -- Alexander Hamilton
From: Stephanie Sullivan
Date: Mon, May 23 2005 6:02AM
Subject: Re: flash satay firefox bug
← Previous message | Next message →
On 5/23/05 7:30 AM, "Stephanie Sullivan" simply typed the following:
> Especially since this method shows a static image if Flash is not
> available.
Clarification... In typing too fast, I misspoke. :P What I meant to say is
that if JavaScript is not available a static image is shown. If Flash is not
available, your alternate text is shown. Sorry. :)
Stephanie Sullivan
Community MX Partner :: http://www.communitymx.com/author.cfm?cid=1008
Team Macromedia for Dreamweaver :: http://tinyurl.com/6huw3
Co-Author .: "Macromedia Dreamweaver MX 2004 Magic" :. New Riders
From: Rainer Wagener
Date: Mon, May 23 2005 7:32AM
Subject: RE: flash satay firefox bug
← Previous message | Next message →
Hi Patrick,
> flash content embedded this way swallows
> the tab focus, making it impossible to
> proceed beyond the movie when using
> keyboard navigation.
on your test page:
http://www.splintered.co.uk/experiments/76/
Jason Davis points to the CSS method { -moz-user-focus:ignore; }
which avoids getting stuck inside a flash object in Gecko Browsers.
When I first run into this method I thought it to be a good solution
for the 'flash satay firefox bug' at least when there is no need of
focusing the flash object. But besides not being able to use the
flash object as a button there is another problem: Once you turn off
CSS the site is no longer tabable what I suggest to be quite a
serious accessiblity issue.
After trying out all possible and may be some impossible ways of
embedding flash accessible in Geckos and producing valide code at
the same time, I came to the conclusion that the Java Script method
is the best way to do it.
> No, the issue does not appear with FlashObject, because
> the javascript
> effectively includes the flash with an (invalid, although
> working) EMBED
> element, rather than a pure OBJECT. The source validates,
> as the invalid
> markup is added client side. Some may call it cheating,
> or going against
> the whole idea of the spec...but I'll leave *that* discussion for
> another day...
Yes, it is cheating somehow. But as long as browsers simply do not
support the specs, one has to be tricky.
We don't produce websites for the specs but for people. It's more
important to provide accessibility and usability as well than
following rules that possibly get your visitors stuck somewhere in a
flash object.
Regards Rainer
--
Rainer Wagener
Webentwicklungen
Blumenstr. 57
69115 Heidelberg
Tel.: 062 21 - 60 05 81
www.rohschnitt.de
From: Andrew Kirkpatrick
Date: Mon, May 23 2005 7:49AM
Subject: Re: flash satay firefox bug
← Previous message | Next message →
> Yes, it is cheating somehow. But as long as browsers simply do not
> support the specs, one has to be tricky.
> We don't produce websites for the specs but for people. It's more
> important to provide accessibility and usability as well than
> following rules that possibly get your visitors stuck somewhere in a
> flash object.
If accessibility is a concern, the satay method is a problem, since at
least in JAWS (but not with Window-Eyes) a flash movie embedded this
way renders the movie completely inaccessible. This isn't an issue for
decorative Flash, but if there is content in the SWF it is best to use
a different embedding method.
AWK
--
Andrew Kirkpatrick
WGBH National Center for Accessible Media
125 Western Ave.
Boston, MA 02134
E-mail: = EMAIL ADDRESS REMOVED =
617.300.4420
From: Michael Moore
Date: Mon, May 23 2005 8:56AM
Subject: Re: flash satay firefox bug
← Previous message | Next message →
Andrew Kirkpatrick wrote:
>
> If accessibility is a concern, the satay method is a problem, since at
> least in JAWS (but not with Window-Eyes) a flash movie embedded this way
> renders the movie completely inaccessible. This isn't an issue for
> decorative Flash, but if there is content in the SWF it is best to use a
> different embedding method.
>
> AWK
Its beginning to sound like we may need to resort to sniffers. Since
the satay method is not necessary for IE and Jaws and Window Eyes do not
work with Gecko browsers one solution may be to use the satay method
only if the gecko browser is detected. What does everyone think?
Mike
From: Patrick Lauke
Date: Mon, May 23 2005 9:57AM
Subject: RE: flash satay firefox bug
← Previous message | Next message →
> Michael Moore
> Since
> the satay method is not necessary for IE
It's not a case of necessary in IE or not...it's that the traditional way
of using nested OBJECT/EMBED does not validate as XHTML.
Patrick
________________________________
Patrick H. Lauke
Webmaster / University of Salford
http://www.salford.ac.uk
From: Andrew Kirkpatrick
Date: Mon, May 23 2005 10:01AM
Subject: Re: flash satay firefox bug
← Previous message | Next message →
> Its beginning to sound like we may need to resort to sniffers. Since
> the satay method is not necessary for IE and Jaws and Window Eyes do
> not work with Gecko browsers one solution may be to use the satay
> method only if the gecko browser is detected. What does everyone
> think?
Only JAWS has this problem, just to be clear. Window Eyes and IBM
Homepage Reader (v. 3.04) read the Satay'd Flash fine.
AWK
--
Andrew Kirkpatrick
WGBH National Center for Accessible Media
125 Western Ave.
Boston, MA 02134
E-mail: = EMAIL ADDRESS REMOVED =
617.300.4420
From: Stephanie Sullivan
Date: Mon, May 23 2005 3:27PM
Subject: Re: flash satay firefox bug
← Previous message | Next message →
On 5/23/05 12:01 PM, "Andrew Kirkpatrick" simply typed the following:
> Only JAWS has this problem, just to be clear. Window Eyes and IBM
> Homepage Reader (v. 3.04) read the Satay'd Flash fine.
Does anyone know of RECENT stats for the number of users of each of these
screen readers? (I'm guessing that JAWS still leads quite nicely?)
Stephanie Sullivan
Community MX Partner :: http://www.communitymx.com/author.cfm?cid=1008
Team Macromedia for Dreamweaver :: http://tinyurl.com/6huw3
Co-Author .: "Macromedia Dreamweaver MX 2004 Magic" :. New Riders
The illiterate of the future will not be the person who cannot read. It will
be the person who does not know how to learn. - Alvin Toffler, Futurist
From: Austin, Darrel
Date: Mon, May 23 2005 4:40PM
Subject: RE: flash satay firefox bug
← Previous message | Next message →
> It's not a case of necessary in IE or not...it's that the
> traditional way of using nested OBJECT/EMBED does not
> validate as XHTML.
Which brings up another solution...don't use XHTML. (It's used more often
than not for no real reason...)
-Darrel
From: John Foliot - WATS.ca
Date: Mon, May 23 2005 7:59PM
Subject: RE: flash satay firefox bug
← Previous message | Next message →
Stephanie Sullivan wrote:
>
> Does anyone know of RECENT stats for the number of users of
> each of these
> screen readers? (I'm guessing that JAWS still leads quite nicely?)
>
Stephanie,
While those numbers may be of interest, I am personally troubled when
developers start developing for user agents and/or combinations of user
agents and assistive technology. Why should it matter what percentage of
users use JAWS... Are you suggesting that users of WindowEyes or IBM
HomePageReader should some-how be left in the cold, or treated
"differently"? What of users of other, smaller, yet equally useful screen
reading applications? Surely we're not descending into the "best listened
to in JAWS" hell are we?
I realize that this may appear to be coming on very strong, but please
consider the message as much as the tone. Developing for any one given
user-group or software application will always be at the cost of another.
Stick to the standards, and work within them if you want real accessibility
compliance, else, fall back on the frustrating but published Priority 1
Checkpoint #11.4 "If, after best efforts, you cannot create an accessible
page, provide a link to an alternative page that uses W3C technologies, is
accessible, has equivalent information (or functionality), and is updated as
often as the inaccessible (original) page.".
I will guess from your sig file that you either work for (or very closely
with) macromedia/Adobe. Flash is great, it has it's place, but
unfortunately will never be 100% accessible, given the very nature of the
tool at hand. Music will never be 100% accessible to the auditory impaired
either, that too is just a reality. Using Flash "just because"... Well,
that's a decision that needs to be made in an informed manner, trying to
wiggle around the realities however is a slippery slope and one which I
would hope that this list would not support (but who are we eh?).
Just my $0.02 worth.
JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-267-1983 / 1-866-932-4878 (North America)
From: Stephanie Sullivan
Date: Tue, May 24 2005 5:30AM
Subject: Re: flash satay firefox bug
← Previous message | Next message →
On 5/23/05 9:59 PM, "John Foliot - WATS.ca" simply typed the following:
> While those numbers may be of interest, I am personally troubled when
> developers start developing for user agents and/or combinations of user
> agents and assistive technology. Why should it matter what percentage of
> users use JAWS... Are you suggesting that users of WindowEyes or IBM
> HomePageReader should some-how be left in the cold, or treated
> "differently"? What of users of other, smaller, yet equally useful screen
> reading applications? Surely we're not descending into the "best listened
> to in JAWS" hell are we?
Hahaha... Without a doubt we are not. ;) If I had time to be more active on
this list, you'd know me and you'd already know that... But I don't blame
you for the reaction in the least. My question was purely curiosity
however. I was just wondering if JAWS was losing market share to some of the
less expensive, more available readers... Or whether they were still holding
strong... (Actually, I read this thread as saying that JAWS was the one with
the Flash satay problem?)
>
> I realize that this may appear to be coming on very strong, but please
> consider the message as much as the tone. Developing for any one given
> user-group or software application will always be at the cost of another.
> Stick to the standards, and work within them if you want real accessibility
> compliance, else, fall back on the frustrating but published Priority 1
> Checkpoint #11.4 "If, after best efforts, you cannot create an accessible
> page, provide a link to an alternative page that uses W3C technologies, is
> accessible, has equivalent information (or functionality), and is updated as
> often as the inaccessible (original) page.".
Yes... I'm a standards junkie... Not to worry. ;)
>
> I will guess from your sig file that you either work for (or very closely
> with) macromedia/Adobe. Flash is great, it has it's place, but
> unfortunately will never be 100% accessible, given the very nature of the
> tool at hand. Music will never be 100% accessible to the auditory impaired
> either, that too is just a reality. Using Flash "just because"... Well,
> that's a decision that needs to be made in an informed manner, trying to
> wiggle around the realities however is a slippery slope and one which I
> would hope that this list would not support (but who are we eh?).
I went to a MAX last year, I attended Bob Regan's, "Accessible Flash"
session. It was very interesting and showed that IF Flash developers
actually stopped to learn how to use the accessibility features in Flash,
their sites would be so much more accessible. I won't argue whether or not
the can be "completely accessible," I'm not a Flash developer and really
I've not spent that much time looking at it. I do know, however, that many
Flash developer's are young guys who never thought about the fact that even
I can't read their 9pt text in their life. Much less that they should create
their buttons so that a screen reader can access them. :P
I would be interested to know -- on the Flash satay question -- if setting
the wmode of your Flash movie to opaque would handle the screen reader focus
issues. I know that an opaque or transparent wmode currently allows screen
readers to pass by Flash and "not get stuck" in it... (I also know that Bob
Regan said that that's not a "feature" but a bug... But it works till they
fix it and heck, maybe that won't be in the development budget this year.
;)) I wrote an article on Flash, DHTML menus and Flash (free) if you want to
know more about wmode and Flash:
http://www.communitymx.com/abstract.cfm?cid=E5141
As to my involvement with Macromedia/not-yet-Adobe? I'm simply a volunteer
that works mostly in the Dreamweaver area... My development strengths are
X/HTML, CSS and accessibility... Those are the things I both do, and bellow
about, the most. ;)
Stephanie Sullivan
Community MX Partner :: http://www.communitymx.com/author.cfm?cid=1008
Team Macromedia for Dreamweaver :: http://tinyurl.com/6huw3
Co-Author .: "Macromedia Dreamweaver MX 2004 Magic" :. New Riders
"The measure of a life, after all, is not its duration, but its donation."
-- Corrie ten Boom
From: John Foliot - WATS.ca
Date: Tue, May 24 2005 5:44AM
Subject: RE: flash satay firefox bug
← Previous message | Next message →
Stephanie Sullivan wrote:
>
> My question was purely curiosity
> however. I was just wondering if JAWS was losing market share
> to some of the
> less expensive, more available readers... Or whether they
> were still holding
> strong...
Gut tells me it's still status quo
>
> Yes... I'm a standards junkie... Not to worry. ;)
/@
___>
(__O)
(____@)
(____@)
(__o)_
(alt="ASCII art - thumbs up")
>
> As to my involvement with Macromedia/not-yet-Adobe?
<q>
Adobe to Acquire Macromedia
On April 18, 2005 Adobe Systems Incorporated (Nasdaq: ADBE) announced a
definitive agreement to acquire Macromedia (Nasdaq: MACR) in an all-stock
transaction valued at approximately $3.4 billion. By combining the passion,
creativity, and technology of two leading-edge companies, we will continue
to drive innovations that help people and organizations everywhere
communicate better.
<cite>http://www.adobe.com/aboutadobe/invrelations/adobeandmacromedia.html<;/
cite>
</q>
> I'm
> simply a volunteer
> that works mostly in the Dreamweaver area... My development
> strengths are
> X/HTML, CSS and accessibility... Those are the things I both
> do, and bellow
> about, the most. ;)
Then we are on the same page. Cool!
JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-267-1983 / 1-866-932-4878 (North America)
From: Robinson, Norman B - Washington, DC
Date: Tue, May 24 2005 10:44AM
Subject: RE: flash satay firefox bug
← Previous message | Next message →
John,
You bring up an interesting point, but I think your email
ignores the problem of testing and developer acceptance.
If only one screen reader provided accessibility for Flash, and
all other screen readers did not provide that accessibility, which
screen reader would you use to TEST accessibility? There are
accessibility standards, but as you well know, you can make a 508
compliant application or web page and it still not be accessible. I
think this is one reason the word "accessibility" wasn't in the section
508 standards. There is simply "508 compliance". The empirical, hands-on
proof many seek are often driven by testing using the same assistive
technologies used by the end-user. It is end-user simulation.
I think that if I had to test I would test with as many user
scenarios as is important to success. I certainly don't test my
applications with the two previous versions of MS Windows. I use what I
know my users are using.
If you can access it with a specific assistive technology does
that mean it is accessible? Probably. Does it mean it is 508 compliant?
Probably. Are their exceptions? Definitely! I don't think the fact one
vendor has provided more access because of figuring out non-standard
ways to give that information to the user means that the whole industry
will flock to that vendor. I can testify to how slow the industry moves.
I probably could pull an example of a specific vendor's software that
used non-standard video hooks and reliance on system information that
wasn't documented. Did that mean the other vendor's software should be
treated differently? No. It meant they figured out a way to provide
access. Nonstandard, but desperately needed access. If a standardized
way did exist, I'm sure they would have used it. Standards help
everybody!
That said - I'm with you! Developers should never target a
specific assistive technology, with the exception of scripting or
something equivalent that help the assistive technology use the
standards. And if the vendors are doing their jobs, they should have
little needs of scripting support for accessing standard technology. I
think having all the assistive technologies tested against a standards
test, similar to the ACID2 test (http://www.webstandards.org/act/acid2/)
is a desirable goal. It would promote standards and let developers know
when to better trust the results of their hands-on testing.
I would like to see the latest numbers on specific user agents,
including combinations of user agents and assistive technologies. I
think it enhances our understanding and encourages vendors of all
software products, specific to an operating system or web based, to
create accessible products.
Regards,
Norman Robinson
From: Stephanie Sullivan
Date: Tue, May 24 2005 1:41PM
Subject: Re: flash satay firefox bug
← Previous message | No next message
On 5/24/05 7:45 AM, "John Foliot - WATS.ca" simply typed the following:
>> As to my involvement with Macromedia/not-yet-Adobe?
>
> <q>
> Adobe to Acquire Macromedia
> On April 18, 2005 Adobe Systems Incorporated (Nasdaq: ADBE) announced a
> definitive agreement to acquire Macromedia (Nasdaq: MACR) in an all-stock
> transaction valued at approximately $3.4 billion.
But John... I refuse to say it till it HAPPENS... ;)) I'm being stubborn...
There's still some legalese that has to happen. Till then, I stand by my
not-yet-Adobe statement.
Stephanie Sullivan
Community MX Partner :: http://www.communitymx.com/author.cfm?cid=1008
Team Macromedia for Dreamweaver :: http://tinyurl.com/6huw3
Co-Author .: "Macromedia Dreamweaver MX 2004 Magic" :. New Riders