Re: SVG2 tooltip, title

Hi, Dr. Olaf-

On 1/11/13 5:36 AM, Dr. Olaf Hoffmann wrote:
>
> concerning the discussion about the behaviour of the title element
> in the minutes, 10 January 2013
> http://lists.w3.org/Archives/Public/www-svg/2013Jan/0049.html
> I suggest to align SVG 2 with the SVG 1.2 tiny and to separate
> the functionality of titles and tooltips even more.
> A title has not the functionality of a tooltip, it is basically a short
> description, summary of the content it belongs to, intended to
> be used only for the text alternative of the graphics.
> A tooltip is a hint, suggestion or instruction to do something.

That is the origin of the term "tooltip", but that has not been the sole 
function of tooltips for many years.

Specifically, in the Web and accessibility context, ARIA defines it thus 
[1]:
[[
tooltip (role)

A contextual popup that displays a description for an element.

The tooltip typically becomes visible in response to a mouse hover, or 
after the owning element receives keyboard focus. In each of these 
cases, authors SHOULD display the tooltip after a short delay. The use 
of a WAI-ARIA tooltip is a supplement to the normal tooltip behavior of 
the user agent.
]]


> That some viewers display SVG title elements in a similar way
> as a tooltip in (X)HTML (represented with the title attribute there,
> that has the wrong name for this functionality as well) results in
> a high risk, that authors provide wrong content within the title,
> therefore not a summary, but an instruction.

It might be a summary or an instruction. Both are helpful for 
accessibility, in the right context. For example, labels in HTML might 
be names or instructions. I don't agree that the distinction is always 
clear.


> Because title and desc are intended to provide text alternatives,
> if one has an instruction instead of a summary inside the title
> element, this will typically create nonsense for the text alternative.

An author could opt to use both the <title> (for a "tooltip") and <desc> 
for a summary, if they wish to make the distinction.


> The document or at least the text variant will become inaccessable
> and obfuscated, because it will be almost impossible for viewers
> to detect the difference between a title and a tooltip, if the same
> element is used for both - at least in SVG tiny 1.2 an additional
> attribute has to be noted, if the title is abused as a tooltip,
> currently the SVG 2 draft has neither the related roles attribute
> not the important RDFa attributes - those should be added soon
> to be able to indicate semantical functionality to SVG 2 documents.

We do plan to add these, though not necessarily in precisely the same 
way as in SVG Tiny 1.2.


> Unfortunately the SVG tiny 1.2 approach seems to be ignored
> in most viewers, event if roles="tooltip" is ignored for the
> metadata element, it is typically not displayed as a tooltip,
> therefore authors are still forced to abuse the title element
> or to put an a element with xlink:title around an element to
> provide a more appropiate structure. Because presumably
> xlink attributes will be depreciated in SVG 2, there is a need
> for a replacement anyway for this attribute aligned to the
> title attribute of (X)HTML.

We will likely define the behavior of the 'title' attribute, since 
browsers already support that "tooltip" behavior in SVG, carried over 
from HTML.

Authors are already familiar with this from HTML, so we should bring 
this into SVG. We need to reuse patterns where we find them.


> Therefore - as already noted in the SVG 2 requirements -
> I suggest do introduce a tooltip element or attribute in SVG 2
> to enable authors to separate the functionalities of a title from
> that of a tooltip clearly. With such a specific structure named
> tooltip I think there is a good chance, that this will be really
> implemented as a tooltip and the abuse of the title element
> can be stopped, therefore this would be an important improvement
> of accessibility of SVG documents.

I personally think it's too late to make this change, because content 
and browsers are already out there, and I don't necessarily agree that 
this is the only or even best way to provide accessibility functionality.

We could add a specific role to distinguish names from instructions, but 
as far as I can tell, this would not map to an existing platform-level 
accessibility API... unless it does, it is no more accessible than 
conflating them.


[1] http://www.w3.org/TR/wai-aria/roles#tooltip

Regards-
-Doug

Received on Friday, 11 January 2013 11:04:08 UTC