[Bug 10873] Provide a method of explicitly setting a tooltip for an element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10873

--- Comment #7 from John Foliot <jfoliot@stanford.edu> 2010-10-02 20:19:29 UTC ---
(In reply to comment #6)
> 
> Seems to me UAAG 4.1.1 already applies, since it explicitly applies to all
> functionality. It would be helpful if the Implementing UAAG 2.0 draft could
> give examples of how to offer access to tooltips using the keyboard. It seems
> to me this is important for @title even if a new feature is also added.
> 
> http://www.w3.org/TR/2010/WD-IMPLEMENTING-UAAG20-20100617/#gl-keyboard-access
> 
> However, UAAG 4.1.1 does not strike me as "device agnostic". It specifically
> requires access via the keyboard. This is surely not appropriate for devices
> without a physical keyboard, for example the iPhone. iOS has been praised for
> its accessibility support, through voice and touch:
> <http://behindthecurtain.us/2010/06/12/my-first-week-with-the-iphone/>.
> Interaction using a virtual onscreen keyboard would be much worse.

Good observations/comments Maciej, and I will be sure to forward them to the
UAAG team. Perhaps a 4th requirement for any solution then is that it be truly
agnostic and 'work' on touch-input devices as well.

> 
> That being said, tooltips themselves do not work very well for any users on
> touchscreen devices, since there is no concept of hover. So it is probably not
> good for device-independence to further encourage their use.

Which raises the larger question: do authors/users need or want Tool Tips? If
the answer to that is yes, then we need to figure out how to do them right,
which is one of the foundations of this bug (the other being that it is an
accessible solution)

> 
> 
> >  2. Text must be resizeable and restyleable. (Ref: WCAG 1.4.4, UAAG 3.9.2)
> 
> Do you mean this UAAG 3.9.2?
> 
> "3.9.2 User Style Sheets: If the user has supplied one or more style sheets,
> the user has the following options (Level A):
> (a) select between the style sheets, or
> (b) turn off the style sheets."
> 
> If the intent of that UAAG requirement is that all text anywhere in the UI must
> be styleable with CSS, then it probably needs to be updated.
> 
> If that were done, then it would apply directly. However, it's not clear to me
> if this requirement would be practical. Operating systems have specific
> conventions on how tooltips look. Magnification is generally controlled in an
> OS-wide way, and not controlled by the UA.

I was mostly thinking about user-supplied style sheets w.r.t. the ability to
style the tooltip: change the contrast, enlarge the size, perhaps even apply a
different font-face[1] if required.
[1. http://www.aph.org/products/aphont.html]

The problem we have is that unlike other UI controls linked to the OS, tooltips
are being used by the page/app author to convey information to the end user:
the source of the "information" is not the UI/OS, but removed-to/assigned-to
the content author.

For example, most browsers today allow for a "zooming" of the on-screen content
in the browser - a feature that has been shifted to the browser (one of the
upsides being the relaxed requirement on fixed font-sizes). However, if a
low-vision user "zooms" a web-page, everything is enlarged to a size they can
see *except* the author supplied 'tip' in the tool-tip.

I for one am not overly religious on how this problem should be solved, and
welcome input from the engineering teams on suggestions, as long as the problem
is solved in a stable and dependable, cross-browser, cross-platform way. 

One way to achieve this is to perhaps a) mint a new <tooltip> element (we
certainly have examples of need and use-cases), or b) create a new attribute
(which would be harder to style, but not impossible AFAICT) or c) as you
suggest modify/improve @title

> 
> >  3. Duration of display must be configurable by users. (Ref: WCAG 2.2.1)
> 
> This too seems like an OS-level issue. (On the Mac, as far as I can tell the
> standard is that tooltips display indefinitely until the user moves the mouse.
> I am not sure if there is a requirement to configure the display duration to be
> limited instead.)
> 

...and if this is the case for all OSes that run browsers, then it may be that
this is a non-problem. I will ask whether there is value in specifically
stating this as a requirement for tooltips, to ensure that this remains the
case?


> 
> Not totally sure, but I gave some comments above. I think the challenges are
> the same whether @title or @tooltip is the name of the attribute. This bug does
> not appear to explain how the problems would be solved for proposed tooltip
> attribute.

I was not aware that submitted bugs also require solutions. :-) 

The problem has been brought to the engineers so that dialog can happen; so
that together we can all figure this out. My gut reaction is/was to create a
new <tooltip> attribute (which could be a child element of any block-level
element) but that has not been fully thought out or explored. I am personally
mindful of the desire to keep "creep" in check however, so open to other
thoughts and suggestions.  Bottom line is to solve the problem, which today is
real.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Saturday, 2 October 2010 20:19:31 UTC