RE:: Thoughts about tooltips

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.0specification -
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
<http://www.w3.org/MarkUp/html-spec/html-spec_2.html#GLOSS21>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 <http://www.w3.org/MarkUp/html-spec/html-spec_2.html#GLOSS2>,
   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<http://www.w3.org/TR/html401/struct/global.html#adef-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