Re: archive: example message page with long titles

aloha, kelly!

while your observations are on-point, i think that your conclusions miss the
point...  what you reported -- the difference between what was intended and
what was experienced -- is the type of feedback that AT developers need to
hear: that their support for the markup is insufficient, and that their
extant implementations need tweaking.

yes, there are sometimes problems in what users of JFW 3.x hear on a
"properly" marked-up page, but faulty implementation on the part of specific
ATs shouldn't be the force that drives our discussions...  and, while the
onus lies squarely on the shoulders of any AT developer and mainstream UA
developers, it's up to us, as individuals and members of larger (presumably
more influential) entities, to get them to implement to spec, so as to break
the vicious circle in which AT developers blame mainstream developers,
mainstream developers ask "where's the demand?", and authors respond to our
efforts with a quote yes, that's all fine and good, and your efforts are
noble, but when something implements this particular feature or supports
such-and-such attribute, _then_ we'll code to it - otherwise, why bother?
what's the point - political correctness? unquote

if, to get technology specific for a moment, JFW can't get the requisite
information from the proprietary DOM implemented by microsoft in MSIE, then
microsoft should be called to task...  and, it should be pointed out to all
involved (to get provincial for a moment) that in order to comply with
section 508, someone bloody well better start supporting the "accessibility
features of the markup languages" which federally-purchased user agents and
authoring tools support.  hence, the path to be traveled is this: the
company formerly known as henter-joyce should be asked why they do not
support a toggle which would allow the user to switch between "speak
hyperlink text", "speak alt text" and "speak title text" - something which
i've already done on a number of occasions - if
the-company-formerly-known-as-henter-joyce claims they can't get the
information from the IE-DOM, then microsoft must be approached and asked if
the requisite information is available from the IE-DOM - and, if so, how it
can be addressed/called, and if not, why not?

we can't just sit back and wait for this to happen -- we, the users of the
technology need to bring pressure to bear on the responsible parties, which
is why adherence to standards, particularly by the W3C, is crucial -- if W3C
doesn't implement the accessibility features of the markup language who
will?  and, when said accessibility features are implemented, they need to
be, and i can't stress this strongly enough, implemented AS INTENDED BY THE
MARKUP LANGUAGE AND NOT DICTATED BY THE LIMITATIONS OF CURRENT TECHNOLOGY,
ESPECIALLY WHEN THE DEVELOPERS OF SAID TECHNOLOGY HAVE BEEN TOLD OF THE
SHORT-COMINGS OF THEIR IMPLEMENTATIONS

sorry for shouting, but i'm sick and tired of exchanging advice on how to
tailor one's markup to cater to or make up for the short-comings of a
particular AT, no matter how much of a stranglehold that particular AT may
have on a "niche" market - THAT is what i'd call proprietary markup...
what's the difference between coding to JFW's aural output, and tailoring
one's coding to browser X?  that's the path that leads down the road to the
evolutionary cul-de-sac where the OBJECT element dwells...

the "title" attribute isn't "broken" simply because JFW doesn't offer users
the ability to switch between "speak hyperlink text", "speak title", and
"speak alt (if graphic)"...  moreover, the user's ability to toggle between
these three states must not be limited to a configuration option -- it must
be available both on-the-fly and as a "display" option in a list-of-links,
as there are many scenarios in which a user might want to query a link to
discern all three bits of information (the actual hyperlink text, text
contained in "title", and the "alt" text associated with a graphic which is
used as a link) -- one such scenario is thumbnailed further on in this
missive.

why should "title" appear before "alt" in the cascade?  simply because the
purpose of "title" is to convey information about the element to a user,
while the SOLE purpose of "alt" is to provide a brief description/textual
equivalent of the image with which it is associated -- in the case of a
magnifying glass used to iconically symbolize a link to a search interface,
the correct alt text would be "a magnifying glass" and NOT "Search" - that
is the appropriate "title" text for the link, as it is the link (to which
the "title" attribute should be appended) that provides the link to the
search functionality, not the image of the magnifying glass -- that is
merely quote graphically defined hyperlink text unquote - no matter what it
links to, it is an image of a magnifying glass, so it should be alt-texted
"magnifying glass" or (less informative, but equally accurate, provided the
same exact icon is used whenever a link within the site that points to the
search facility is defined as a graphical hyperlink) "search icon".  the
"thing" that "does the linking" is the link (the A element in combination
with the "href" attribute), so when a graphic is used as hyperlink text, the
"title" defined for the link should contain orientational information about
the link, which in this case would be "Search"

