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

Re: Take 4 - Proposal for Definitions and coformance (with just 2 Levels)

From: <gian.sampsonwild@families.qld.gov.au>
Date: Tue, 15 Apr 2003 09:56:52 +1000
To: john_slatin@austin.utexas.edu, w3c-wai-gl@w3.org
Message-ID: <OFD3497CFE.939F507B-ON4A256D08.008347B2@families.qld.gov.au>

>> the ALT text was longer than the JAWS default line length
Gian: what is the JAWS default line length, and what happens if the ALT tag
is longer?

>> I think we need conformance schemes that encompass both "visible" and
"invisible" accessibility features.
Gian: Surely we break up conformance into how much it helps the user (who
has a disability), rather than a) how easy / hard it is to implement, or b)
how much / little it affects the look of the site?

"John M Slatin" <john_slatin@austin.utexas.edu>(by way of Wendy A Chisholm
<wendy@w3.org>)@w3.org on 15/04/2003 02:25:38

Sent by:  w3c-wai-gl-request@w3.org

To:   w3c-wai-gl@w3.org

Subject:  Re: Take 4 - Proposal for Definitions and coformance (with   just
      2 Levels)

Gregg, thanks for posting Take 4! And for the clarifications in
yesterday's telecon.

:Response: Visible and invisible accessibility

I find myself increasingly uneasy about the direction in which the
reorganization of WCAG 2.0 that Gregg first proposed at the March 2003
face to face is taking us, despite the fact that Gregg's Take 4
represents a substantial improvement over the original.  As I understand
it, at the heart of the proposal is the distinction between "visible"
and "invisible" support for accessibility.  The proposed minimum level
would encompass things that enhance accessibility without constraining
the default (visual) presentation of the resource.  The next level would
include checkpoints and success criteria that would make demands on the
default (visual) presentation.

This distinction appears to have a number of advantages.  For one thing,
it's clear: if a given accessibility feature is visible to the naked eye
it's almost certainly at level 2, while minimum-level requirements are
invisible (at least at first glance).  This invisibiligy is proposed as
the second possible advantage: the guidelines might be more palatable if
at the minimum level content providers were required to do only those
things that enhance accessibility without having to re-consider
prevailing design practices or conventions.  Only developers who chose
(or who worked for organizations that chose) to go beyond the minimum
level would have to worry about challenging those conventions.

I'm concerned that this appears to send the wrong message both to
content creators and to people with disabilities-it seems to say,
accessibility is OK as long as the majority of users don't have to see
the things that are done to accommodate the needs of users with
disabilities, and as long as developers and designers don't have to
change any of the visual design practices that often create
accessibility barriers in the first place.  In other words, guidelines
organized on the proposed lines might be read as saying that disability
itself is most acceptable when it's least visible.

Of course this isn't what WCAG 2.0 is intended to convey.  On the
contrary: we are in fact asking developers to do a great deal, both
behind the scenes and on the stage, to support a vastly improved level
of accessibility-and that accessibility requires action in both places.
So let's not seem to privilege one above the other.

I mean this as a practical argument as well as a high-falutin
cultural/political one.  When accessibility features are invisible
they're also easier to overlook-even for the people who created them in
the first place.  For example, yesterday I reviewed a site whose home
page was entirely graphical (including several images of text).  The key
element in the visual design was an image that changed whenever the user
moused over one of several thumbnail-sized images on the right side of
the screen.  This image also functioned as a link to another site which
was represented by the image.  Explanatory text beneath the central
image changed whenever that image changed.  There were several problems:
(1) the explanatory text was actually a graphic, with ALT text identical
to the image of text on the screen.  But (2) the ALT text was longer
than the JAWS default line length, so the screen reader behaved as if
there were two graphics there instead of one (pace Joe Clark, I know
this is a screen reader flaw; nonetheless it's an aspect of user
experience).  (3) The ALT text and the HREF for the link associated with
the image were hard-coded: they stayed the same even when the image and
the (graphical) explanatory text changed as a result of the mouseover.
There were other issues, too: for example, the placement of the images
on the screen made a complete mess of the reading-order as JAWS
encountered individual <img> elements and read their ALT text.  But the
site looked OK (though the graphical text was too small), and things
happened visually pretty much the way they were supposed to happen.  The
trouble was all in the invisible stuff-that is, in the accessibility
features.  I fear that this state of affairs will continue as long as
accessibility features remain largely invisible.

I think we need conformance schemes that encompass both "visible" and
"invisible" accessibility features.

John Slatin, Ph.D.
Director, Institute for Technology & Learning
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.ital.utexas.edu

The information contained in this e-mail is intended for the
recipient(s) only. It may contain privileged or confidential
information. If you are not the intended recipient of this
e-mail, you must not copy, distribute or take any action
that relies on it.

If you have received this e-mail in error, please notify the
sender immediately and then delete the message.

This footnote also confirms that this e-mail message has
been checked for the presence of computer viruses.
Department of Families provide no guarantee that all possible viruses
have been detected and cleaned during this process.

Received on Monday, 14 April 2003 20:10:50 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 16 February 2017 16:48:45 UTC