Re: Mozilla - like JAWS or like Hal?

["Tom Masterson" <kd7cyu yahoo com>]

THis is where customization comes in. :)

I hate the numbering of links in lynx and turn it off as quickly as possible
if it is on.  As for whether a link has been visited or not once again I
don't care and my windows stuff is set up not to tell me any more than that
it is a link and that normally just by highlighting/underlining it.  I would
like some ability to work better with tables.  Sometimes I want them
linearized and sometimes I want to see them in their natural state,
especailly when doing a page layout.

Tom
----- 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: Tuesday, May 04, 2004 23:32
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
>