Re: alt text seen or not?

In my mind, it's the image map that is redundant.  I prefer to use text
links only. But if I am required by my content provider or my customer
to put an image map or graphic navigation buttons on the page as well, I
will ensure that the page will be accessible and usable by all visitors,
regardless of their ability, disability, hardware, software, or economic
condition.  

"Making a Web site accessible does not have to stifle its artistic
presentation or professional look. The design and presentation will not
suffer if you follow one simple rule: Create your site with text-only
pages first. When you are sure that it is complete and accessible, then
add the images and other design touches. Your site then will be
accessible to everyone."

Making the Internet Accessible For all -
http://www.civic.com/civic/articles/civic_120699_39.asp

That's how I do it. 

P.S. However, since I completed Kynn's HWG Accessibility class, I would
also add the steps of HTML and CSS validation as well. Obligatory Plug!)

-- 
Kathleen Anderson
State Comptroller's Office
55 Elm Street, Room 101
Hartford, Connecticut 06106
voice: (860) 702-3355   fax: (860) 702-3634
e-mail: kathleen.anderson@po.state.ct.us
URL OSC: http://www.osc.state.ct.us
URL ACCESS: http://www.cmac.state.ct.us/access



pjenkins@us.ibm.com wrote:
> 
> We went off in various directions and never seemed to close the original
> point of this thread.  Here is my attempt to close it.
> 
> DP: = David Poehlman
> PJ: = Phill Jenkins
> KA: = Kathleen Anderson
> BB: = Bruce Bailey
> 
> DP: if alt text is not available, should not there be an alternate
> DP: somution?  for instance, in some cases, alt text is only available when
> DP: you pass your <mouse> over the image.  with no mouse to pass, shouldn't
> DP: that be rendered alternatively so that more people with disabilities
> can
> DP: be accommodated?
> 
> PJ: Are you talking about in-line images (1), client-side image maps (2),
> PJ: and/or JavaScript "mouse-overs"(3)?
> 
> KA:I can't speak for David, but I was referring to (2) client-side image
> KA:maps.
> 
> David?
> 
> PJ: The answer is dependent on what you mean by "rendered alternatively"
> and
> PJ: who [the browser or assistive technology] is doing the rendering. ...
> PJ: For client-side image maps (2) the answer is different depending which
> PJ: browser + assistive technology combination we are talking about.
> 
> KA: In this case I was using IE5, with graphics turned off, with no
> KA: assistive technology.
> 
> KA: In this case, there was nothing rendered.
> 
> Not completely true.  In IE 5 the alt-text for the areas of the image map
> are visually rendered as pop-ups when the mouse is moved over them.  And,
> keyboard navigation with the tab key does stop over the empty areas [moves
> the visual focus indicator] even when graphics loading is turned off. And
> of course, with readily available assistive technologies the user has
> access to the "rendered" alt-text of the image map regions.
> 
> So, is this an accessibility issue or an economic issue?
> 
> PJ: I do not consider this ...
> PJ: "accessibility" related, but more to do with economics [can I
> PJ: afford the time, money, or hardfile space] and the politics
> [willingness]
> PJ: of upgrading or changing technology.
> 
> KA: I guess this is where we differ. As a state government webmaster, I
> KA: still need to accommodate the needs of users who browse with graphics
> KA: turned off and do not use assistive technology. If someone cannot
> afford
> KA: to upgrade their computer or does not have the hard drive space or
> KA: permission to download another browser, they certainly can't afford to
> KA: buy the assistive technology necessary to properly render the alt tags
> KA: in an image map. Nor should they have to.
> 
> No one is asking your sighted IE5 user to "afford to" do anything, except
> run the mouse over the image map - OR - turn image loading on [OK a little
> more $ for connect time].  If your sighted IE5 user has a mobility
> impairment and no "mouse keys" [move the mouse with the keyboard arrow
> keys]" functions,  then they MAY have to turn image loading on to see the
> hot spots.  Still only an economic issue, except it would be nicer for
> graphical browsers to also render [without the mouse or mouse keys] the
> alt-text for client-side image maps, which is currently a Priority 1 [UAAG]
> checkpoint 1.1 [priority seems high for this example].  But, then it's
> another economic issue to upgrade to the better browser.
> KA: Again, as a government webmaster, I can't separate one kind of
> KA: accessibility from another. As a civil servant whose salary is paid for
> KA: by taxpayers, I need to make our sites, which they have paid for,
> KA: accessible to everyone, regardless of their ability, disability,
> KA: hardware or software.
> 
> Sounds like you need to add "or economic condition" to the end of this last
> sentence.  And you as a government webmaster can always make your sites
> triple AAA compliant or at least meet the [WCAG] P3 checkpoint 1.5 by
> adding redundant text links for client-side image maps.
> 
> BB: As Gregg V. wrote in response to Jonathan C. very recently, making
> BB: mainstream Web content meaningful to children is beyond the domain of
> the
> BB: WAI.  Kathleen A. argued that we should accommodate:
> BB: > A sighted person surfing the net with graphics turned off, because
> they
> BB: > have a low end processor, slow modem, or [can't] pay for connect
> time,
> BB: But this is not a WCAG issue either!
> 
> Is the issue that government webmaster don't have the funds [economic
> issue] to add the redundant text links?
> 
> Regards,
> Phill Jenkins
> 
> [WCAG] http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/
> [UAAG] http://www.w3.org/WAI/UA/WD-UAAG-20000115/#gl-device-independence

Received on Wednesday, 19 January 2000 19:59:02 UTC