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

Hi Luc,

My understanding is that "Accessibility" is about *** not creating barriers 
*** for disabled people. That is certainly the principle I have been working 
on for the last ten years. If you provide something extra, that is useful to 
some people but not others without harming those "others" then I do not see 
a problem. Note that I say "useful". I will give an example.

For navigation lists I recommend using the ordered list <ol> element as it 
helps blind people by telling them how many links are in the list and how 
far down the list they are. Now this system is of no benefit to sighted 
users, so a keyboard user, or anyone else, does not get this "helpful" tip 
because my list doesn't display bullets visually. Should I deprive blind 
users of this useful facility, or ruin my visual presentation by including 
numbers in the menu link text ?. No,  The numbering does not present a 
barrier to anyone, but it does help blind people.

So - with regard to using the <title> element it is the same. If it's use 
does not present a barrier it is OK. The real problem is not the use of the 
title attribute, it is the language in the link text. If the language in the 
link text is not understandable then the link text is a barrier. Adding the 
title might help overcome the barrier for some people, but not everyone. So 
inaccessible link text is innacccessible - period.

OK so we start from the position that link text makes sense and tells the 
user what will happen if it is selected. Now the discussion is whether we 
want to *add* the title attribute to provide more help to those who can 
benefit from it. We need to balance this benefit with two things

1) Not everyone will benefit - so it must not be essential
2) Some people will be annoyed by it, my screen reader can be switched to 
read titles and I may not want the helpful comments in your title attribute 
because it slows me down having to listen to both the link text and the 
title. But this is an annoyance, not a barrier.

Therefore accessibility is not about "dumbing down" or restricting 
innovation, it is about thinking about what we are trying to do and how we 
can do it without depriving disabled people of the same benefits that 
everyone else gets. There is no need to ban or deprecate something just 
because some people don't use it properly.

Richard
Userite
London




----- Original Message ----- 
From: "Luc Pardon" <lucp@skopos.be>
To: "W3C WAI ig" <w3c-wai-ig@w3.org>
Sent: Thursday, August 19, 2010 10:50 AM
Subject: 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 Saturday, 21 August 2010 18:05:21 UTC