- From: Andrew Kirkpatrick <akirkpat@adobe.com>
- Date: Thu, 7 Sep 2006 08:05:23 -0700
- To: "Gez Lemon" <gez.lemon@gmail.com>, "Gregg Vanderheiden" <gv@trace.wisc.edu>
- Cc: <w3c-wai-gl@w3.org>
> > 4. If there is an element within a technology > specification that is not > > supported by AT we can: > > > > a. Not include it as a sufficient technique (e.g. not > include 'object' > > in our list of sufficient techniques) > > I'm a bit confused. It's the object element that makes Flash > work with IE and reveal the accessibility features of Flash > to MSAA. The issue is that when using the proper MIME type > (application/x-shockwave-flash), the Flash movie's > accessibility features are not revealed to MSAA, but they are > when using the class id for the ActiveX object. If we ban the > object element, there is no way Flash can be used accessibly. > It's possible to just use the object element to include Flash > content that works with all modern user agents, without > having to use embed (requires hacks for IE), but it's > impossible to just rely on the embed element as IE doesn't > support it at all. The Flash Satay method [1] didn't work > because it didn't use the ActiveX object for IE. I think that this was just a "for instance" - it might be just as well to talk about some other element, like bidi or sup elements in HTML 4.0. As far as the Flash goes, I just want to clarify Gez's points. The issue is not that the Flash movie's accessibility information is not revealed to MSAA, but that a major AT doesn't look at the MSAA data that is provided. Other screen readers and talking browsers do read the MSAA data, so it is present. All of this is a bit of an aside to the clarification of baseline, but if we're talking about Flash as an example we should have the facts clear. AWK Andrew Kirkpatrick Corporate Accessibility Engineering Lead Adobe Systems akirkpatrick@adobe.com
Received on Thursday, 7 September 2006 15:06:25 UTC