W3C home > Mailing lists > Public > public-html@w3.org > September 2007

Re: More about <alt>

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Sat, 8 Sep 2007 02:01:34 -0400
To: public-html@w3.org
Message-Id: <20070908054122.M1586@hicom.net>

aloha, sander!

IMG is different because IMG is not a container -- my point was twofold:

1. to illustrate the need for a short and a long descriptor for static 
   images

2. to illustrate why a compliant UA must continue to support "alt" and 
   "longdesc" as part of the requirements for a conforming user agent

which is why -- at the last teleconference -- i proposed adding to the 
design principles document prose to the effect that:

   "Browsers should retain residual markup designed for a specific 
   purpose, such as accessibility. internationalization or device 
   independence. Simply because new technologies and superior 
   mechanisms have been identified, not all of them have been 
   implemented. Moreover, disabled users are more likely to be 
   users of "legacy technology" because it is the only technology 
   that interacts correctly with third-party assistive technologies"

but let me attempt to clarify the points i was attempting to make:

1. the ask.com thing is something that is being heavily promoted in the 
u.s. -- "search intelligently" is their slogan and they boast that they 
offer OnMouseOver page previews while the user is perusing the engine's 
search results, so as to save the visitor time by being able to quickly
(i suppose) distinguish a site that is worth the user's time to 
investigate, which isn't worth the user's time visiting, and which hits 
actuallly point to a list of adds for products the user doesn't need, 
nor want

i don't know the mechanics of it, or really how to describe it better, 
as it has only been described to me when i've been at a mate's house 
to listen to a match, and the commercial ran at half time...  i've 
never thought of asking someone when they are here to visit ask.com and 
describe the preview pane more completely, and i only have one box with 
a mouse, anyway -- the laptop which i'm typing on now is mouseless, much 
to the distress of anyone who attempts to help me when my screen reader's 
crashed, or another application has crashed and frozen the screen...


2. when i wrote, "you can get a thumbnail of an image in a file listing, 
right?" i was asking (rhetorically, i thought) whether one of the GUI 
file listing formats is to show a thumbnail of the file, so that one 
can decide whether or not it is the file one wants opened...


3. the "weird icon in the tabpanel" is a reference to any generic 
button-type icon in the tabpanel or toolbar area of any GUI program 
whose meaning is not self-evident;


4. there are 3 things that often need to be communicated to the user 
in order for that user to fully inspect and utilize a graphic, 
especially one which is used as a link:

A) a terse description (currenly provided via "alt")

B) a longer fuller, rich description (currently provided by "longdesc")
   it could just as easily be "hrefdesc" or the twain could simply be 
   renamed "terse" and "long"

C) what is this object's intended function (currently provided by 
   the "title" attribute)

a clear distinction between "title" and "alt" text is possible in HTML 
4.01, the problem is that "title" may trump "alt" or "alt" may trump 
"title", which is why there is a need for specific, rather than generic
attribute names for describing objets, just as there are in HTML 4.01
-- the problem is presenting them ALL to the user when necessary, by 
default, or whatever the end user's preference at the time they are 
browsing the web...  when you use a "W3C Validated ML!" graphic, you're
attempting to communicate 2 things to the user:  since you cannot 
process this graphic, here is a terse equivalent: 
alt="W3C Validated ML!" as well as the fact that a visitor can check 
your handiwork for his or herself, by activating the link for which the
graphic serves as hyplink text -- both bits of information are important
to communicate to the user, and any attempt at clarity might run afoul 
of the too-long-an-alt-value syndrome -- for example, about 2 years ago,
on newly created pages, i started using the following ALT text for the 
W3C validation logo:

alt="W3C Validated XHTML 1.0 Strict! (check for yourself)"

but that forces an extra sentence fragment to the ALT text, which is 
annoying to someone who doesn't need to or want to check it for 
themselves, but who simply wants the alt text, not a bastardized alt-
title -- for most, it is sufficient to know that the page is valid -- 
for others, there are plenty of reasons for checking a page's self-
proclaimed conformance...


5. the fact that OBJECT lacks a short and a long descriptor is a problem
with the definition of OBJECT -- if SVG can provide a user with both a 
terse and a fuller, richer description, why can't HTML?  a 
content-negotiation equipped OBJECT is clearly the most robust and 
satisfactory solution moving forward, but i was thinking about those who 
are about to be left behind, and what we could learn from the experience
of IMG and its descriptor options (or lack thereof)


6. i disagree with your reading of the HTML 4.01 TR:

quote
So until now, HTML didn't claim that, as a principle, it is necessary 
to semantically indicate short and long equivalents. It only defined 
that distinction for <img>. Not for <applet>, not for <area>, not for
<object>, not for <frame>, not for <iframe>, which each have only 
either @alt
unquote

