RE:: Thoughts about tooltips

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/

Received on Friday, 30 March 2007 11:51:32 UTC