take the following "real life" example, drawn from the navigational sidebar
of:
<http://www.whitehouse.gov/news/freedominitiative/freedominitiative.html>

<A HREF="/"><IMG SRC="/images/whlogo-big-stripe.gif"
WIDTH="124" HEIGHT="85"
ALT="White House Logo" BORDER="0"></A>

now, there ain't nothing wrong with that "alt" text -- i showed someone the
graphic, and, indeed, it contains the white house logo...  fine and good,
but does the link lead to the white house logo?  does it lead to a
description of the white house logo?  no, it leads to the white house's
home/front page, which is why the link should have a "title" defined for it,
such as: "Welcome to the White House" (the TITLE of the referenced page);
"The White House" (common sensical); or, "Official White House Web Site" (a
bit stuffy, but authoritative)

as regards "regular plain old text hyperlinks", the "title" attribute allows
the author a means of describing the function/purpose of the link, usually
with more detail than that contained in the hyperlink text defined for the
link, since that allows authors more flexibility when attempting to
gracefully and naturally integrate hyperlink text into the surrounding
prose, whilst still providing text that can, in isolation, sufficiently
communicate the function/purpose/destination/special features of the link.
note, too, that "in isolation" doesn't just mean "in a list of links" --
when one considers a single word which serves as a hyperlink and which is
embedded in a paragraph of text, that for many, constitutes "viewing the
hyperlink text in isolation" -- an isolation which can be broken (as
jonathan, i'm sure would attest) via a windows-type tooltip which reveals
the contents of the "title" defined for the hyperlink.

so, until it is possible, via either the UA's or the AT's interface, to
query an element and obtain from it any (or all) of the conditional content
defined for it by an author, such functionality remains both a blessing and
a curse...  a blessing in that the ability to describe or annotate a link
using the "title" attribute allows the author to more gracefully and easily
incorporate hyperlink text into the surrounding prose, while providing a
means to convey orientational/contextual information when the hyperlink is
included in a list of links or is read/spoken/felt in isolation...  this is
obviously a disadvantage to anyone who's access to a list of links is
limited to a single mode of presenting link information, as it can lead to a
serious disconnect between what is heard/felt when the page is aurally or
tactilely rendered, and what information is available to a user via a list
of links...  this is the design flaw in JFW's list of links, as there is no
way to toggle between listing links by hyperlink (screen) text and "title"
or "alt", nor of choosing, in the case of a graphic which is being used as a
hyperlink, between the "title" defined for the encasing link and the "alt"
text defined for the graphic, but again, i emphasize, it is a shortcoming in
a specific implementation and not with the spec...

why is such flexibility necessary?  to meet different needs and conditions,
of course...  when i am moving through a page autonomously, i need to know
the nature and function of the link; the former my AT can (and does)
identify; the latter, the author needs to provide in the form of a
"title" -- unless i trust my UA to "get" the contents of the TITLE defined
for the linked resource, and depending upon the type of resource to which
the hyperlink points, there may not be a practical [read: non-RDF] way to
natively associate a title with the resource...  in order to find and/or
actually navigate to a graphically defined hyperlink, however, i may need
some knowledge of the contents of the graphic...  why?

