Re: archive: example message page with long titles

Hello Gregory,

I want to digest all you wrote for a bit.  But if my comments made it
sound like coding should be done to one particular AT product, that wasn't
my intent.  Rather I was attempting to illustrate how a couple of
different products interpreted this example.

Again I want to fully digest your comments.  But I have stated publicly in
the past that I believe JAWS should handle certain aspects of how it
displays web pages differently.

Kelly



On Wed, 29 Aug 2001, gregory j. rosmaita wrote:

> 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 10:00:08 UTC