Re: Usability issues with the specific semantics for "title" attribute

I will specify the different issues and possible solutions below:

 - on <dfn> and <abbr> the expansion or complete definition term is
practically hidden, while at least in the second case it is vital for text
comprehension. I STRONGLY suggest you to allow a "value" attribute, and to
implement a different kind of (native) focus-state tooltip working along
with a visual/acustic hint (e.g. a question mark as superscript).

 - on <menuitem> the title attribute wouldn't need any specific semantics,
as the proposed usage is somehow compatible with the common usage of this
attribute. But as the <menu> element is conceived to integrate the context
menu of the user agent (at least if it contains menuitem children
elements), maybe the tooltip behaviour isn't the ideal choice. As I
suggested in a previous (unresponded) message, <menuitem> (which I still
ask myself why on earth has been conceived as void element) can (and
should) have the command name specified by the textContent. So the label
attribute could be used for a further description. Think about the menu
element as an integration of context menu in mobile devices (as it is
commonly implemented in apps), or in desktop browsers when recalled by the
"context menu" key: what use could ever be there for a hover tooltip?

 - on <input> elements, relying on a potentially invisible attribute for
hints about pattern (which is itself a subtle feature) is nonsensical: such
a hint is more useful while keying the input itself, than in a second step
regarding form validation. What the spec suggests, instead, is to initially
rely on a potentially invisible tooltip while inserting the value, with no
hint of the very existence of the input request, and on second stance to
expose this generic attribute in a completely new fashion. Ever heard about
user-friendliness? Pattern hints MUST be exposed in clear and from the
beginning, in the control's label which must be present in such a case. The
only necessary tooltip for this case can be generated by the user agent,
stating that "the control is not completed as required", while the
requisites cannot be left to the common sense of a user hovering the
control itself (I should remember authors that interactive elements can be
focused via the use of the tab key, saying "byebye" to hover tooltips).

 - on <link@rel=stylesheet> and <style>, @title is again nonsensical as its
common usage is to define a visible tooltip... but these elements are
invisible metadata elements. It should be substituted by an "id" attribute
which IMO is more appropriate for the use (Alternative style sheet set
name)...

 - ...and/or in general on <link> elements it shuld be substituted by a
"name" attribute if the restrictions on a @id attribute value are too
strict.

@title is a global attribute. No change at all would be necessary in old
pages, as the suggestion is there. It's just the idea of substituting old,
generic features with newer, more useful ones. Like what was done when
sequencing <div>s were substituted by <article>s and <section>s.
I listed the points in order of decreasing relevance Please consider them
appropriately, it's important.
Regards.
Andrea


2014-04-13 19:58 GMT+02:00 Andry Rendy <master.skywalker.88@gmail.com>:

> Hi everybody.
> As the spec says, "Relying on the title attribute is currently discouraged
> as many user agents do not expose the attribute in an accessible manner"
> for a number issues regarding usability. But some elements heavily rely on
> this attribute to convey their own meaning or for thorough native workings.
> This is a huge problem for assistive technology users. In addition to this,
> it makes the text of the tooltip potentially useless for common users, as
> no hint is commonly associated with the presence of @title, be it relevant
> or not. Finally, it is a theoretic nonsense in some cases.
> I think it should be substituted by different attributes and different
> implementations, which must be elaborated in a case-by-case basis. I shall
> keep the specific suggestions for a following message, hoping this thread
> can have a little support.
> Thanks.
> A.
>