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

This message replies to two queries stated below and to Jason's query
about what exactly I'm proposing.

John

-----Original Message-----
From: gian.sampsonwild@families.qld.gov.au
[mailto:gian.sampsonwild@families.qld.gov.au]
Sent: Monday, April 14, 2003 6:57 pm
To: John M Slatin; w3c-wai-gl@w3.org
Subject: Re: Take 4 - Proposal for Definitions and coformance (with just
2 Levels)



 >> 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?

The default setting for line length in JAWS is 150 characters, including
spaces and punctuation.  When JAWS encounters ALT text with more than
150 characters, it behaves as if it had encountered another graphic.  A
sample transcript might sound like this:

We will provide access for evgraphic ery citizen into the resources of
our libraries, collections, museums, and much more. - Larry R. Faulkner,
President of The
Graphic University of Texas at Austin

The example above is the complete ALT text for a single *image* of the
text (presenting the same words in graphical form).  It's *one* graphic,
but JAWS treats it as two.  It's not a big deal in this particular
instance, but it can be confusing if the long ALT text happens to be
associated with a graphical link.

 >> 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?

I agree with you!  But Gregg's proposal, as I understand the way it's
outlined in his "Take 4" message, argues that the minimum conformance
level should be confined to those techniques that do *not* constrain the
default presentation of the content.

-- Jason, what I'm proposing is that the working group think very
carefully about the implications of a conformance scheme in which the
minimum standard is constrained by political considerations.  I don't
mean to dismiss Gregg's concern about the difficulty of achieving
Recommendation status if we write guidelines whose minimum level may
constrain the choices designers make about the visual or auditory
presentation of their material.  But I think we'll have to face that,
and make compromises if they're necessary to address the concerns. Of
reviewers and member organizations. I'm perfectly happy to give full
support to Gregg's proposal if the group as a whole is convinced that
it's in the best interests of the global community of Web users who have
disabilities.

John





"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
cc:

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
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 Tuesday, 15 April 2003 10:38:10 UTC