Re: Potential Conflicts between Lynx & WAI P3 Standards Query

aloha, kath!

let me see if i can provide you with some answers...

KM Question 1: As Lynx already has access keys, will assigning access keys
to a page
cause potential conflicts?

GJR: no -- accesskeys will simply be transparent to lynx users...  a few
points of clarification:

1) lynx doesn't currently support "accesskey", as defined at:
http://www.w3.org/TR/html401/interact/forms.html#h-17.11.2

2) lynx's keybindings can be reassigned by the user by editing a plain text
file;

3) to obtain a list of the currently active keybindings, type a 'k' -- and
type an 'h' to get 'help' on using and reassigning keystrokes/keybindings...

note, too, that Opera (www.opera.com) also boasts a rich keyboard interface
(although no support for "accesskey" that i'm aware of) enabling a lot of
on-the-fly control and single-key functionality

KM Question 2: The title attribute of a href, for example, doesn't seem to
do anything
in Lynx? Is it required in Lynx - and which browsers is it recognised in?

GJR: the "title" is used by Lynx when displaying a list of links (by
default, typing an 'l' will generate the list of links...  caveat/bug: the
"title" defined for internal (this-page) links  and for (some, if not most)
partial references (a link to an anchor in a page) are rather annoyingly
rendered (at least by default) in the lynx-generated list of links in the
following manner, even if a "title" has been defined for the link:

form:
  in [TITLE of document] - ['name' value for link]
example:
  in Blindness-Related Resources - orgs

note: while the contents of the "title" attribute is often exposed as a
ToolTip in GUI interfaces, although some (such as Opera) offer options as to
where to expose the contents of the "title" attribute

as for accesskey support, i know it to be supported in:

1. MSIE for Windows: versions 4x and 5x (works differently in 4x and 5x!)
2. MSIE for the Mac: version 5 (i believe--miraz, help me here!)
3. iCab (Mac): http://www.icab.de/info.html
4. Amaya: ??? (i wish i knew--Amaya _still_ doesn't communicate
properly/consistently with my screenreader)

KM Question 3: Navigation - We have been developing a method of working that
included using
invisible images as anchor links within the page so that visually impaired
users can
easily bypass navigation and go straight to the content of a page. As the
user can use built in keys in Lynx to move around the page we are again
concerned about potential conflicts.

GJR: i'm not sure i understand the concern...  lynx must, perforce, offer
more scrolling/navigational keystrokes than a GUI browser because it doesn't
have a scrollbar mechanism, hence the advance-2-lines and go-back-2-lines
commands, as well as the next/last screenfull go-to-beginning and go-to-end
and advance/retreat half-a-page keybindings, to name but a few...  the
exception to this rule is Opera, whose keyboard interface is extremely
robust...

actually, as has been well documented on the WAI-IG list and elsewhere --
consult, for example:
http://lists.w3.org/Archives/Public/w3c-wai-ig/1999OctDec/0725.html -- there
is a far greater potential for key conflicts when accesskey is being invoked
in a GUI environment...  MSIE, for example, supports accesskey, but uses the
ALT key as the triggering mechanism (you have to hold down ALT whilst typing
the accesskey in order to invoke it in IE), which leads to conflicts with
IE's user interface, since the means of invoking/opening menus in the
windows environment is to use ALT as a modifier/trigger key...  for
examples, try the accesskey test pages located at:
http://www.w3.org/WAI/GL/tests/accesskey1.html
http://www.w3.org/WAI/GL/tests/accesskey3.html

as for use of an invisible image to provide transparent aurally/tactilely
oriented information, i'd suggest (a) reading the recent thread on this
topic archived in the wai-xtech mailing list's archive, which starts at:
http://lists.w3.org/Archives/Public/wai-xtech/2001Jun/0001.html

KM Question 4: Spacer Images - We have been following the RNIBs advice on
spacer images and using * as the alt tag. However it appears that the page
is easier to read in Lynx if the alt tag is left blank for spacer images,
which method should we use?

GJR: i think you may have misunderstood RNIB's advice -- use null ALT text
(ALT="") for spacer images and ALT="*" for graphical bullets, list item
indicators, etc., so that the user isn't forced to hear:

[bullet: rotating homer simpson head] Visit Springfield!
  [bullet: funky multi-colored rotating disco ball] Disco Stu's Party Palace
  [bullet: funky multi-colored rotating disco ball] Moe's Tavern
  [bullet: funky multi-colored rotating disco ball] Stoner's Pot Palace

as the result of overly literal descriptions of purely decorative
elements -- sure, it's cool to know that the bullet defined for the DT in
the DL mock-rendered above is a rotating head of homer simpson, but since
i've never seen homer simpson's head, and since the point of using his
rotating head is to indicate an item in a list, using ALT="*" for the
graphic of homer's rotating head, and ALT="+" for the funky rotating disco
ball graphic (a) makes the page more readily comprehensible by someone
browsing without support for/need for/desire for images; (b) reduces the
cognitive load on the visitor; and (c) is a true textual equivalent for the
graphic used as a list item indicator -- of course, if you believe in full
disclosure, you could always describe the graphics using the "longdesc"
attribute...  for an example of this sort of literalism in the wild (and at
a site which should know better) consult www.rfbd.org, which, as of this
writing, not only has inaccessible javascripted "extended/pop-up"
navigational menus (with no true equivalent/replication of the content of
the javascripted sub-menus), but blocks of text preceded by a graphic whose
ALT text is repeatedly defined as "The RFB&D headphone logo", when
ALT="*" would have been far more appropriate and user-friendly

KM Question 5: HTTPS and Secure Sockets - We have been developing a online
donation product which we have endeavoured to make accessible to Priority 1.
When we came to test the site we
found that we couldn't open it in Lynx.

GJR: lynx can be made to support HTTPS -- refer to:
     http://lynx.isc.org/release/ssl.html
and  http://lynx.isc.org/current/README.ssl
for detailed information on Lynx & HTTPS/secure sockets...  for users using
Lynx32, the 32-bit windows port of Lynx, this is more problematic, as the
windows version of Lynx comes pre-compiled, which means that it isn't easy
to patch...  a few work-arounds: contact one of the people involved in
porting Lynx to the 32-bit windows platform and ask them to compile an
SSL-enabled version of Lynx for distribution via floppy -- the reason Lynx
doesn't "ship" with SSL support are restrictive encryption laws, which
wouldn't impact an effort to distribute an SSL-enabled version of Lynx32 via
floppy, for example, as long as you didn't directly export the floppies!
another strategy is to offer a SSL-enabled Lynx through a telnet session, in
the same manner that public versions of lynx are made available
http://www.hicom.net/~oedipus/weave.html#telnet
or to set up a proxy server which would enable SSL-support for lynx users...

the main distribution points for Lynx32 are:
1. http://www.shonai-cit.ac.jp/eci/senshu/ - excellent and up-to-date ports
of the latest Lynx build; unfortunately for those who don't comprehend
japanese (a classification that includes my screen-reader), all the info on
the download page is in japanese, although the link text is in english;
which is really unfortunate, as i believe this site is now (and i hope my
publicizing this doesn't put an end to it) either distributing a Win32 port
of Lynx with SSL support or instructing users how to provide SSL support for
the Lynx32 port -- the informational file is in japanese, and when i
attempted to run it through a translation engine, the output was nearly as
incomprehensible as the original -- hopefully, someone on this list who
speaks/reads/understands japanese (perhaps someone from Keio?) can provide a
synopsis of the information contained in:
http://www.shonai-cit.ac.jp/eci/senshu/lynx_upd.txt
(by the way, anyone know of a good, reliable, free
japanese-to-english/english-to-japanese translation engine?)

2. http://www.fdisk.com/doslynx/lynxport.htm - various Lynx ports (for DOS
as well as Win32) from the "father of Lynx32", wayne buttles, as well as
links to other Lynx ports

3. http://www.jim.spath.com/lynx_win32/ - a lynx-port built using Borland

i hope this answered your questions -- please feel free to ask for further
clarification on any of the points raised herein or any other issues you
have about lynx

gregory
--------------------------------------------------------------------
IMPARTIAL, adj. Unable to perceive any promise of personal advantage
from espousing either side of a controversy or adopting either of
two conflicting opinions.   Ambrose Bierce, _The Devil's Dictionary_
--------------------------------------------------------------------
              Gregory J. Rosmaita, oedipus@hicom.net
          Camera Obscura: http://www.hicom.net/~oedipus/
     VICUG NYC: http://www.hicom.net/~oedipus/vicug/index.html
  Read 'Em & Speak: http://www.hicom.net/~oedipus/books/index.html
--------------------------------------------------------------------

Received on Wednesday, 6 June 2001 13:43:41 UTC