[nvda] Re: Fw: NVDA and Firefox

Hello,
I was just testing support for firefox with rev 316 and comparing it to e.g. how jaws support is is nearly at the same level for me. of course there are limitations you have posted about. That inconsistency when using tab to change focus instead of arrowing happens very randomly in here too. I have got little suggestion to the virtual buffers in general I think. Would it be possible to make NVDA speak type of page element after it's text is spoken? It works this way in internet explorer so it's why I believe it's more general thing. to be more precise when tabbing over the links NVDA is saying link and it's text. I think it would be nice if this could be reversed to the text following by the word link. Please excuse if that has already been discussed I am slowly reading some archives but I was not able to see all the postings yet. 

PV


Michael Curran  wrote:

Hi all,
The status of NVDA support for Firefox was asked about on the dev accessibility mozilla list, and I thought I would forward my responce.
It gives quite a clear overview of the support NVDA currently has for Firefox, and I hope that people on this list might be able to do some more testing and see how it can be improved more. 

Mick

----- Original Message ----- From: "Michael Curran" <mick@xxxxxxxxxx>
To: <dev-accessibility@xxxxxxxxxxxxxxxxx>
Sent: Saturday, January 27, 2007 10:02 PM
Subject: Re: NVDA and Firefox



Hi Aaron and all,

