RE: accesskey

On Monday, December 27, 1999 5:18 PM, Eric Eldred [SMTP:eldred@mediaone.net] 
wrote:
> David Wagner wrote:
> >
> ...
> > I think an accesskey to switch among alternate stylesheets is a good idea.
> >  Why?  Well, one can make an alternate stylesheet to show only the heading
> > levels, and it would be a view of the table of contents.  You may have one
> > stylesheet for editing, showing the content of all the INS and DEL 
elements,
> >
> > and another for viewing what will be the final document.  Of course,
> > choosing
> > the print medium stylsheet will give you a print preview, something not all
> > browsers do.  Having a quick key to switch among these is a good thing,
> > whether
> > there is a navigational element shown or not.
>
> but how does the user know which accesskey to
> press to switch stylesheets?
I would let users know (perhaps in a help file) what these shortcut keys are. 
 My pages are often already crowded with information.  If I have a good useful 
document available in different styles for various media and accessibility 
requirements, with a few translations available, and part of a set of documents 
in a collection (with prev/next/chapter/toc/index/glossary/bibliography... 
links), I would need dozens of Anchors on every page to display all these 
choices.  My thinking is I have a help file explaining the standard keys used 
to access these common LINKs from any given page.
>
> i think the idea behind ACCESSKEY was to put
> in the user's display some indication just
> before a link, that retrieving the link is as
> easy as pressing that key (or maybe in
> combination with CTRL or ALT or CLOVERLEAF.)
> for example, as Lynx does, the octothorpe
> before the nav bar at the top of the page.
>
> this could work easily with A ANCHORS, but
> i don't see how it would work with LINKS
> in the HEAD element that are not displayed.
>
> it might work for nav bars LINKS, if they
> were displayed the same as Lynx, but there
> is still a complication in that the big 2
> browsers don't support that.  adding the
> "feature" to enable accesskeys for all links
> would seem to me backwards incompatible.
I had been crossing my fingers the big 2 would display LINKs as appropriate for 
the operating system, as menu items, toolbar buttons, voice prompt, or such. 
 The MSIE 4/5 "Links" toolbar at first glance looked like it would do so. 
 Capturing the ACCESSKEY behavior fo LINKs would, as you point out, probably 
not work in current browsers.
>
> on the other hand, if the user agent displays
> the HEAD LINKS at the top of the page with
> optional ACCESSKEYS to switch stylesheets
> and so on, then adding the ACCESSKEY to LINK
> would be easy and useful.  but it would be
> redundant, since placing the LINK in the
> HEAD is an alternative to an ANCHOR in the
> displayed text, implying non-visibility in
> the display.  once it is visible in the
> display it is really the same as an ANCHOR
> and so the ACCESSKEY in an ANCHOR is already
> allowed.  a page author can just write for
> ANCHORS instead of LINKS if that is the
> desired behavior.
I agree.  LINKs in the HEAD should not be displayed on the page.  But I don't 
think page authors can tie stylesheets in with A elements without scripting the 
behavior to override the browser's normal processing.
>
> as an alternative, the behavior of Lynx
> might be something different that other
> browsers might wish to copy.  a global
> option in Lynx is to have all links preceded
> by a number.  this shows on the display and
> works quite the same as ACCESSKEY except that
> one enters a number instead of pressing a
> key.
>
> there was a suggestion a month or two ago
> here that ID (for example for an H1 element)
> have the semantics of TABINDEX--thus the
> next TAB in order would be indicated by
> that attribute of an element, instead of
> by TABINDEX.  nobody commented on that,
> but i think it wouldn't work because an
> ID attribute value should not begin with
> a digit, while the TABINDEX attribute value
> is supposed to be an integer.  and ID and
> TABINDEX have different purposes that should
> not be confused.
>
> but allowing ACCESSKEY to be an integer
> instead of or as well as a key would
> allow a new browser to mimic the behavior
> of Lynx, maintain backwards compatibility,
> and also provide some usefulness for user
> agents for accessibility.  if that is not
> desired, then making visible the HEAD LINKS for
> navigation, with TABINDEX allowed as
> an attribute, would also be good.  then
> Lynx could change from ID to TABINDEX for
> its tabbing order, and MSIE change from NAME to
> TABINDEX.  but likely this will be opposed
> because of backwards compatibility concerns?
MSIE 5 allows accesskey="5" [Alt-5] or whatever digit you like.  I agree to the 
need to keep ACEESKEY, TABINDEX, and especially ID attributes seperate, and 
could not possibly live with a limit of 10 links on each page. (See above.)
>
> and as far as LINKS in HEAD that are not
> nav bars, the user agent would have to add
> code to do something once the LINK is
> selected.  as for example, switch to another
> language (on a new page).  but without a
> prompt, this would be hard to implement.
> wouldn't it be better in that case just to
> try to do it with ANCHOR in the visible page?
I don't think it would be that difficult to program a toolbar displaying LINKs 
in MSIE5; there are plenty of similar custom toolbars around, and MSIE 4/5 
looks like it will even support entire stylesheet changes and additions as well 
as simple navigation.

I guess what I am getting at is there are many useful little things, relatively 
easy to implement, to put on pages especially when each page forms part of a 
larger work.  Many of these things would be very useful for only a few users, 
but I really can't clutter the 640x480 screens of the many for benefit of the 
few.  However, I really want to make my work shine for every user, and having a 
bunch of magic keys available seems like a good way to do this.

Received on Thursday, 30 December 1999 17:10:09 UTC