W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2001

Re: Accessibility of ALT texts

From: gregory j. rosmaita <oedipus@hicom.net>
Date: Wed, 11 Apr 2001 04:20:31 -0400
Message-ID: <000301c0c260$46d33670$71b6f5d0@igor>
To: <w3c-wai-gl@w3.org>
Cc: "\"Lois Wakeman\"" <lois@lois.co.uk>, <w3c-wai-ua@w3.org>
aloha, lois!

an equally important question is, what style rules are inherited by the ALT
text when it is rendered inline?  it isn't sufficient merely to force the
browser to display all of the ALT text defined for an IMG, regardless of
whatever height and width has been defined for the unrendered image--the ALT
text has to be usable, and it is my understanding (based upon inquiries made
of sighted users, and work with low vision users) that, aside from Opera,
most GUI browsers display the ALT text in a miniscule font, over the
presentation of which the user has very little to no control...

but, what style rules should ALT text inherit?  should they simply inherit
whatever styles have been defined for the structural element in which they
are contained (such as P, DIV, etc.), or should they be granted a class of
their own, so that authors can stylistically convey to users (who have
support for image placeholders turned off, or for whom such placeholders are
meaningless) that what you are seeing/hearing/feeling is a textual
equivalent for an object that hasn't been rendered?

obviously, the superior solution is to use the OBJECT instead of the IMG
tag, as the OBJECT, by virtue of being a container, provides a means of
providing rich, stylable alternative/conditional content, but for backwards
compatability's sake, a lot of designers/hosts are loathe to use the OBJECT
element to reference images...

my primary concern about CSS and images, however, is the inability to
provide alternatives for images which are referenced via a stylesheet (other
than using a number of hacks, such as generated pseudo-elemental text, which
is problematic, as content generated via the stylesheet won't be carried
through the DOM)...  for example, while i can reference a background image
using a stylesheet, as i did for my QA position paper [1], using the
following bit of CSS:

background-position: top left;
background-attachment: fixed;
background-repeat: no-repeat;
background-image: url(http://www.w3.org/QA/images/qabg.png);

there isn't any means for me to associate an alternative equivalent for
it--such as:

background-image: url(http://www.w3.org/QA/images/qabg.png), alt("Quality
Assurance & Conformance");

another matter for consideration are images defined through stylesheets
(using the list-style-image syntax) for use as list item markers--while the
browser should (at least logically) default to its native list calculation
algorithms/rendering rules (i.e. bullets, asterisks, numeric sequences) if
image rendering is turned off, not all browsers do so (just as not all
browsers support CSS2's nested list counters and scope rules)...  this
should, perhaps, be more explicitly spelt out in CSS3, although it might
already be--i couldn't locate a link to CSS3 Module 14 "Generated
Content/Markers" cited as a dependency in the CSS3 Selectors Module's 26
January 2001 draft...  moreover, a means of providing a fallback if image
rendering is turned off (a.k.a. a cascade) is also necessary--syntax that
allows for the following cascade order if image rendering is turned off, (a)
use client-side style rules for lists; (b) generate list markers according
to the following (author-supplied) rules or (c) default to the UA's default
stylesheet for the list type for which the list-style-image has been

just my 2 cents,

[1] http://www.hicom.net/~oedipus/temp/w3c/qa/gjr_qa_pp.html
Chaos is a name for any order that produces confusion in our minds.
                                                -- George Santayana
Gregory J. Rosmaita, oedipus@hicom.net
Received on Wednesday, 11 April 2001 04:19:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:30 UTC