[Tried sending this message before but I don't think it got through]
I can give a summary here of how NVDA supports Firefox, but I think it might be better if someone else updates the AT support wiki since I am the core developer of NVDA and apart from it looking a little dojy, I may be quite biased as to how well NVDA works, and what bugs there are etc. 

NVDA can be found at:
http://www.kulgan.net/nvda/
Following is a description of the features and bugs of NVDA supporting Firefox (from my point of view): 

Document Rendering
When NVDA finds a Mozilla Gecko document either with focus, or is in a direct ansestral line with the current focus, NVDA Traverses the document structure, rendering the document in a virtual buffer. (This is rather much like Jaws, Window Eyes and other screen readers).
The buffer is made up of lines of text, however there are fields overlayed which represent links, headings, tables, paragraphs, form fields, block quotes and lists etc. These fields are announced when arrowing on to them (in the case of links, headings, graphics, form fields etc) and announced when moving in and out of them (in the case of lists, tables, paragraphs and block quotes etc).
Bullets and numbering are also rendered, though like fields, these are only announced when moving in to list items, they are not actually physically written in to the buffer as text.
I have not yet come up with any way of splitting table cells in to rows, but you can configure NVDA at least to announce when moving in and out of cells, and of course entire tables.
I have not yet got around to adding any summary or caption info to tables.
NVDA can distinguish between links and visited links, though I have not yet labeled same-page links different to links; I guess I will have to look at the value and work out if its pointing to an ID.
NVDA takes care to render text so that it is not broken up just because it comes from a different object than the one beefore it. In general, when a text node is added, a newline char is also added. However, if it is detected that a text node is being added right after another text node, then they are murged and no newline char is added. This to make sure that code like: 
<p>Hello, my name is <strong>Michael Curran</strong></p>
is not broken up.
NVDA also wraps lines at a user-configurable length, so that really long paragraphs do not end up all on one line.
Flash and other plugin windows are not supported by NVDA, in fact 'embed' objects are currently not being traversed at all since NVDA ends up getting in to an infinit loop.
Of course shortcut keys are also announced for objects that have them, and Frames and IFrames seem to all work fine.
Because NVDA is written in Python, the rendering of documents is perhaps a bit slower than it should be. When rendering www.google.com (the classic version) it renders easily in half a second. For www.anz.com, it renders in just on 3 seconds. However for some really large documents such as Wikis like www.wikipedia.com it can take more than 5 seconds.
I would really like to cut down this time, but after optimising things for the last month or so, I have improved it from what it was. If anyone has any suggestions on how to make it faster, I would love to hear from you. I am sure it can be faster; origionally www.anz.com was 8 seconds, but I have got it down to 3 now.
On the other hand, once the document is rendered, arrowing around the text and fields is as snappy as you would ever want it to be.
Font and color info can not yet be stored in the buffer as I still have no way of accessing any of the Mozilla DOM interfaces such as ISimpleDomNode etc. This is due to the IDL files not compiling in to a typelib (.tlb file) for use with Python and comtypes. 

Dynamic content
The virtual buffers are completely dynamic in that content can be removed and inserted easily with out disterbing any of the content around it. This means that pages such as the accessible ajax demos at: 
http://accessibleajax.clcworld.net/
Work quite well. The scoreboard updates its values fine, the chat demo keeps the list of the last 10 chat log lines up to date, and the Signup form shows and hides the form validation error messages fine.
Note though that the most current Firefox 3 alpha seems not to be firing event_reorder events for javascript updates at the moment, but Firefox 2 seems to be doing it fine. 

Updating of form field content also works fine (typing in
an edit field still keeps the buffer up to date).
Even though the buffer is being dynamically updated, I am unable to find out live region info so that NVDA can announce updates as marked in the source. This is again because I don't have access to anything else than MSAA. Of course once IAccessible2 is implemented, hopefully all this will change. 

Tabbing and hot key navigation
Wen the focus moves due to tabbing through links etc, NVDA reports the content at the place of the new object with focus in the buffer. Rather than just reporting the MSAA object directly, it uses the fields and text in the buffer at this point to make sure that the user hears the same thing when tabbing or arrowing. Also if the object has a 'labeled by' relation, NVDA will announce the content at the label place before the actual object with focus.
NVDA has keys such as h for heading,, p for paragraph, f for form field, l for list, k for link etc that can jump to the next field of this type in the buffer. Adding the shift key with the letter searches for the previous field instead. 

Object interaction
When on a particular field in the buffer, you can press space or enter to activate it. For most things this means executing 'doDefaultAction' on that object, but for edit fields, this gives focus to the object (with accSelect) and turns on virtualBuffer pass-through mode, so that the keys now go straight through the virtualBuffer to the object that was chosen.
This mode can be exited either by pressing insert+space, or it will be automatically turned off the next time a page load happens.
However, I have noticed that sometimes Firefox's tabbing order can get a bit stuffed up if I arrow on to an edit field and I press enter to give focus to it, if I then press tab, its sort of like I was really back at where I origionally was in the tab order because the next object that gets focus is the object after the origional object, rather than the object after the edit field. I do know the edit field is definitly getting focus, because NVDA sees an event_object_focus, and I am able to successfully type in to the edit field. However this problem does not always happen, and I can not yet work out a real pattern as to when it happens.
Check boxes and radio buttons get activated as you would expect, and their new state is announced. Comboboxes are accessible, but there is one problem where after selecting an item, the whole virtualBuffer gets rendered again. I am not sure if this is bad code on my part, or if there is an event from Gecko that shouldn't be there.
Arrowing around edit fields is not at all accessible at the moment, since there is no way to find out the caret's position just using MSAA.
NVDA uses beeps to notify the user of progress bar changes, and this seems to work fine in Firefox when loading a page etc.
NVDA also currently beeps each time there is an event_reorder received for debugging purposes. This can be annoying when typing in to edit fields, but for now it is necessary until edit fields can become properly accessible, and until I have access to the live attributes of markup.
I hope I have covered everything here, please feel free to ask any questions on anything I have missed.
I would urge any other blind Firefox users on this list to test NVDA if they have the time, so any bugs can be sorted out, and so we can find out if NVDA is up to scratch with Firefox Accessibility. 

Mick



_______________________________________________
dev-accessibility mailing list
dev-accessibility@xxxxxxxxxxxxxxxxx
https://lists.mozilla.org/listinfo/dev-accessibility



To post messages to the list send email to
nvda@xxxxxxxxxxxxx
To unsubscribe from the list send a blank message to:
nvda-request@xxxxxxxxxxxxx
with 'unsubscribe' in the Subject field.
Thank you for your continued support of Nonvisual Desktop Access, an open source free screen reader for Microsoft Windows: 
http://www.kulgan.net/nvda/



To post messages to the list send email to
nvda@xxxxxxxxxxxxx
To unsubscribe from the list send a blank message to:
nvda-request@xxxxxxxxxxxxx
with 'unsubscribe' in the Subject field.
Thank you for your continued support of Nonvisual Desktop Access, an open 
source free screen reader for Microsoft Windows:
http://www.kulgan.net/nvda/

Other related posts: