Link title attribute and things (Was: Re: Microsoft PowerPoint accessibility)

   Regardless (or in addition to) what Wayne said about link title
usefulness, there are a few more thoughts that I'd like to bring up. Not
replying to anybody in particular.

> Title text, being only of use to some users of AT, should never be
> relied on to explain the purpose of a link, [...] 

   Agreed, that's also what the guidelines say, no argument here.

> [...] and should be done away with
> as it is misused and relied on to provide information which may only
> benefit a small proportion of users.

   If "do away with" is intended to mean that all the "title talk"
(a.k.a. H33) should be removed from the Guidelines, or even that the
Guidelines should explicitly tell developers not to use it, I
respectfully disagree.


   1. As long as something (link title or whatever) doesn't get in the
way of some users, and as long as it is not used to provide "essential
content" (as defined in the Guidelines), I don't think there is a valid
reason to "do away with it".

   If we do that, it means we go for the "lowest common denominator"
across all the different UA's out there, and then we're down a slippery
slope.

   Using that same logic, we should, for example, do away with images,
since they only benefit those users that can see them. And music.

   I have a website in Dutch. That benefits (well, I like to think it
benefits <g>) just the tiny proportion of the world population that
understands this language. It is totally "inaccessible" to the others.
Should my site be done away with? Or be forced to provide "alternate
content" in all the different languages of this world?

   The content of websites about astrophysics or advanced mathematics
would probably be totally "inaccessible" to most people. Get rid of them?

   My website is about Greek music, not astrophysics, but it's full of
specific terminology nonetheless. My target audience is a
(Dutch-enabled) visitor with an advanced knowledge of the subject. But
that's a tiny subset of a tiny subset. Most other people would say "this
site is all Greek to me" <g>. Does that mean it shouldn't be there?

   Yes, I know that on this list we're concerned with technical and
physical issues, not linguistics and things, but I'm getting there,
right now <g>.

   I happen to provide dictionary-type definitions in mouse-over
pop-ups. That makes my site more "accessible" to a "beginner" with an
appropriate UA. Should I stop doing that because some/many/most other
UA's can't show them?

   Remember that those users that can't benefit from my flashy
definitions are no worse off than if there were no definitions at all.
So, it's not that they loose something, it's just that they can't gain
something, whereas others can.

   As an aside, and before somebody refers me to G55 "Linking to
definitions" or G111 "Inline definitions", let me point out that we're
_not_ talking about "unusual words" here. They are not unusual to my
target audience. To them this is basic stuff, somewhat like "HTML" on a
site about web design, or "user agent" on a site about accessibility.

   A related question that came up in the "link title debate" is this:

> if it's useful enough to add, shouldn't it be available to
> everyone?

   If it's "essential" that it be available, then yes, of course. If
it's just "useful", let me turn the question around: if it can't be made
available to some, should it be kept away from all? As a matter of
principle?


   Don't get me wrong: it's not that I'm up in arms because my beloved
pop-up definitions are threatened with extinction (in fact they're not,
link title is not involved so I'm off the hook <g>). I'm only using them
as a convenient example of things that are "relied on to provide
information which may only benefit a small proportion of users". I could
have referred instead to HTML5 constructs that are not supported by MS IE.

   To summarize: I don't think it's wrong to "give" extra things to some
people, as long as you don't "take away" things from others. Yes, that
is subjective, and yes, that should be considered on a case-by-case
basis. But that is true also for the decision about what is "essential
content" and what is not. And that is how it should be.


2. It has been said that link title attributes are used for all kinds of
ugly, annoying, boring, or otherwise horrible things. That may be so,
but that by itself is - in my opinion - not a reason for us to "forbid"
them.

  We do "forbid" some color combinations because they make content
inaccessible to some users, not because they are "ugly". The
Accessibility Guidelines are about accessibility, not about taste.


3. Another remark in this thread was this:

> [...] since practically user agent/adaptive
> technology combinations don't give access to the attribute, we
> shouldn't be telling developers to use it

   Actually, I don't think we're really telling developers to "use" the
title attribute. What we're doing is we're telling them to use it with
care, to think about the consequences. To quote H33: "... authors should
use caution in applying this technique".

   And I believe that this is the proper thing to do. That attribute is
valid HTML, we shouldn't ignore it, we must say something about it.
Developers expect guidance from the Guidelines. They start out with an
idea, then they think about how to implement it, and then they go and
consult the Guidelines. If the proposed implementation doesn't meet the
success criteria, they (should) go back and start over. That's basic
engineering practice, applicable to the design of bridges, airplanes,
tea grinding machines, whatever. In this case the Guidelines are the
touchstone.

   Now, if the link title attribute is part of the developer's candidate
solution, and the Guidelines are silent about it, what do we expect them
to do?

   One thing is for sure: it's not reasonable to expect a developer to
be an expert in all imaginable medical conditions and all available
brands, types and versions of all different kinds of user agent out
there. That's what the Guidelines are for, to be a kind of "combined
wisdom" of all the experts that contributed to them.

   So, even a developer with the best of intentions cannot really be
expected to know that there are any issues with "title" unless we say so.

   Therefore, we should document the issues, which is exactly what we
do, in this particular case in H33.


4. While I'm at it, there is yet another issue that has been on my mind
for quite some time.

   More and more countries start to enforce accessibility by law. That's
good (for reasons that have been discussed at length). But it also means
we must be very careful about what we put in the rule book, because the
lawyers are going to come in and they will look at what is written, not
what was meant. This is an entirely different game from UA talk and even
accessibility considerations. We must be careful not to create a
Frankenstein monster.

   The plea to "do away with the title attribute", for example, may do
just that. If the law requires a site to be accessible "as defined by
Rulebook Whatever" and those rules say "don't use title", then it's
against the law to use "title", period. Now, let's say I'm using a link
title to bring up a silly popup that says "this is a link, please click
me", it bothers nobody (most certainly not those who don't see it <g>).
It gives nothing, it takes nothing. But I'll still get sued for "being
inaccessible", and I will loose the case. The judge may or may not think
the lawsuit is silly, or abusive, but (s)he has no choice, the rules
must be enforced. There always will be lawyers who will try and convince
people to hire them to sue other people, if there is enough money to be
made.


5. Finally (I promise it's "finally"!), the reasoning that we should
drop things because most UA's don't support them is flawed. UA is
commercial stuff. It won't get a particular feature if there is no
demand for it, and there will be demand only if the missing feature is
considered "desirable" by the customers. This has been said many times
before, but I thought it worth-while to bring it up again.


  Note: When I say "we", please don't take that as a claim that I have
somehow contributed to the "writing of the rulebook". I have not, I'm
just a developer.

  That's all. Really! Thanks for listening.


   Luc Pardon
   Skopos Consulting
   Belgium

Received on Thursday, 19 August 2010 09:51:07 UTC