Re: @title's relation to accessibility

Sander Tekelenburg wrote:
> 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". 

I guess this is the goal of the new spec. However it seems to me that if
a feature or attribute is not explicitly accessibility related then it
may have a greater chance of surviving the machinations of how the spec
develops. So I think there is a disconnect. I am unsure if this is the
right approach anyway and that a one size fits all approach to new
elements/attributes in the spec may not work. If it sounds too good to
be true it probably is.

> [...]
> 
>> 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.

Yes, but when you as a user rely on the presence of particular semantics
or other elements and attributes in order to make sense of content,
navigate interfaces etc - then its pretty important - and you or I may
perceive of as an optional accessibility feature or whatever is actually
an integral part of the making the web work for many users.

>> 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.

I think this is good, if that is the case.

>> 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?

No. However as a model it is flawed IMO, and I think this kind of thing
should be avoided in the new spec, or at least there should be greater
awareness in the group of how vendors will likely implement aspects of
the spec. There does, of course, need to be flexibility and I am not
suggesting that psychic powers are necessary but I do think we need to
be aware of how the decisions we make will be implemented and anticipate
any holes, or potential disconnects where possible.

> 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? 

I don't think that its a case that they *are* more difficult to handle
though it could be the case. I would suggest a part of the reason for a
disconnect is the ambiguous nature of some of the attributes. This could
really be a problem with new elements also. Are elements explicitly
being designed for someone who is vision impaired, or blind, has limited
mobility or is it a catch all element/attribute that is meant to serve
everyone, including all devices browsers and user agents? In reality
will this kind of approach work? I am inclined to feel this could render
 concepts like theoretical purity and mantras like 'Universal Access'
and 'Design for All' etc to be void - because IMO there *are* specific
use cases and user requirements that need explicit bindings. The devil
is in the detail.


>> 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.) 

I trust that last sentence is drenched in irony.

>However, UAs should ship with
> some default settings that 'make sense' to most users for most content.

They do. But there is a disconnect. The use of the img element and its
attributes is a perfect case in point where you have two related
attributes but the way they are rendered is an either or situation. But
there is an element of guesswork needed on the part of the screen reader
user. Has the author used @alt and @title? One or either may be
qualitatively useless, one or either  may be useful. Should it be up to
the user to then try and guess a setting in their preferences to try and
anticipate which one the author may get right? No.

To expand the example we may as well suggest that screen reader users
start sampling a population of data containing their average browsing
experience and working out which attribute has a greater probability of
appearing with quality, useful data, if the sample size is large enough
(>30) and the distribution is normal. Lovely. @alt would win BTW but how
many ordinary non-geek users know of such things (meaning the use or
existence of @alt, not statistical calculation)?

>> 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
[...]
> 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.)

In discussions about whether something is the responsibility of the
specification, the vendor or the UA the user is usually the last in the
queue so its not really about freedom when the user doesn't understand
the choices they are making.

Josh

Received on Monday, 3 September 2007 21:52:30 UTC