W3C home > Mailing lists > Public > wai-xtech@w3.org > April 2007

Re: : Thoughts about tooltips

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Thu, 5 Apr 2007 13:53:05 +0100
Message-ID: <55687cf80704050553j42b2e486j19ed2441b8d97cc7@mail.gmail.com>
To: "Jon Gunderson" <jongund@uiuc.edu>
Cc: wai-xtech@w3.org, wai-xtech-request@w3.org
There are a few issues to take into account inregards to use of the status
bar:

*Situations where the status bar is hidden, such as scripted windows.
* Undermines the implicit relationship (contiguity) between a link text and
an associated title text.
* Screen magnifier users will often not have the status bar in view.

stefan said:
"is a interesting proposal (but what to do with veeery long tooltips, won't
they be truncated?). "

In firefox/mozilla the title text longer than 75 characters is truncated.



On 30/03/07, Jon Gunderson <jongund@uiuc.edu> wrote:

>
> I suggest that the title content appear in the status bar when keyboard
> focus moves to an item with a "tooltop" title.  Make the browser could have
> a default stylesheet options to identify items with tooltip with an icon
> beofre or after the link.
>
> Jon
>
>
> ---- Original message ----
> >Date: Fri, 30 Mar 2007 08:46:56 +0100
> >From: "Steven Faulkner" <faulkner.steve@gmail.com>
> >Subject: RE:: Thoughts about tooltips
> >To: wai-xtech@w3.org, wai-xtech-request@w3.org
> >
> >   Hi Becky,
> >   a comment on Stefan's assertion:
> >   <stefan>
> >   >FIRST STATEMENT: Originally title attribute is
> >   designed to host tooltip
> >   >strings.
> >   >It should solely remain for this purpose and
> >   explecitely designated by
> >   >W3C for this.
> >   </stefan>
> >
> >   The original documentation of  title attribute
> >   display (HTML 2.0 specification -
> >   http://www.w3.org/MarkUp/html-spec/html-spec_5.html#SEC5.7.3
> >   ) is not prescriptive about how the title attribute
> >   is designed to be displayed:
> >
> >        "suggests a title for the destination resource
> >        --- advisory only. The TITLE attribute may be
> >        used:
> >          * for display prior to accessing the
> >            destination resource, for example, as a
> >            margin note or on a small box while the
> >            mouse is over the anchor, or while the
> >            document is being loaded;
> >          * for resources that do not include a title,
> >            such as graphics, plain text and Gopher
> >            menus, for use as a window title. "
> >
> >        It only suggests a number of possible display
> >        scenarios.
> >
> >        The HTML 4.01 specification does not prescribe
> >        how title attribute content is to be conveyed
> >        to the user
> >
> >        "Values of the title attribute may be rendered
> >        by user agents in a variety of ways. For
> >        instance, visual browsers frequently display
> >        the title as a "tool tip" (a short message that
> >        appears when the pointing device pauses over an
> >        object). Audio user agents may speak the title
> >        information in a similar context. "
> >        [http://www.w3.org/TR/html401/struct/global.html#adef-title]
> >
> >        But it does clarify its intended function in
> >        relation to accessibility:
> >
> >        2.3.2 Accessibility
> >
> >        "As the Web community grows and its members
> >        diversify in their abilities and skills, it is
> >        crucial that the underlying technologies be
> >        appropriate to their specific needs. HTML has
> >        been designed to make Web pages more accessible
> >        to those with physical limitations. HTML 4
> >        developments inspired by concerns for
> >        accessibility include:"
> >
> >        "Support for the TITLE and lang attributes on
> >        all elements."
> >        [http://www.w3.org/TR/html401/intro/intro.html#h-2.3.2
> >        ]
> >
> >
> >
> >        So i suggest that:
> >          * The title attribute is not solely "designed
> >            to host tooltip strings" and has not been
> >            "explecitely designated by W3C for this."
> >          * The function of the title attribute and its
> >            common visual display characteristics (as a
> >            tooltip) are being incorrectly conflated in
> >            this discussion.
> >        Becky wrote:
> >
> >        "I don't want to make tooltips visible onfocus
> >        because I think that would be
> >        annoying to both keyboard and screen reader
> >        users."
> >
> >        In Windows 'tooltips' are displayed on focus.
> >        (example: navigating through the start menu
> >        shows tootips on items where present)
> >
> >        For screen reader users some indication that
> >        advisory information is available needs to be
> >        provided, as it would be impratical to expect
> >        users to query each focusable element to find
> >        out whether it has a "tootip" or not. It has
> >        been suggested that for screen reader users and
> >        sound such as a "beep" could indicate the
> >        presence of advisory information, but i would
> >        suggest that the repeated sound of a beep would
> >        be more annoying than actually hearing the
> >        title attribute content after the focused
> >        element content is announced.
> >
> >        The same applies for keyboard users, if no
> >        indication that content is displayed, how are
> >        they to know that they need to use a keystroke
> >        to display the advisory information?
> >
> >        Having a user agent preference to show/announce
> >        title attribute information on focus would be a
> >        possible method.
> >
> >
> >
> >        On 29/03/07, Becky Gibson
> >        <Becky_Gibson@notesdev.ibm.com > wrote:
> >
> >          parts of original mails copied below.
> >
> >          <stefan>
> >          >FIRST STATEMENT: Originally title attribute
> >          is designed to host tooltip
> >          >strings.
> >          >It should solely remain for this purpose and
> >          explecitely designated by
> >          >W3C for this.
> >          </stefan>
> >
> >          Yes, but the browser doesn't make these
> >          keyboard accessible and we need
> >          that support today. Also, people want to be
> >          able to create rich text
> >          tooltips.
> >
> >          <stefan>
> >          >SECOND STATEMENT: I don't want to have
> >          describedBy to be used for the
> >          >tooltip BY ANY MEANS.
> >          </stefan>(more details in original response)
> >
> >          Well, I don't feel that strongly but can
> >          understand Stefan's concerns.
> >
> >          <becky original post>
> >          visual indicator that a tooltip is available
> >          Tooltips could be given the ARIA role of
> >          alert  so a screen reader will
> >          speak the alert when it is made visible or
> >          Tooltip can be implemented
> >          via
> >          the described by property on the trigger
> >          element.
> >          </becky>
> >
> >          <stefan>
> >          NOOOOOOOOOOO, MUST BE SCREEN READER
> >          CONFIGURABLE IF TOOLTIP SPOPKEN ON
> >          FOCUS OR NOT
> >          </stefan>
> >
> >          I understand Stefan's concern that the
> >          browser and screen reader should
> >          make the title attribute accessible, but
> >          there is currently not a
> >          mechanism to do this. People want to create
> >          tooltips today that are
> >          keyboard accessible and may include
> >          rich/formatted text.  Given that, my
> >          question still remains? How should these
> >          tooltips be made accessible?
> >
> >          My current feel is to create some keyboard
> >          command like up ctrl-up arrow
> >          or shift-up arrow but I have to try and find
> >          some combination that has the
> >          least conflicts with assistive technology.
> >          This would be a "discoverable"
> >          tooltip - there may be no visual indicator
> >          that a tooI exists.  I don't
> >          want to make tooltips visible onfocus because
> >          I think that would be
> >          annoying to both keyboard and screen reader
> >          users.   I need to implement
> >          something for dojo tooltips and dojo
> >          tooltip-dialogs (these allow other
> >          focusable elements within them).  So feedback
> >          from more folks on the
> >          preferred mechanism to make tooltips
> >          accessible to keyboard and screen
> >          reader users would be appreciated.  See the
> >          thread for more details [1]
> >
> >          thanks,
> >          -becky
> >
> >          [1]
> >          http://lists.w3.org/Archives/Public/wai-xtech/2007Feb/0033.html
> >
> >          Becky Gibson
> >          Web Accessibility Architect
> >
> >          IBM Emerging Internet Technologies
> >          5 Technology Park Drive
> >          Westford, MA 01886
> >          Voice: 978 399-6101; t/l 333-6101
> >          Email: gibsonb@us.ibm.com
> >
> >        --
> >        with regards
> >
> >        Steve Faulkner
> >        Technical Director - TPG Europe
> >        Director - Web Accessibility Tools Consortium
> >
> >        www.paciellogroup.com | www.wat-c.org
> >
> >        --
> >        with regards
> >
> >        Steve Faulkner
> >        Technical Director - TPG Europe
> >        Director - Web Accessibility Tools Consortium
> >
> >        www.paciellogroup.com | www.wat-c.org
>
>
> Jon Gunderson, Ph.D.
> Director of IT Accessibility Services
> Campus Information Technologies and Educational Services (CITES)
> and
> Coordinator of Assistive Communication and Information Technology
> Disability Resources and Education Services (DRES)
>
> Voice: (217) 244-5870
> Fax: (217) 333-0248
> Cell: (217) 714-6313
>
> E-mail: jongund@uiuc.edu
>
> WWW: http://cita.rehab.uiuc.edu/
> WWW: https://netfiles.uiuc.edu/jongund/www/
>
>
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Received on Thursday, 5 April 2007 12:53:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:42 GMT