Re: Mozilla - like JAWS or like Hal?

[Peter Korn <Peter Korn Sun COM>]

Hello everyone,

I'm delighted with this discussion - it's getting a lot of good ideas out of 
the woodwork.  I have three additional requests!

 1. Please crosspost this discussion to <mozilla-accessibility mozilla org>,
    which is the Mozilla accessibility community.  Not everyone working
    on mozilla accessibility is involved in the UNIX & GNU/Linux aspects of
    it, and some of the suggestions have bearing on Windows & Macintosh users
    as well.

 2. In addition to your suggestions, think about how to implement them; and
    for the programmers out there, consider submitting patches to the mozilla
    or gnopernicus code bases (or both) to implement the features you would
    like to have.  This is an open source, community effort; contributions of
    patches are most welcome!

 3. Now that we've started a good discussion about what is needed for good
    blind access to mozilla, perhaps we can start similar discussions about
    other aspects of the desktop.  Here are some questions to get that
    started (this further discussion shouldn't be cross-posted to
    <mozilla-accessibility mozilla org> of course...):
     a. What is good, and what can be improved, in Gnopernicus access to
        Nautilus and the actual desktop window itself?
     b. Same question, but about Gnopernicus and gaim?
     c. Same question, but about Gnopernicus and StarOffice/OpenOffice.org?
     d. What do you think about the Gnopernicus features?  The Gnopernicus
        NumPad commands and layer concept?  Braille interface?
     e. What TTS engine(s) do you use with Gnoperncus?
     f. What are the most important things you want to use with Gnopernicus
        but cannot use yet?


Regards,

Peter Korn
Sun Accessibility team


Janina Sajka wrote:
> This is a fine summation of what has become the expected behavior of browsers under the Windows GUI. However, I am not so sure I would jump to the conclusion that it's the way browsing should work for everyone. Those seem two separate issues to me.
>
> A few examples:
>
> I find the business of marking links "visited" anoying, especially when the information precedes (rather than follows) the link text. First of all it inhibits a smooth read of content. Second, and perhaps more important, it takes time. Uttering the words "visited link" requires four separate syllables. To top it off, it's not actionable information like the numbering of links is in the Lynx (the cat) browser. You still have to tab to activate--unlike the cat where you can simply type the number and press enter.
>
> To my mind a far better way to proceed toward defining useful accessibility features is to canvas successful strategies from both GUI and console environments--then to allow for their use through UA configuration. If you want visited links, you should be able to turn them on--but I should be able to turn them off. And, why not borrow the numbering strategy still available in the cat (and the chain)? What's wrong with that?
>
> Saqib Shaikh writes:
>
> > Hi
> >
> > I ve been following the thread regarding Mozilla 1.7 RC1 acccessibility.
> > I'd like to make some comments based upon my experience with two Windows
> > screen readers - JAWS and Hal.
> >
> > JAWS effectively textualises the screen: it inserts the word "link" or
> > "visited link" into the text of its virtual buffer, and also inserts words
> > like "list of x items" or "table with x columsn and y rows".  If you copy
> > and paste from JAWS into a text editor you'll get this textual
> > representation.
> >
> > In contrast Hal takes the approach of leaving the screen just the way it is,
> > and reading what is actually there.  It has a virtual focus mode, but this
> > is more like a reinterpretation of the graphical screen, not a textual
> > replacement.
> >
> > Likewise in Mozilla's text browsing mode I'd like links to be coloured and
> > underlined, but no word "link".  Likewise Headings should be bold or
> > whatever, and tables/lists/frames should look like what they are.  So what
> > we have is a version of the main page, but with the ability to cursor up and
> > down, select text with the keyboard, do text finds within the document, and
> > also maybe have a list of links/headings/frames appear at the press of a
> > keystroke.  This is all quite general functionality that is acceptable IMHO
> > in a text browsing mode, but which doesn't make it a screen reader only
> > browsing mode.
> >
> > Then Gnopernicus should be given enough semantic knowledge of the document
> > that when it comes across a link it should know whether it is a visited link
> > or not, and when inside a table, even though Mozilla's table navigation
> > commands will be used, Gnopernicus should represent the table in
> > speech/braillle in the appropriate fashion.
> >
> > I think this is the best way to present this UI, but would appreciate any
> > comments.
> >
> > Saqib
> >
> >
> > _______________________________________________
> > gnome-accessibility-list mailing list
> > gnome-accessibility-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list