W3C home > Mailing lists > Public > public-html-comments@w3.org > August 2011

Re: Proposal: ALT attribute for text

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 24 Aug 2011 23:32:59 -0700
Message-ID: <4E55EC9B.9080309@jumis.com>
To: "Jukka K. Korpela" <jukka.k.korpela@kolumbus.fi>
CC: public-html-comments@w3.org
On 8/24/11 10:41 PM, Jukka K. Korpela wrote:
> 24.8.2011 23:50, Clint Goss wrote:
>> ARIA does seem to be a comprehensive proposal for accessibility.
> It is specifically about accessibility (not about the idea of 
> providing alternative presentations in general), it is complex, it is 
> meant for specialized user agents and assistive software (as opposite 
> to mainstream browsers in normal use, the use that most authors and 
> developers focus on), and it is difficult to test.
I've found, as a developer, that ARIA has strong use cases outside of 
accessibility; mainly, in UI development.

By storing additional state data in the DOM, I'm able to both -see- what 
I'm doing, without needing to go into introspection in the script, and 
I'm able to inter-operate with other scripts, speaking the same standard 

element.setAttribute('aria-pressed', true) has helped me on several 
occasions. ARIA has a large vocabulary, and it certainly has a learning 
curve, but like other standards; css3, html5, it's worth learning, and 
it's a big help in development... it's also something that can be 
learned piecemeal. I'm not so concerned about testing, in this case, as 
I am with simply getting developers to start using it.

When ARIA is used with the scripting environment, testing just 
"happens". If an attribute is mis-set, it becomes pretty obvious, as the 
scripting environment relies on its proper setting to function. So if I 
use ARIA, and I do not set my pressed attribute correctly, my site 
breaks, quite noticeably.

> So I'm afraid it will be used by a small minority of authors and 
> developers only.

We're in the same situation with alt: only a small minority of authors 
and developers use it,
and the same with the title tag in SVG. Clint Goss' comments about 
advocacy ["social engineering"] still apply.

Only a minority of devs/authors use the labels appropriately.

>> (although I was not able to quickly find
>> stats on compliance of the mandatory @alt).
> One might measure the compliance to the formal requirement of having 
> an alt attribute for every <img>. But this would give much too high 
> figures, since it is so common to have alt attributes that are useless 
> or worse, failing to comply with the requirement that the attribute 
> specify a textual replacement for the image.

There's an '07 study on user frustrations with the computer; I believe 
it was a survey of 100 non-sighted users... Missing image alts were high 
on the list, as were poorly labeled/named links. Both require additional 
human intervention.

IE9 F12 Developer Tools includes some functions to help "test" for ALT 
tags. One of the reasons, I believe, why alt are not so common, is that 
they're just not emphasized in authoring tools, nor development tools. 
This is something that can and should be worked on further.

There are certainly difficulties in requesting titles. Consider cases 
when users are uploading to an online forum, or a site, like 
Blackboard-- in those cases, it's fairly easy to make adding a title a 
part of the process... but unfortunately, many software packages were 
not designed with WCAG / ATAG in mind. Those are areas we can advocate 
change in.

There is then, the more difficult case, where users are uploading 
multiple images, and asking them to label each image immediately would 
not desirable. In those cases, again, it makes good sense to allow the 
user to update the titles later, and to grant them a tool to help them 
see which images are not labeled.

The user does not need to be told it's "for accessibility", but they 
should be prompted with enough information to caption the image 

Consider that, when a user sees a "caption this image" option, they may 
add some kind of subtitle which makes a pun, or otherwise adds to the 
image. That's fun, and useful, but it's not so useful for non-sighted 
users. And that's where, again, the software that is being used can be a 
big help. It can and should allow the user to write in descriptive 
captions, additive captions, short captions, and so forth. But, most 
software was not designed from that premise.

All of those caption types could be worthwhile for a user to provide. 
But the tool has to allow them that provision.
> But _many_ authors _often_ use alt attributes in a useful way, and 
> this helps people. On similar grounds, it would be useful to have a 
> simple way of specifying textual replacement for text. But the problem 
> is how to define the markup and how to define the conditions for using 
> the textual replacement.
> In some use cases, it would suffice to define as follows: an alt 
> attribute on a <span> element or other phrase element indicates the 
> text to be used in place of the element content, if the content cannot 
> be presented as graphic characters; for example:
> <span alt="diameter">&#x2300;</span>
> or
> <span alt="ΓΈ">&#x2300;</span>
> (A browser would be expected to use the alt fallback if it cannot 
> render the content as the diameter sign, probably due to lack of such 
> character in available fonts. And maybe the idea could be extended to 
> rendering content non-visually; in that case, only the former fallback 
> would make sense.)
I think that font fallback is a different issue, widely handled by 
Unicode related standards.

That said, using aria, instead of specifying new tags, would both work 
with ATs that support ARIA, and it would work for the scripting 
environment, which the author-developer can tweak to the contentment of 
their use case and their users.

Wouldn't something like this work out?:
<span role="img" aria-label="diameter">&#x2300;</span>

May not be the best example, but it's certainly something I can pick up 
with the scripting environment, and post-process, to get additional 
compatibility out of legacy browsers.

Received on Thursday, 25 August 2011 06:33:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:27 UTC