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

RE: Key results and recommendations from Face to Face

From: John M Slatin <john_slatin@austin.utexas.edu>
Date: Fri, 25 Mar 2005 09:22:19 -0600
Message-ID: <6EED8F7006A883459D4818686BCE3B3B7ADFCD@MAIL01.austin.utexas.edu>
To: "Gregg Vanderheiden" <gv@trace.wisc.edu>, <jasonw@ariel.its.unimelb.edu.au>
Cc: "Al Gilman" <Alfred.S.Gilman@IEEE.org>, <w3c-wai-gl@w3.org>

Gregg wrote:

<blockquote>
Perhaps we are confusing the term "standard" in its two meanings.  One
is "the way most people do it" and the other is " the way you must do it
to conform". 
</blockquote>

Perhaps "conventional" or "typical" would be better terms to use for
that first sense of the word "standard."  For example, it has become
"conventional" to use the link text "More ..." for a link to the
continuation of a news item.  By contrast, the HTML standard (in this
case a specification) requires that the link text is enclosed within an
anchor element.

Use of the alt attribute to provide a text alternative for an img
element is both standard (in that it's required by the HTML
specification) and (almost) conventional, in that it is now fairly
widespread on the Web (certainly more widespread than it was five years
ago).

Hope this helps.
John


"Good design is accessible design." 
John Slatin, Ph.D.
Director, Accessibility Institute
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.utexas.edu/research/accessibility/


 



-----Original Message-----
From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] 
Sent: Friday, March 25, 2005 7:36 am
To: jasonw@ariel.its.unimelb.edu.au
Cc: John M Slatin; 'Al Gilman'; w3c-wai-gl@w3.org
Subject: RE: Key results and recommendations from Face to Face


Hi Jason,

 I still don't follow your thoughts.   Help me here.

  If there are several acceptable methods then there are several
acceptable methods. 

  If there is only one - then there is only one.

  What is in the techniques doc does not change that fact.   Being in
the
techniques doc may make one approach more known.   And it may give the
user
of the technique more evidence that it is a good technique.  And it may
be
used more.  (is that what you mean by de-facto standard?).   But it does
not
make it normative.  And it does not require the user to use it to
conform.

Perhaps we are confusing the term "standard" in its two meanings.  One
is "the way most people do it" and the other is " the way you must do it
to conform". 

Gregg



Gregg Vanderheiden writes:
 > Pretty good Jason,  except where you made the leap to "if there is no
> standard than whatever techniques says is de facto standard".  This is
not
> true.  If there is no standard and supported manner then there is none

> -- and you can't comply with that technology.

In the original post I was trying to clarify what I believed to be one
of the central issues Al raised. Suppose a format specification provides
features that allow a certain requirement to be met in several different
ways. That is, there are various distinct usage practices that would
satisfy the WCAG success criterion. To support accessibility, content
developers and software implementors need to know which to support.

The most likely outcome is that the techniques documents would fill the
void left by the absence of, or inconsistencies among, usage practices
with respect to the success criterion. In substance, the techniques
documents would be legislating by specifying one or more of the
alternative solutions allowed by the format specification; and this is
what would give rise to the accusation I mentioned of conferring a de
facto authoritative status on the techniques.

One answer might be to adopt a technique development process whereby
proposed techniques are implemented first, tested for efficacy, and only
then integrated into a document; the techniques documents might then be
truly statements of empirical fact rather than disguised norms.
Received on Friday, 25 March 2005 15:22:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:36 GMT