frames and IFRAME both allow "id" "name" and "title" values to be set, as
does AREA (for which "alt" is mandatory, according to section 13.8 of the 
HTML 4.01 TR; moreover, the "long description" for a frameset or a script 
is provided by what everyone's clamoring for -- a container for rich, 
marked-up text, via the NOSCRIPT and NOFRAMES elements, both of which are 
containers -- my early practical web advice when frames first started to 
proliferate was to urge people to use the NOFRAMES element not to tell 
their visitors to get a "real" browser, but to contain whatever the 
contents of the navigational frame contains, plus as much of the "main" 
frame's content as the site's tender/overseer deemed necessary...

besides, "applet" (like blockquote for formatting purposes) was 
deprecated in HTML 4.01 and OBJECT, no matter what one may think of its 
original specification or implementation, also provides rich feedback 
intrinsically as a containing element and can be tersely described by 
using the "title" attribute in the opening OBJECT tag...  for OBJECT 
the "title" attribute IS the terse descriptor, while the container 
itself provides for as full and rich an alternative (or set thereof)
as could be desired...  there is an excellent illustration of this 
in the HTML 4.01 TR, which i need to add to the Pattern of Explicit 
Associations wiki page:

<q cite="http://www.w3.org/TR/html401/STRUCT/objects.html#edef-OBJECT"
In the following example, we embed several OBJECT declarations to 
illustrate how alternate renderings work. A user agent will attempt 
to render the first OBJECT element it can, in the following order: 
(1) an Earth applet written in the Python language, (2) an MPEG 
animation of the Earth, (3) a GIF image of the Earth, (4) alternate 
text.

<P>                 <!-- First, try the Python applet -->
<OBJECT title="The Earth as seen from space" 
        classid="http://www.observer.mars/TheEarth.py">
                    <!-- Else, try the MPEG video -->
  <OBJECT data="TheEarth.mpeg" type="application/mpeg">
                    <!-- Else, try the GIF image -->
    <OBJECT data="TheEarth.gif" type="image/gif">
                    <!-- Else render the text -->
     The <STRONG>Earth</STRONG> as seen from space.
    </OBJECT>
  </OBJECT>
</OBJECT>

</q title="close quote">

it would have been "nice" if the editors had used a fuller, richer
description in the container, rather than simply repeating the 
contents of the "title" attribute... it is also "eye-opening" to 
read section 13.8 "How to specify alternate text"

<q cite="http://www.w3.org/TR/html401/struct/objects.html#h-13.8">

Attribute definitions

  alt = text [CS]
      For user agents that cannot display images, forms, or applets, 
      this attribute specifies alternate text. The language of the 
      alternate text is specified by the lang attribute.

Several non-textual elements (IMG, AREA, APPLET, and INPUT) let authors 
specify alternate text to serve as content when the element cannot be 
rendered normally. Specifying alternate text assists users without 
graphic display terminals, users whose browsers don't support forms, 
visually impaired users, those who use speech synthesizers, those who 
have configured their graphical user agents not to display images, etc.

The alt attribute must be specified for the IMG and AREA elements. It 
is optional for the INPUT and APPLET elements.

While alternate text may be very helpful, it must be handled with care. 
Authors should observe the following guidelines:

   * Do not specify irrelevant alternate text when including images 
     intended to format a page, for instance, alt="red ball" would 
     be inappropriate for an image that adds a red ball for 
     decorating a heading or paragraph. In such cases, the alternate 
     text should be the empty string (""). Authors are in any case
     advised to avoid using images to format pages; style sheets 
     should be used instead.

   * Do not specify meaningless alternate text (e.g., "dummy text"). 
     Not only will this frustrate users, it will slow down user agents 
     that must convert text to speech or braille output.

Implementors should consult the section on accessibility for information 
about how to handle cases of omitted alternate text.
</q title="end quote">

[sidenote: the section on accessibility alluded to above is located at:
http://www.w3.org/TR/html401/appendix/notes.html#accessibility 
which contains 4 links, all of which link to WAI resources...]

the first bullet point should have formally deprecated the use of 
images to format pages in favor of stylesheets; also, the character 
entity for the paragraph sign could have been used as alt text in the 
HTML 4.01 example; as for red balls, i once presented a paper as part 
of a symposium on the role of the philosopher in resistance and 
rebellion at kent state university, a topic and a conference which 
had absolutely nothing to do with accessibility...  nevertheless, 
over the lunch break after i had presented my paper, the subject of 
do you slash can you use the internet or web inevitably came up, and 
i gave an aural equivalent of what closely resembled the later WAI 
QuickTip cards, addressing the biggest barriers and the simplest 
solutions, and not long after the conference, i was contacted via email 
by one of the professors i had met over lunch, who maintained a site 
which contained a resource listing which currently active philosophers 
believe that artificial intelligence can truly exist, asking me to check 
her site, as she had just done a "major accessibility overhaul"...  to 
illustrate the sentiments of each philosopher, she had used red balls 
to indicate anti-AI philosophers, and blue balls to indicate those who 
were pro-AI -- the reason i knew she had used red and blue balls, is 
that she had used "red ball" and "blue ball" as alt text, resulting in 
a page full of philosophers with red and blue balls...

gregory.
---------------------------------------------------------------------
CARTESIAN, adj.  Relating to Descartes, a famous philosopher, author 
of the celebrated dictum, Cogito ergo sum -- whereby he was pleased 
to suppose he demonstrated the reality of human existence.  The 
dictum might be improved, however, thus: Cogito cogito ergo cogito 
sum -- "I think that I think, therefore I think that I am;" as close 
an approach to certainty as any philosopher has yet made.
                            -- Ambrose Bierce, The Devil's Dictionary
---------------------------------------------------------------------
Gregory J. Rosmaita, oedipus@hicom.net
             Camera Obscura: http://www.hicom.net/~oedipus/index.html
---------------------------------------------------------------------

---------- Original Message -----------
From: Sander Tekelenburg <st@isoc.nl>
To: public-html@w3.org
Sent: Thu, 6 Sep 2007 13:01:29 +0200
Subject: Re: More about <alt>

> At 01:07 -0400 UTC, on 2007-09-05, Gregory J. Rosmaita wrote:
> 
> > if IMG is preserved as an empty container for "backwards 
compatibility",
> > then it is ESSENTIAL that the alt and longdesc attributes be retained
> 
> Why exactly?
> 
> > [...] if IMG is deprecated, UAs will STILL
> > have to support/enable exposure of alt
> 
> Indeed. As they need to support all (well, most) other pre-HTML5 
> content.
> 
> > and provide a configurable method
> > for presentation to the user
> 
> I can't follow. To configure what?
> 
> > AND the replacement element or elements,
> > MUST have a short descriptor and a long descriptor form
> 
> Why exactly?
> 
> [...]
> 
> > look at it this way, and i do mean visualize this:
> >
> > you can get a site preview through a MouseOver or other hover event on
> > ask.com, right?
> 
> Sorry, I don't understand what you mean. A "site preview" of 
> what, by hovering over what? (Maybe this is some UA-specific 
> feauture of ask.com? I've never used that site before.)
> 
> > you can get a thumbnail of an image in a file listing,
> > right?
> 
> Same thing. I can't follow.
> 
> > you can get an explanation of that weird icon in the tabpanel
> > through a hover event
> 
> Sorry, more of the same confusion again :) What "tabpanel"?
> 
> FWIW, the only mouse hover effects I get on ask.com is when I do 
> an image search, for each found image there is a "source" link. 
> If I mouse hover over that, I get a CSS-dependant tooltip 
> simulation. (I'm guessing it says "source" -- they're forcing me 
> to consume a dutch version of the site.)
> 
> [...]
> 
> > users don't always need or want to have everything explained in 
detail,
> > but if i land, as i did in an earlier thread, on a short descriptor
> > such as:
> >
> > "Snapshot of a KDE Desktop"
> >
> > might i not want a description of a KDE desktop's default GUI "look
> > and feel" so that i can communicate with sighted technical support, 
let
> > alone colleagues and assistive technology?
> 
> Understood. But why exactly does that mean that HTML must define 
> a distinction between short and long descriptions? In what sense 
> does the example I posted in 
> <http://www.w3.org/mid/p06240688c303bb702138@%5B192.168.0.101%5D>, 
using two <alt> elements for the same <img>, one providing a short and 
the other a long description, each indicated as such by the author 
through @title, not suffice?
> 
> I'm not convinced it is not needed. But I think we should be 
> sure that it is needed.
> 
> I don't think the mere fact that both @alt and @longdesc exist 
demonstrates
> that need. After all, the distinction exists *only* for <img>. 
> Not for <DEFANGED_object>. So until now, HTML didn't claim that, 
> as a principle, it is necessary to semantically indicate short 
> and long equivalents. It only defined that distinction for 
> <img>. Not for <DEFANGED_applet>, not for <area>, not for 
> <DEFANGED_object>, not for <DEFANGED_frame>, not for 
> <DEFANGED_iframe>, which each have only either @alt or @longdesc 
> in HTML 4.01.
> 
> [...]
> 
> > sometimes a glance or a signpost is sufficient, and sometimes -- more
> > times than most would admit/think -- it is necessary to know in detail
> > the contents of a graphical component of a document instance; it's
> > like driving: sometimes the signs are sufficient, sometimes you need
> > a map, and sometimes, you just need to pull over and ask someone...
> 
> Completeley understood. And actually, I think <alt> could serve 
> this better, because it would allow for more than just 1 short 
> and 1 long textual equivalent. It would allow for an audio 
> equivalent as well. And a tabular one. Etc.
> 
> -- 
> Sander Tekelenburg
> The Web Repair Initiative: <http://webrepair.org/>
------- End of Original Message -------
Received on Saturday, 8 September 2007 06:01:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:07 GMT