New: Firefox 3 with Screen Readers FAQ

classic Classic list List threaded Threaded
65 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Virtual buffers in Windows [was Scriptability]

T.V Raman

Mike --Yes, you're correct.
The role="application" bit will help AT  distinguish  between
documents and applications. There is nothing wrong with virtual
buffers fo document interaction.

On a separate note, you had asked earlier on the thread about the
emacspeak <-> Firefox bridge --- and as to how that was similar
to or different from a virtual buffer.

To answer that question:

There are indeed similarities to a virtual buffer there ---  when
Firefox hands off content to emacspeak to display and speak, you
get a virtual buffer.
The difference mostly shows up in how it's used --- The "virtual
view" is only created on demand, and mostly created for filtered
views --- so:

0) Emacspeak essentially uses Firefox as a DOM server.
1) Firefox handles all the gory details of HTML parsing,
   document.write execution, and anything else involved in keeping
   the DOM live.
2) Emacspeak provides  end-user commands that allow you to view
   different projections of the live DOM.
3) When invoked, those commands request the appropriate filtered
view from Friefox.


the browser

Michael Curran writes:
 > A major reason why NVDA does not render virtualBuffers if the page has
 > an ARIA role of application, rather than document.
 >
 > NVDA uses virtualBuffers and nothing can change this right now, but, if
 > app developers write a web application that should feel like an
 > application, then my belief is that they must set role application.  ATs
 > must be able to tell the difference between documents and applications.
 > Its not simply just whether or not to use virtualBuffers, its actually
 > to understand whether this is a document or application.
 >
 > Mick
 >
 >
 > T.V Raman wrote:
 > > well said. In addition, as  the Web transitions from pure
 > > documents to user interfaces and interactive applications, the
 > > model of navigating flat, static  documents breaks down --- in
 > > general having two modes between which the user  has to
 > > constantly switch is not something that will work well with
 > > Web applications that implement all their widgets via DHTML. As a
 > > case in point, try playing with any of the initial ARIA code
 > > examples for complex widgets --- you *never* want to have to
 > > remember which mode the screenreader you're using is in --- in
 > > general, you want to interact with the Web Application as any
 > > other mainstream user does, namely, by interacting with the page,
 > > rather than interacting through an intermediary.
 > >
 > > Jason White writes:
 > >   >  On Sun, Jul 13, 2008 at 11:27:52AM +1000, James Teh wrote:
 > >   >  >  Three reasons that immediately come to mind:
 > >   >  >  * Although virtual buffers involve a slight rendering delay (which is
 > >   >  >  usually unnoticeable in our implementation now), once rendered, they
 > >   >  >  allow for instantaneous access to any portion of the page. One never has
 > >   >  >  to wait for a complex part of the document to be rendered into a
 > >   >  >  readable form. While I haven't personally used Orca and Firefox much, i
 > >   >  >  understand that there can occasionally be some delay while moving
 > >   >  >  throughout the page, although corrections are of course welcome.
 > >   >
 > >   >  With a modern, fast machine, I haven't noticed any delays peculiar to Firefox.
 > >   >  There are speech-related delays involving gnome-speech and eSpeak, but a patch
 > >   >  has been circulating to correct those. Again, I haven't been able to reproduce
 > >   >  them on my quad-core desktop system, although on my single-core laptop, this
 > >   >  issue does become slightly noticable.
 > >   >  >  * Cursor navigation in a virtual buffer is similar to that of any flat
 > >   >  >  document. You can move by character, word, line, block, etc. Cursor
 > >   >  >  navigation is always symmetrical; i.e. if one moves the cursor forward
 > >   >  >  in a certain way, reversing those movements will always land you back
 > >   >  >  where you started unless the document changed during the movement.
 > >   >  >  Again, I don't have any real experience with Orca and Firefox, but I
 > >   >  >  understand that the Firefox caret is not always symmetrical in this fashion.
 > >   >
 > >   >  Correct, but Orca by default moves the focus to the beginning of the line as
 > >   >  this is what users mostly desire according to the Orca developers.  With this
 > >   >  feature switched off, my understanding is that the cursor does arrive at the
 > >   >  same point in the document when navigational actions are reversed - barring
 > >   >  bugs, of course.
 > >   >  >  * Virtual buffers allow for very fast "quick navigation"; i.e. moving to
 > >   >  >  headings, links and other page elements.
 > >   >
 > >   >  Orca's structural navigation is very fast indeed.
 > >   >
 > >   >  I think the Orca developers were right not to create virtual buffers, and I
 > >   >  applaud this decision.
 > >   >
 > >   >  this also simplifies the user interface by eliminating multiple "modes" of
 > >   >  interaction.
 > >   >
 > >   >  _______________________________________________
 > >   >  dev-accessibility mailing list
 > >   >  [hidden email]
 > >   >  https://lists.mozilla.org/listinfo/dev-accessibility
 > >

--
Best Regards,
--raman

Title:  Research Scientist      
Email:  [hidden email]
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman
GTalk:  [hidden email], [hidden email]
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Virtual buffers in Windows [was Scriptability]

Aaron Leventhal-3
In reply to this post by T.V Raman
I used to think it was obvious there should be only 1 mode, but I'm not
a user. These days I think it's a matter of taste, and there are
practical reasons for either choice.

For example, one nice thing about having the app/forms modes is that it
gives the browser and JavaScript apps the chance to use whatever
keystrokes that they think are available, without having those be eaten
by the screen reader. There are a certainly lot of things fighting for
the same keys. On the other hand, perhaps it's easier to teach
non-technical people losing their site how to use a screen reader on the
web when there's only 1 mode.

It's probably good taht there continues to be experimentation and
improvement of both ways of addressing accessible web browsing. It may
become more clear over time that one model is better, or at least what
the advantages are.



- Aaron




David Bolter wrote:

> +1 for 1 mode!  Is this on the roadmap for commercial screen readers?
>
> cheers,
> David
>
> T.V Raman wrote:
>> well said. In addition, as the Web transitions from pure
>> documents to user interfaces and interactive applications, the
>> model of navigating flat, static documents breaks down --- in
>> general having two modes between which the user has to
>> constantly switch is not something that will work well with
>> Web applications that implement all their widgets via DHTML. As a
>> case in point, try playing with any of the initial ARIA code
>> examples for complex widgets --- you *never* want to have to
>> remember which mode the screenreader you're using is in --- in
>> general, you want to interact with the Web Application as any
>> other mainstream user does, namely, by interacting with the page,
>> rather than interacting through an intermediary.
>>
>> Jason White writes:
>> > On Sun, Jul 13, 2008 at 11:27:52AM +1000, James Teh wrote:
>> > > Three reasons that immediately come to mind:
>> > > * Although virtual buffers involve a slight rendering delay (which
>> is > > usually unnoticeable in our implementation now), once rendered,
>> they > > allow for instantaneous access to any portion of the page.
>> One never has > > to wait for a complex part of the document to be
>> rendered into a > > readable form. While I haven't personally used
>> Orca and Firefox much, i > > understand that there can occasionally be
>> some delay while moving > > throughout the page, although corrections
>> are of course welcome.
>> > > With a modern, fast machine, I haven't noticed any delays peculiar
>> to Firefox.
>> > There are speech-related delays involving gnome-speech and eSpeak,
>> but a patch
>> > has been circulating to correct those. Again, I haven't been able to
>> reproduce
>> > them on my quad-core desktop system, although on my single-core
>> laptop, this
>> > issue does become slightly noticable.
>> > > * Cursor navigation in a virtual buffer is similar to that of any
>> flat > > document. You can move by character, word, line, block, etc.
>> Cursor > > navigation is always symmetrical; i.e. if one moves the
>> cursor forward > > in a certain way, reversing those movements will
>> always land you back > > where you started unless the document changed
>> during the movement. > > Again, I don't have any real experience with
>> Orca and Firefox, but I > > understand that the Firefox caret is not
>> always symmetrical in this fashion.
>> > > Correct, but Orca by default moves the focus to the beginning of
>> the line as
>> > this is what users mostly desire according to the Orca developers.
>> With this
>> > feature switched off, my understanding is that the cursor does
>> arrive at the
>> > same point in the document when navigational actions are reversed -
>> barring
>> > bugs, of course.
>> > > * Virtual buffers allow for very fast "quick navigation"; i.e.
>> moving to > > headings, links and other page elements.
>> > > Orca's structural navigation is very fast indeed.
>> > > I think the Orca developers were right not to create virtual
>> buffers, and I
>> > applaud this decision.
>> > > this also simplifies the user interface by eliminating multiple
>> "modes" of
>> > interaction.
>> > > _______________________________________________
>> > dev-accessibility mailing list
>> > [hidden email]
>> > https://lists.mozilla.org/listinfo/dev-accessibility
>>
>

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Scriptability [was Re: New: Firefox 3 with Screen Readers FAQ]

mozilla accessibility
In reply to this post by Jason White-14
In my humble opinion, the concept was "invented" purely for practical
reasons.  Must have been around 1997 when win95 was the dominant
"accessible" operating system.  IE was accessible, but you couldn't really
do much except read links by tabbing around and I think you could get the
whole page read from top to bottom. You could use the Jaws cursor to read
the document, but if there were columner text or navigation along the left
edge for instance, then text from nav links would be intermixed with page
content and things became very confusing very fast.  So, without a good
alternative (I don't think MSAA was very mature back then, especially with
respect to IE), the virtual buffer concept seemed a good approach at the
time.  Perhaps its time is past, but ultimately I don't care how the screen
reader works as long as it can do all the things necessary to support modern
web applications, which I expect is more difficult using a virtual buffered
approach.


Just my two cents.
-- Rich

----- Original Message -----
From: "Jason White" <[hidden email]>
To: <[hidden email]>
Sent: Saturday, July 12, 2008 3:15 AM
Subject: Re: Scriptability [was Re: New: Firefox 3 with Screen Readers FAQ]


On Sat, Jul 12, 2008 at 04:47:37PM +1000, James Teh wrote:
> It should also be noted that our original Gecko virtual buffer code was
> implemented entirely in Python. It wasn't anywhere near as good as the
> current solution, but it certainly had some limited useability.

I'm not a Windows user, but I'm curious anyway: why do screen readers for
that
environment implement virtual buffers for Web content? I use Orca under
Linux,
which doesn't need any virtual buffers, and this is a good thing.

Virtual buffers remind me of off-screen models and all the reasons why they
are such a bad idea, especially when client-side Javascript comes along and
changes the document via the DOM.

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Virtual buffers in Windows [was Scriptability]

mozilla accessibility
In reply to this post by Michael Curran-2
>I am most certainly happy to investigate a non-virtualBuffer way for
>NVDA to access web documents, if the community at large thought it was
>worth it. In fact we will need to do this anyway for access to complex
>editable documents in Open Office and IBM Lotus Symphony etc. Perhaps
>once that work is done, then people could have the choice to use either
>interface.

Seems to me this would be the strongest case for not using virtual buffers
since you now have two code bases pertaining to web content which must be
maintained and kept in sync with respect to features, etc.  Interesting
though - I wasn't aware that  the non-virtual buffered approach in Windows
was so slow.

Again, I'm not a purist in any sense, so don't care whether my screen reader
uses virtual buffers or not, just as long as I can be guaranteed to see a
faithful representation of the page I'm working with, whether it be a
traditional web document, a web application, or a mixture of the two.

-- Rich

----- Original Message -----
From: "Michael Curran" <[hidden email]>
To: <[hidden email]>
Sent: Saturday, July 12, 2008 10:21 PM
Subject: Re: Virtual buffers in Windows [was Scriptability]


Hi Jason,

On Windows out-of-process access to accessibility APIs such as MSAA and
IAccessible2 is most likely some what slower than access to ATK in Unix.

Note that IAccessible2 also does not contain the collection interface
like ATK does, so jumping by particular node types such as headings
would be extreamly slow.

We have considered not using virtualBuffers for NVDA many times. But
each time we find its just too slow.

I think it is great that Orca is able to do it in Unix, and if it works
for Unix blind users then that is also great.

But, on Windows, it is just simply the case that the fastest and most
efficient way of providing access to complex documents to blind users is
via virtualBuffers.

Note that Jaws, Window Eyes, Dolphan Hal, System Access, and NVDA  all
use some form of virtualBuffers.

Even Talks (Symbian phone screen reader) now uses virtual Buffers.

Please forgive me if I'm wrong here, but isn't there some form of bridge
that can be used from Firefox to Emacspeak? if so, this to me seems very
much like virtualBuffers. No doubt the emacs buffer would  have to be
updated each time a node changed in the Gecko DOM. We both have to deal
with the same problems. However, as long as we pay attention to all
events, I can't really see a way it can get out of sync.

Many many blind users on Windows are very happy with the page model that
virtualBuffers provide. We can debate for ever whether its the most
efficient choice for a given Operating System. But at the end of the
day, blind Windows users when using a Windows screen reader come to
expect this model.

