W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2000

Re: alt text seen or not?

From: Kathleen Anderson <kathleen.anderson@po.state.ct.us>
Date: Mon, 17 Jan 2000 17:25:37 -0500
Message-ID: <388396E1.7A870B94@po.state.ct.us>
To: pjenkins@us.ibm.com
CC: w3c-wai-ig@w3.org, David Poehlman <poehlman@clark.net>
pjenkins@us.ibm.com wrote:
> David Poehlman wrote:
> >if alt text is not available, should not there be an alternate
> >somution?  for instance, in some cases, alt text is only available when
> >you pass your <mouse> over the image.  with no mouse to pass, shouldn't
> >that be rendered alternatively so that more people with disabilities can
> >be accommodated?
> Are you talking about in-line images (1), client-side image maps (2),
> and/or JavaScript "mouse-overs"(3)?

I can't speak for David, but I was referring to (2) client-side image

> The answer is dependent on what you mean by "rendered alternatively" and
> who [the browser or assistive technology] is doing the rendering.  Perhaps
> more importantly to consider is which version of which browser or assistive
> technology is being considered and whether it is being "visually" rendered
> [seen or not].

In this case I was using IE5, with graphics turned off, with no
assistive technology.

> As we all know, the "rendered alternative" in many graphical browsers for
> images (1) occurs when you turn off loading of images and the browser then
> visually renders the alternative text in place of the images that were not
> loaded. An assistive technology screen reader [if used] could then "render"
> the alternative text in synthesized speech or Braille.  Many graphical
> browsers ALSO visually render the alternative text of the image when the
> mouse goes over the image.  The more interesting cases are image maps (2)
> and JavaScript mouse-overs (3).

In this case, there was nothing rendered.

> For client-side image maps (2) the answer is different depending which
> browser + assistive technology combination we are talking about. I heard
> arguments that because many graphical browsers render visually the "alt
> text" of images (1), that they should also render visually the alt text for
> the areas of the images maps (2).  These arguments were based on older
> level assistive technologies AND / OR when graphical browsers have images
> turned off for faster downloading and the sighted user can't see the
> alt-text for the areas of the image maps, only the alt text for the whole
> image, because many [all?] graphical browser doesn't visually render the
> alt-text for the areas (2).  I do not consider either of these two
> arguments "accessibility" related, but more to do with economics [can I
> afford the time, money, or hardfile space] and the politics [willingness]
> of upgrading or changing technology.  To be certain,  it is still helpful
> for authors to provide the redundant set of text links, hence the Priority
> 3 guideline 1.5 in [WCAG], but also note the checkpoint 2.1 Priority 1 for
> User agents to provide the access to all content including alternative text
> [I assume for image maps?] at some point [UAAG]. Whether being visually
> rendered is the intent of the checkpoint or by providing an equivalent
> interface for the assistive technology meets the checkpoint is unclear to
> me in this image-map case.

I guess this is where we differ. As a state government webmaster, I
still need to accommodate the needs of users who browse with graphics
turned off and do not use assistive technology. If someone cannot afford
to upgrade their computer or does not have the hard drive space or
permission to download another browser, they certainly can't afford to
buy the assistive technology necessary to properly render the alt tags
in an image map. Nor should they have to.

> For JavaScript "mouse-overs" (3) I believe the responsibility for
> "alternative rendering" belongs in the assistive technology.  There is also
> the mobility view of the issue that needs to be considered here.  A sighted
> person needs to be able to get the graphical browser to render the
> "on-mouse over" event without directly using the mouse.  Some combination
> of "mouse keys" support in the operating systems platform and additional
> assistive technology that utilizes that support is needed to solve the
> accessibility issue for the mobility impaired user.  The assistive
> technology used by a blind person would also need to utilize that support
> or perhaps a better interface that is being designed into the Document
> Object Model (DOM).  The DOM interface would be exposed by the browser so
> that the assistive technology could directly manipulate the document and
> "render the equivalent" of the mouse-over to the user.  No need to simulate
> hardware mouse actions or have the browser visually render the mouse-overs
> with some new user interface.
> I generally believe that there is and will always be a place for assistive
> technology.  Although I support the goal or direction of universal
> accessibility, I believe it is just that, a goal and direction, not a real
> destination.

I prefer to think of it as a mission. Not to get emotional here, but
tackling this issue is something I've wanted to do for quite awhile, and
things recently fell into place at my job that allowed me to do so. If I
could do this kind of work full time, I would. It's turned into a
passion for me, and that's a first for me in my 25 years of working in
the Information Technology field.

  I also prefer to separate the economic and political concerns
> from the pure "accessibility issues".   Keeping things separate makes it
> easier to identify the party responsible, whether the browser, the
> assistive technology, the user, or governments and society; thereby helping
> us focus our efforts and directing the issues to whom best could solve
> them.

Again, as a government webmaster, I can't separate one kind of
accessibility from another. As a civil servant whose salary is paid for
by taxpayers, I need to make our sites, which they have paid for,
accessible to everyone, regardless of their ability, disability,
hardware or software. I am not in a position to write or introduce any
web site accessibility legislation at the state level, but as a
webmaster, I can work towards achieving that goal.

> [WCAG] http://www.w3.org/TR/WCAG10/#tech-redundant-client-links
> [UAAG]
> http://www.w3.org/TR/UAAG10/wai-useragent.html#tech-doc-content-access
> Regards,
> Phill Jenkins

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
Received on Monday, 17 January 2000 17:27:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:07 UTC