Re: [orca-list] Page presentation issues



am Fr 16. Mai 2008 um 11:57:46 schrieb Jason White <jason jasonjgw net>:
On Fri, May 16, 2008 at 07:28:27PM +1000, Daniel Dalton wrote:
 
Would writing the navigation functions for orca in c help? (Is python 
causing the slowness?) Or is it not related to that?


It would increase performance to some extent, but slow down development a lot.
Python code, in general, is much shorter than the corresponding C code,
less prone to bugs (e.g., memory allocation problems) and quicker to develop.
 
I'm no programmer, but I've read statements telling the exact opposit.

Let's state it this way: the Orca developers aren't going to rewrite the
Firefox support in C, and they are right in not doing so. This discussion has
been held before on the mailing list; perhaps consulting the archive would
help if you are interested.
  
Rewriting Orca's code in C would not affect Firefox only, it would mean 
redeveloping the whole stuff.
But from my experience with Windows screen readers I think a program 
written in C or C++ is much faster; scripting is used for the fine tuning. 
But I agree that this are yesterday's decissions, and a real comparism 
only could be made if a competetive solution would exist, completely 
written in C or C++.

Which is better than the windows buffering I think I have seen in internet 
explorer.
(I hardly ever use windows so that is why I didn't notice the speed thing)


I don't notice any performance problems in Firefox.

But I do, and I would suggest trying out Windows more extensively before 
judging.

Is there any hope of implementing a links list dialog?

I think the majority of the community rejects such suggestions.

Why not a hotkey to put the links into a list view or whatever so you can 
down arrow through links (same with forms, and perhaps objects) but when 
these lists are not active show the page as it looks. (Like it is shown 
now.) (Don't invent this buffering stuff)

This sort of manipulation is best implemented as a Firefox extension so that
it can be used regardless of what screen reader happens to be operative, and
can also be used by people who aren't accessing Firefox with a screen reader,
but who may find a list of links, a list of headings, etc., helpful.
 
Sorry, but I don't see why this is needed. To read the screen is the job of 
a screen reader, and why should one install such extensions to do a 
job that one program can do?
And BTW.: It is no solution for FF3, since these extensions become 
incompatible after every new step of development. I used this extension for 
a while, and one day FF deactivated it for compatibility reasons.
In addition: Lots of hot keys collide with the structural navigation of 
Orca.

This sort of functionality should not be in Orca. It should be a firefox
extension, I would argue.
 
No, see above.

A much more powerful and valuable solution is provided by the Axsjax software,
written by Charles Chen and T.V. Raman at Google. It is written entirely in
Javascript and modifies Web pages to improve accessibility as they are loaded
into the browser. To activate Axsjax you can use bookmarks or the Greasemonkey
Firefox extension.

Axsjax modules have been written for various Google applications as well as
several other Web sites. It would be easy for Javascript developers interested
in accessibility to implement more features and to extend this approach
further.
 
I think this makes everything more complicated, since one has to look for 
such a solution for every website.
I think a common user is interested in keeping things simple and easy to 
handle, and stuff like this makes all more and more dificault.
So my conclusion is that either the screen reader should do the accessible 
presentation of websites, or a webtool should be developped that presents 
webpages in an accessible form, independent from the screen reader one 
uses. Such webtools exist for Windows:
http://www.webformator.com/
http://www.webbie.org.uk/
Hermann



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]