Re: @title's relation to accessibility

At 16:37 +0100 UTC, on 2007-09-03, Joshue O Connor wrote:

[...]

> Well currently it is used for 'additional' information as per the WCAG
> guidelines [1]

Ah, thanks. Yes, I can see how such use of @title can be helpful in some
browsing situations. But personally I would think such markup can be useful
for all browsing situations, not just for "accessibility". Or perhaps what
I'm trying to say better: while WCAG 13.1 explains that @title can be helpful
for certain specific accessibility cases, an author needs not target such
specific cases. He can understand that @title may be useful for some users,
and provide it. In doing so, he doesn't need to think of specific
accessibility situations, or even of accessibility in general.

> but often this implementation is pretty useless as
> Assistive Technology often practically ignores it

Indeed.

[...]

> For example to tell a user about the purpose of a link or
> to add supplementary information that adds to what they can glean from
> the link text is straight forward etc but with the img element,  even
> when the user explicitly chooses to have the contents of the title
> attribute read out. it can still be ignored.

Sure, but what has this got to do with "accessibility"? A user without any
disablities may just as well choose to ignore @title, or images, or Flash, or
javascript, etc.

> With ALT/TITLE on the img
> element it is an either or situation. I don't think this is ideal.

Agreed. Which is why I'm glad the current draft tells UAs to present @alt and
@title differently.

> Screen readers like JAWS often give the user a choice to output the
> content of one attribute over another.

Are you saying that is the case with more than just @alt and @title? If so,
does that suggest that for screen readers (and other AT?) attributes are more
difficult to handle (make accessible to the user) than elements? If so, that
would definitely be something to consider when speccing HTML. (Through some
rather vague hints, I got the impression that this applies to all UAs, btw.)
This is exactly the sort of real world/practical info we need from AT
developers.

> I think this could be improved if
> use cases were examined. many users never get under the hood of their
> assistive technology and modify how their reader handles HTML and how it
> is 'virtualised', and that is understandable. Why should an ordinary
> user have to know how HTML works in order to use their assistive
> technology correctly?

Well, I have to say that realilty dictates that he should ;) (Or otherwise
not complain when he misses out on things.) However, UAs should ship with
some default settings that 'make sense' to most users for most content.

> This is practically the case with attributes like
> @title. I don't want to have to fiddle about with my car just to drive
> it

Sure, it's reasonable to expect that your car's default settings are useful
for your average use. But you'd still better adjust your headlights when you
load it heavily some time, or fiddle with snow chains when conditions require
them, etc. Alternatively, you can choose to always load the same weight, and
stay home when it snows ;)

Of course people are free to refuse to even look at their settings, but
they'll need to bear the consequences. (Much like democracy burdens voters
with the responsibility to inform themselves.) I mean, just because people
refuse to change IE's default font size to something that makes more sense,
we now have the majority(?) of authors defining font-sizes that in turn
create problems for other users.

Some UAs could make settings much more user friendly though. (Then again,
there too it in the end is the end user's responsibility to pick the best
tool; execute their freedom.)


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Monday, 3 September 2007 16:49:31 UTC