it's not uncommon to be told to "find the button that says download Adobe
Acrobat" or "find the button that says 'Opera 5 Free Browser'" when what one
is actually searching for is a graphic used as a hyperlink that contains an
image of those words, not the structural element BUTTON, nor an INPUT
element whose type is "submit"...  if (as with JFW or Opera) it is easiest
to find such structural elements by entering a special "forms mode", i may
never find what i've been told to look for -- in fact, the only guaranteed
result is mutual frustration...  if, therefore, the "alt" text defined for
an image which is used as a hyperlink describes the function of the link,
and not the image, the problem of finding the link (not to mention the
user's frustration level) will be compounded, and that user's desire to
visit that site -- or to even utilize the resource to which the user was
being guided -- has either been substantially diminished or entirely
extinguished...

if, on the other hand, the hyperlink contains a "title" such as "download
Adobe Acrobat Reader 5 NOW!" or "use this link to download Adobe's free
Acrobat Reader", and the "alt" text defined for the graphic contains the
same text contained (in a binary, pixelized form) in the graphic itself,
then it would not only be possible for a visitor operating in a
graphics-free environment to either independently discover the link which
allows one to obtain acrobat, or to be guided to it by both casual reference
(in conversation or in a commercial) and direct reference, such as that
provided by a friend, family member, assistant, or customer service /
technical support person...  it doesn't help matters that the term "button"
has entered the vernacular as a generic term for a graphical
hyperlink -especially those which lead (directly or indirectly) to the
initialization of a download routing - nor that sites which disseminate
graphics for use as hyperlinks routinely refer to them as "buttons", either.

the bottom line is, use "title" to describe the function of a graphical
hyperlink; use "alt" to describe the graphic itself.

the purpose of a graphic as a graphic is separate from its function as a
link -- that it is used as a link does change the function of the graphic in
that it's not just a pretty picture any more, but it doesn't change the
content of the graphic itself; hence, the fact that a graphic is used as
part of the definition of a hyperlink shouldn't impact the "alt" string
defined for the graphic...  it should, however, prompt an author to provide
a description of the function or destination of the link using the "title"
attribute for the A element which defines the link...

"alt" text should describe the graphic and nothing but the graphic; the
"title" text defined for the hyperlink itself should describe the function
and/or the expected/intended (re)action...

let's not bend extant markup to our will, but, rather, raise holy hell until
the responsible parties implement/support/make available all of the
"accessibility features" for the markup languages that they support,
natively or through a programmatic interface...

gregory.

--- original post ---
Date: Mon, 27 Aug 2001 03:23:22 -0700
To: wai-xtech@w3.org
From: Kelly Ford <Kelly@kellford.com>
Subject: Re: archive: example message page with long titles

Hello Al,

At 09:47 PM 8/26/01 -0400, you wrote:
>What does the list of links view in Jaws show?
>
>This is controlled by the user setting I mentioned in my first
>message.  The specific setting is called "Text Links Verbosity" and both
>the list of links and Virtual PC view of a web page in JAWS use this
>setting to control what is displayed.

>Can anyone tell us what the list of links view in Window-Eyes uses?
>
>It never uses the title text.  Window-Eyes always uses the general link
>name in all navigation modes.

>If one does not use the list-of-links view, how hard is it to read all the
>text, including what comes in each list item before the link text, and
follow
>the link that you wish when you get to it?

Here's the heart of the matter.  At present I'm confining my comments to
JAWS and Window-Eyes, although I know that HPR behaves somewhat similarly.

Both JAWS and Window-Eyes offer three basic navigation methods of a web
page.  First is what I'll call the buffered or default view.  In this
navigation mode the text of a web page is loaded into a buffer and the user
navigates around with the cursor keys or a few acceleration options, such
as focus to first input control, focus to first non-linked text and such.

In this mode tables are decolumnized and linked text is displayed on a line
by itself.  Assume I have the sentence:

I want to win loads of cash from Powerball but must buy a ticket first.

The hyperlink in the sentence is the word Powerball.  I've also defined
title text on the link as:

A Multi-state lottery game.

This will show up to JAWS and Window-Eyes as follows.  The user would be
pressing down arrow or perhaps in a continuous reading mode.

***Window-Eyes

I want to win loads of cash from
*L Powerball
but must buy a ticket first.

***JAWS set to read title text, the default mode
I want to win loads of cash from
*L A Multi-state lottery game.
but must buy a ticket first.

***JAWS set to read screen text, requires user action to change
I want to win loads of cash from
*L Powerball
but must buy a ticket first.

The second navigation option offered by both JAWS and Window-Eyes is the
list of links feature.  This simply generates a list of all links found on
a web page and places them into a standard Windows list box.  While the
user has several options from this point, what's important here is how the
user can find the context of the links from such a mode.  Both JAWS and
Window-Eyes offer a command, no matter the name, which is the functional
equivalent of moving the user to the link of interest on the web page.  The
user activates this feature from the list of links and is returned to the
buffered view of the web page on the line containing the link.  The user
can then use any reading command to read what's before or after the linked
text.

Finally the user has the option to tab through the web page while in this
buffered mode.  In this navigation mode, the user is stopped at anything
reachable via tab, links, input controls and such.  I should mention that
in this navigation mode, JAWS ignores the "text links verbosity" option and
will always read title text for a link if such has been defined.

In your example page, I noticed that items like reply, next and previous
were present as both text and part of the link titles.  In some navigation
modes for JAWS in particular, this will cause text duplication, i.e. if the
user is cursoring through the buffer with the default of reading title or
alt text.  Here's an example:

Next message:
*L Next: Kynn Bartlett: "RE: guideline 7.1 about screen flickering (fwd)"
Previous message:
*L Previous: Anne Pemberton: "RE: guideline 7.1 about screen flickering
(fwd)"

Kelly

Received on Wednesday, 29 August 2001 09:29:38 UTC