Re: Mozilla - like JAWS or like Hal?

["david poehlman" <poehlman1 comcast net>]

I may have mentioned this before, but audio styling can help here for folk
with sound cards and perhaps some braille styling as well.  Instead of
having the word visitted something short and meaningfull could be insertable
and chooseable.

----- Original Message ----- 
From: "Tom and Esther Ward" <tward1978 earthlink net>
To: "Janina Sajka" <janina rednote net>
Cc: <gnome-accessibility-list gnome org>;
<mozilla-accessibility mozilla org>
Sent: Wednesday, May 05, 2004 2:32 AM
Subject: Re: Mozilla - like JAWS or like Hal?


Hi.
I think janina is correct. The numbering links option found in lynx is
perhaps one of the best accessibility aids in a web browser. It allows for
quick navigation through web pages.
Another point Janina mentioned is web browsers in Windows tend to announce
visited link before stating the link. If a visited link message is to be put
in the program it should come at the end so that the end user can hear what
link has focus.
The main feature I would like to see is good table navigation, and to have
spoken feedback on what row and column I am in when carot browsing is on.


----- Original Message -----
From: "Janina Sajka" <janina rednote net>
To: "Saqib Shaikh" <me saqibshaikh com>
Cc: <gnome-accessibility-list gnome org>
Sent: Tuesday, May 04, 2004 5:24 PM
Subject: Re: Mozilla - like JAWS or like Hal?


> 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
>
> --
>
> Janina Sajka, Director
> Technology Research and Development
> Governmental Relations Group
> American Foundation for the Blind (AFB)
>
> Email: janina afb net Phone: (202) 408-8175
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list