RE: why ALT text alone doesn't suffice for many blind/VI users

From a dogmatic perspective, it matters not all if a checkpoint is onerous.
I don't really care if a P1 checkpoint offends the aesthetic sense of a web
developer.  A barrier is a barrier!  This is why I made the plea for
consensus as to what degree of obstacle graphical text (in navigation
elements) is.

Yes, acceptance and guideline adoption is a real issue.  (Although, perhaps
one that belongs more on the EO list than GL?)  I am, however, alarmed by
the notion recently put forth that some on this list think that some
checkpoints should be unobtainable ideals!

I am also pleased to see some sign of consensus that people understand that
logos and artistically stylized text are quite different from plain text
captured in a GIF.  No one is advocating that all instances of textual
graphics be eliminated!

Your observations about target size is interesting, but moot.
(1)  Missing the target (with an able-bodied person and mouse cursor) is
fairly common and one of the first skills new users learn to perfect.  The
"cost" (clicking again, but aiming a little more carefully) is low.
(2)  Persons with significant disabilities are probably okay -- they either
have AT that makes selecting regular hyperlinked text practical, or they are
using the tab key (and target size is irrelevant).
(3)  CSS can be used to increase the "live area" around text.  Indeed, one
of the features of CSS is the ability to transform regular hyperlinked text
into "real" buttons, complete with bevels, indentation when selected, and
mouse-over highlighting.  (I'm not sure how to add a "click" sound effect,
but that's probably not too hard.)  Navigators (4.x) support of these
enhancements is non-existent, but IE's (5.x) behavior is quite acceptable.
The example used at www.hwg.org doesn't support the enlarged target size
because the text links are inside of table cells (as opposed to using the
"border" attribute).  This was a reasonable compromise, as otherwise the
"button look" would have been lost completely (and not merely degraded) with
Netscape Navigator.
(4)  Even if not remedied with robust CSS, the disadvantage of the smaller
target size is small (P3 maybe) compared with the disadvantage associated
with "text" that refuses to scale.

Once we all understand how graphical text is a significant obstacle for many
persons with low vision, I believe that accepting Checkpoint 3.1 at its face
value will be the only logical conclusion.  (One nice thing about this
resolution is that the WCAG doesn't need to be amended!)  The more
interesting question then becomes, "How do we get supposedly AA to mend
their ways (with the use of graphical text)?"  Of course, maybe that
question too belongs to the EO group!

P.S.:  For an example of using CSS to create real buttons, you can visit
URL:
<http://www.dors.state.md.us/mrc/index2.html>
Just try to find dead space on the buttons!  Please note that these pages
use validated HTML (strict even) and CSS (no warnings) and are (as far as I
know) AAA compliant.  They were designed to run on a kiosk and are pretty
much just their for proof of concept.  The pages are totally non-functional
on deprecated browsers, but I think this says more about Netscape than it
does about the viability of CSS.

Cheers,
Bruce

> -----Original Message-----
> From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
> Behalf Of Greg Gay
> Sent: Monday, October 23, 2000 7:41 PM
> To: unlisted-recipients:; no To-header on input
> Cc: 'Gregory J. Rosmaita'; 'Kynn Bartlett'; 'Web Content Accessiblity
> Guidelines Mailing List'
> Subject: Re: why ALT text alone doesn't suffice for many 
> blind/VI users
> 
> 
>> Is there anyone else who cares to make the case that 
>> graphical text in
>> navigation elements is NOT a significant barrier to many 
>> folks with low vision?
> 
> I haven't caught this entire discussion, so excuse me if I'm 
> missing the point. 
> 
> From a Web developer's and an accessibility evaluator's perspective,
> <em>requiring</em> that all text be presented as text, instead of an
> image of text, is quite unrealistic. Idealistic, yes, but "designers
> won't accept it and won't do it" if it's not a reasonable 
> request. While
> I certainly agree that where ever possible text should be used instead
> of images of text, there are many many instances where actual text can
> not be used: logos, trademarks, propriatary text.... as a 
> number of you
> have mentioned. If we want to convince developers not to use images of
> text, ever, there needs to be much better reasoning. Dictating just
> doesn't cut it with this crowd.
> 
> With regard to navigation images, images of text can aid 
> accessibility.
> Most older screen readers won't read down through a set of text
> navigation links to the left of a page, without reading them 
> in amoungst
> the text that appears in the content to the right. Our 
> solution, create
> image navigation buttons down the left and provide a text alternative,
> usually a set of text links at the bottom of the page with a 
> bypass link
> to them. If the navigation links to the left are text, that would
> violate WCAG1 5.3 and 10.3, if tables have been used to place them
> there. CSS positioned DIVs sort of fixes this problem but CSS
> positioning is not consistent enough across browsers to require that
> developers use CSS/DIVs for this purpose.
> 
> I might also argue that these navigation text-image links 
> could include
> blank ALT text. In practice we include the ALT text anyway to avoid
> arguments from accessibility advocates that follow the guidelines to a
> T, rather than by reasoning or functionality. The first of these
> navigation links might read "text navigation at bottom", thereby
> reducing the redundancy of having to listen to a barage of 
> nav links at
> the top of every page. 
> 
> By the same token, a navigation bar may appear horizontally across the
> top (or bottom) of a page with ALT text ommitted in favour of a set of
> text links immediately below it. I have not heard a good 
> arguement that
> would justify including ALT text for map areas or buttons in 
> an instance
> like this, although I'm sure many here would say, as 1.1 
> states, include
> text for ALL non text elements (period). Reasoning---Functionality!
> Well, in this case the text links below are the text alternative. Why
> include ALT text? Again, why not use a single ALT text for 
> the first map
> area or button that points the user to an accessible text version some
> where else on the page. No functionality is lost, and accessibility is
> improved by reducing redundancy.
> 
> The guideline should state "Don't use images of text for navigation
> purposes without including an actual text alternative."

Received on Wednesday, 25 October 2000 11:23:27 UTC