Re: Addition to guidelines

Daniel Dardailler writes:    supplementary guides like Trace or Starling to fill in the gaps.    The issue of scope vs. time is not new (see
DD>  msg  http://lists.w3.org/Archives/Public/w3c-wai-wg/1997AprJun/0078.html
DD>  in  the archives and the minutes of the June 18th conference call at 
DD>  http://www.w3.org/WAI/group/970618call.html) but since this thread has 
DD>  started I've been thinking of new ways to adress it.    One new element,
DD>  at least in my opinion, is the vigor with which  visually impaired users
DD>  themselves, like Raman,

Speaking for myself, all statements I have made about keeping UA and
 UA and access agent  specific stuff
out of the guidelines  are made from the point of a good design that can
 survive over time, not as "a visually impaired user".

DD>  Jason, or others at  the Boston meeting (Judy
DD>  Dixon, Steve Tyler) are advocating the "let's  focus on the
DD>  document-encoding" view (or forget the idiosyncrasies of  specific user
DD>  agents, as Jason put it).  
You cannot improve things by focusing on any one of the three components in
the (document_encoding, user_agent, access_agent) tupple.
The key is to clearly anchor each statement and guideline with respect to the
elements of the tupple to which they apply.


 So on one hand, I'm totally in favor of
DD>  dropping all these "one link  per line" and "BR in TD" element from the
DD>  WAI Markup guidelines and  concentrate on the quality of the source
DD>  itself, and nothing else.    In a sense, that's working for the future,
That's working towards  sanity-- yours and everyone else's who is attempting
to work in this field.


DD>  which is a position I'm  happy to stand for.    On the other side, as
DD>  Chuck presented it, there are people that want  to do more than what's
DD>  just needed, and want to serve the largest  population of today's Web
DD>  (and therefore for whom knowing the  idiosyncrasies and how to cure them
For these kindly souls  author a "tips" document that is clearly marked
to be relevant at the time of writing.


DD>  at a point in time is important).    These people shouldn't be left out
DD>  the WAI.    It's now clear that we want to separate the "pure"
DD>  guidelines (that  apply to the markup out of a particular browser
DD>  context, like ALT text  presence) from the agent-dependent guidelines,
DD>  the question left is  whether we want to present this split using:  1-
DD>  footnote/subsections in the overall "pure" document  2- as a separate

If they are footnotes in the overall document, you'll make that document have
more footnotes than content.

DD>  document still edited by the WAI group  3- as a separate document edited
DD>  by some other groups   I think we're heading toward 1 after the August
DD>  meeting, but I'd like  to propose that we do 2 instead (Gregg, how about
DD>  that for a moving  target...).    The issue, as Raman put it, is one of
DD>  perception, more than anything  else, and one of our requirement should
DD>  be that content providers  (mainly) and authoring tool makers feel
DD>  comfortable they can easily  implement our guidelines when they look at
DD>  them, so the shorter and  more focused the document, the better.     
DD>  To formalize a little more using Raman model:    WWW access is a
DD>  function of the following triple:   (document-encoding, user-agent, access-agent)_t   I personally think it is 
DD>  (document-encoding, user-agent)_t   (I don't see why we need to separate

You need to separate the access_agent today because user-agents like IE and
Netscape dont have directly builtin accessibility.
Often, accessibility is muddied by how effective a particular access_agent is,
and you dont want to author guidelines that are biased by the features and
more likely the bugs of any single access tool.


DD>  access-agent for the overall  user-agent in the theory, and I also like
DD>  to point out that  document-encoding include anything you get from the
The above is not theory-- it's an attempt to put a stake in the ground,
based on todays practicalities so that one does not end up getting thoroughly
confused.


DD>  server).    And what we could achieve is to make WWW access *guidelines*
DD>  a even  simpler function:  (document-encoding)_t   where the only


No-- caring only about HTML will not help anyone.  You'll end up in the same
situation as exists today for SGML-- in theory it's the most accessible
because it is fully structured and separates presentation from information
--hell, most SGML documents have no presentation:-) but the "accessible
agents" for previewing SGML documents are even scarcer than the tools for
previewing them in a WYSIWYG interface.

DD>  think we care about timewise are the versions of HTML  in support.   

-- 
Best Regards,
--raman

      Adobe Systems                 Tel: 1 (408) 536 3945   (W14-129)
      Advanced Technology Group     Fax: 1 (408) 537 4042 
      (W14 129) 345 Park Avenue     Email: raman@adobe.com 
      San Jose , CA 95110 -2704     Email:  raman@cs.cornell.edu
      http://labrador.corp.adobe.com/~raman/        (Adobe Intranet)
      http://cs.cornell.edu/home/raman/raman.html    (Cornell)
----------------------------------------------------------------------
    Disclaimer: The opinions expressed are my own and in no way should be taken
as representative of my employer, Adobe Systems Inc.
____________________________________________________________

Received on Tuesday, 19 August 1997 12:49:35 UTC