I am most certainly happy to investigate a non-virtualBuffer way for
NVDA to access web documents, if the community at large thought it was
worth it. In fact we will need to do this anyway for access to complex
editable documents in Open Office and IBM Lotus Symphony etc. Perhaps
once that work is done, then people could have the choice to use either
interface.

But, virtualBuffers were the easiest and most efficient way of giving
access to Firefox via NVDA I knew of.

Mick

Jason White wrote:

> On Sun, Jul 13, 2008 at 11:27:52AM +1000, James Teh wrote:
>> Three reasons that immediately come to mind:
>> * Although virtual buffers involve a slight rendering delay (which is
>> usually unnoticeable in our implementation now), once rendered, they
>> allow for instantaneous access to any portion of the page. One never has
>> to wait for a complex part of the document to be rendered into a
>> readable form. While I haven't personally used Orca and Firefox much, i
>> understand that there can occasionally be some delay while moving
>> throughout the page, although corrections are of course welcome.
>
> With a modern, fast machine, I haven't noticed any delays peculiar to
> Firefox.
> There are speech-related delays involving gnome-speech and eSpeak, but a
> patch
> has been circulating to correct those. Again, I haven't been able to
> reproduce
> them on my quad-core desktop system, although on my single-core laptop,
> this
> issue does become slightly noticable.
>> * Cursor navigation in a virtual buffer is similar to that of any flat
>> document. You can move by character, word, line, block, etc. Cursor
>> navigation is always symmetrical; i.e. if one moves the cursor forward
>> in a certain way, reversing those movements will always land you back
>> where you started unless the document changed during the movement.
>> Again, I don't have any real experience with Orca and Firefox, but I
>> understand that the Firefox caret is not always symmetrical in this
>> fashion.
>
> Correct, but Orca by default moves the focus to the beginning of the line
> as
> this is what users mostly desire according to the Orca developers.  With
> this
> feature switched off, my understanding is that the cursor does arrive at
> the
> same point in the document when navigational actions are reversed -
> barring
> bugs, of course.
>> * Virtual buffers allow for very fast "quick navigation"; i.e. moving to
>> headings, links and other page elements.
>
> Orca's structural navigation is very fast indeed.
>
> I think the Orca developers were right not to create virtual buffers, and
> I
> applaud this decision.
>
> this also simplifies the user interface by eliminating multiple "modes" of
> interaction.
>
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Scriptability [was Re: New: Firefox 3 with Screen Readers FAQ]

David hilbert Poehlman
In reply to this post by mozilla accessibility
I used netscape in win3.11.

----- Original Message -----
From: "Rich Caloggero" <[hidden email]>
To: "Jason White" <[hidden email]>
Cc: <[hidden email]>
Sent: Tuesday, July 15, 2008 1:08 PM
Subject: Re: Scriptability [was Re: New: Firefox 3 with Screen Readers FAQ]


In my humble opinion, the concept was "invented" purely for practical
reasons.  Must have been around 1997 when win95 was the dominant
"accessible" operating system.  IE was accessible, but you couldn't really
do much except read links by tabbing around and I think you could get the
whole page read from top to bottom. You could use the Jaws cursor to read
the document, but if there were columner text or navigation along the left
edge for instance, then text from nav links would be intermixed with page
content and things became very confusing very fast.  So, without a good
alternative (I don't think MSAA was very mature back then, especially with
respect to IE), the virtual buffer concept seemed a good approach at the
time.  Perhaps its time is past, but ultimately I don't care how the screen
reader works as long as it can do all the things necessary to support modern
web applications, which I expect is more difficult using a virtual buffered
approach.


Just my two cents.
-- Rich

----- Original Message -----
From: "Jason White" <[hidden email]>
To: <[hidden email]>
Sent: Saturday, July 12, 2008 3:15 AM
Subject: Re: Scriptability [was Re: New: Firefox 3 with Screen Readers FAQ]


On Sat, Jul 12, 2008 at 04:47:37PM +1000, James Teh wrote:
> It should also be noted that our original Gecko virtual buffer code was
> implemented entirely in Python. It wasn't anywhere near as good as the
> current solution, but it certainly had some limited useability.

I'm not a Windows user, but I'm curious anyway: why do screen readers for
that
environment implement virtual buffers for Web content? I use Orca under
Linux,
which doesn't need any virtual buffers, and this is a good thing.

Virtual buffers remind me of off-screen models and all the reasons why they
are such a bad idea, especially when client-side Javascript comes along and
changes the document via the DOM.

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
1234