W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2006

RE: Incorporating Flash into a Website

From: Andrew Kirkpatrick <akirkpat@adobe.com>
Date: Wed, 11 Oct 2006 05:26:08 -0700
Message-ID: <53744A0A1D995C459E975F971E17F56401538C98@namail4.corp.adobe.com>
To: "John Foliot" <jfoliot@stanford.edu>, "Patrick H. Lauke" <redux@splintered.co.uk>
Cc: <w3c-wai-ig@w3.org>

> Actually Patrick, I believe it's the other way 'round, that 
> it is a strange mix of Live DOM and raw HTML stew (the 
> virtual buffer) 
> [http://juicystudio.com/article/making-ajax-work-with-screen-r
> that the screen readers are dealing with.  

I'd caution against making too many generalizations about how screen
readers do their work - different screen readers function in different
ways - some combination of gathering information from MSAA, parsing of
the DOM or the HTML files, and looking at the screen is used, but the
specifics are the "special sauce" that you'll be unlikely to nail down.

> If it were all Live DOM, then many of the AJAX "issues" would 
> not exist for screen readers as they would note the change in 
> focus happening in the DOM view.  But they need an actual 
> refresh to change focus inter-page 
> [http://www.sitepoint.com/article/ajax-screenreaders-work] 

 Same here.  The triggers that each screen reader use are also part of
the special sauce, and are most likely selected by the screen reader
vendors to achieve refreshing at times that are deemed appropriate.
Unfortunately, there isn't any consistency in how this is done and
developers need to test more than they otherwise might to make sure that
they get correct functioning.

Received on Wednesday, 11 October 2006 12:27:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:29 UTC