Re: Mozilla - like JAWS or like Hal?

["Tom and Esther Ward" <tward1978 earthlink net>]

Hi, Janina.
You bring up some good points, but at some point one would have to work on
the assumption that the table was written correctly, and that the format is
pretty standard. I know that that doesn't settle well with most people, but
I am not sure how Mozilla/Gnopernicus could handle incorrect tagging. As you
said it would probably be some limitations to a smart table approach.
However, one thing that also needs be done in Mozilla is a special set of
hot keys for jumping to row and column. It is difficult in most web browsers
for a blind end user to get to a specific portion of a table quickly.

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


> Tom, you are very correct about tables. Just to be clear, I think we need
to know more than what row and column. We really need the label for
each--the column header and the row label. I suppose a smart interface would
announce this once and then announce only the one that changes as one
navigates the table. I do think, by the way, that we'd prefer to navigate
around in tables. So, if it's left and right movement across a single row,
then the new column header and cell contents should be read as each new cell
gains focus.
>
> Problem is, though, how do you distinguish real tables from the rather
ubiquitous use of table tags to force layout? And, which cells contain the
labels in those cases when the HTML is improperly tagged? Are these the
limits of a smart tables approach?
>
> Tom and Esther Ward writes:
> > 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
>
> --
>
> Janina Sajka, Director
> Technology Research and Development
> Governmental Relations Group
> American Foundation for the Blind (AFB)
>
> Email: janina afb net Phone: (202) 408-8175