JAWS. There are open-source Screen-Readers, but, if I remember right, the only Adobe supported platforms for Flex with Screen Readers were (are?) Windows, Internet Explorer and JAWS with JAWS scripts.
On Tue, Jan 24, 2012 at 5:00 PM, Rick Winscot <[email protected]>wrote: > @David Buhler - did you use JAWS or something else for screen reading? > On Jan 24, 2012 11:29 AM, "David Buhler" <[email protected]> wrote: > > > I built a Flex website for the Federal government that was fully > accessible > > (PCIP.gov). I did a demo for Adobe of the Accessibility capabilities. I'm > > glad to help with answering any accessibility questions. > > > > On Tue, Jan 24, 2012 at 11:12 AM, Frank Pepermans <[email protected] > > >wrote: > > > > > Would be good to know exactly why Flex underperforms in areas such as > > item > > > renderers right now, > > > so much goes on when for example a grid is created and shown, that it > is > > > hard to track down. > > > > > > i.e. having tandem of the Flex layout framework plus Starling would > still > > > be slow, especially the added code to manage an extra 3D display list. > > > > > > optimizing the Flex innards, finding a good alternative to the TLF > > > components (a big hit for Spark based renderers), in future maybe > adding > > > the Worker classes into Flex etc... might be enough to leave the > stage3D > > > alone? > > > > > > -----Original Message----- From: Roland Zwaga > > > Sent: Tuesday, January 24, 2012 3:07 PM > > > To: [email protected] > > > Subject: Re: Pushing Flex components thorough the GPU > > > > > > > > >> Thanks Roland, that makes sense. > > >> If I remember correctly Stage3D content is rendered behind the normal > > >> DisplayList. This does allow you to mix Stage3D content with standard > > >> components. > > >> I guess when taking this into account it seems like item renderers > would > > >> not be the way to go. > > >> > > >> What about narrowing down this use case and introducing a new > component, > > >> maybe something based off of the DataGroup? This may be able to allow > us > > >> to > > >> get something "out the door" even with issues related to z-sorting and > > >> accessibility. > > >> > > >> I know currently these components rely heavily on the DisplayList, but > > >> after looking at the Starling framework I really don't think there is > > >> anything in place that would prevent this from happening. > > >> > > >> > > > It sounds viable perhaps. I suggest you do some little tests do see if > it > > > is a workable > > > avenue to explore. Using a POC component we could try and determine > > whether > > > the > > > accessibility limitations are of real issue or not. I'm not sure, but > > > there's probably some kind > > > of rules about what accepted accessibility is for a component, so at > > least > > > we'll know what > > > to look out for. Anyone here who can shed a light on this? I must say > > that > > > I know next to nothing > > > about it :) All I know is that its important, haha (sorry, ignorance > > > shining through there...) > > > I do believe that the combination of Stage3D and regaulr DisplayList > > based > > > UI ought to > > > be explored, because it seems like it could have great potential. But > we > > > will need to > > > tread very carefully. > > > > > > cheers, > > > > > > Roland > > > > > >
