Re: Re-Organizing Guideline 2.7

aloha, charles!

Charles McCathieNevile wrote:
> Some of what we require is already done by checkpoint 2.4.2 - Make generation
> of accessible content a naturally integrated part of the authoring process,
> which is P1 already.

to which Gregory responds:

true, enough, but as was debated at the cambridge face2face meetings (i
believe) when it was proposed that portions of 2.7 be rolled into 2.4,
this is important enough an issue to address in a discrete guideline... 
the point is that while, yes, it is definitely a P1 to quote make
generation of accessible content a naturally integrated part of the
authoring process unquote, it is also necessary to make accessible content
a naturally integrated part of the help system...  the difference here is
that guideline 2.4 is concerned with getting the authoring tool to present
the user with the accessible solution first and as the default, whereas
2.7 is concerned with the documentation of accessible authoring practices,
and the natural integration of accessible markup into each and every
applicable example of implementation methods (i.e. choosing style sheets to
change font size and color) and in every example of code (the sample
markup for a form, for example, should include fieldset, legend, label,
accesskey, and tabindex, etc.)

yes, 2.4 and 2.7 are inter-related, but they are 2 methods of achieving a
common goal: the production of authoring tools that not only output
accessible content and which are themselves accessible, but which also
educate the user (or at least alert him or her) about accessibility
issues, thereby enabling them (that is, the authors themselves, rather
than the tool exclusively) to make educated decisions about the content
and (equally important in my mind)  structure of the pages they produce... 
what a specific guideline on help/documentation does, therefore, is to
assist in the production not only of more accessible (and more structured) 
content, but in the production of more enlightened authors, as well...  if
accessibility isn't addressed in each and every applicable instance in the
help files and documentation that accompanies the tool, the implicit
message is:  accessibility is a quote worthwhile unquote consideration,
and there exist methods of making ubiquitous mark-up accessible, but these
built-in features of the markup are not really as important as the rest of
the quote hardcore unquote markup and output with which ninety percent of
your users will interact...

how can we condone, let alone give our stamp of approval to, a tool which
shows how to construct a form or table _without_ including the
accessibility features associated with such elements as part-and-parcel of
what constitutes a form or a table?  if we leave the current 2.7.1 as-is,
and the current 2.7.2 a p2, we doing just that...

therefore, i simply cannot see how one could possibly justify according
the current 2.7.1 priority 1 status, whilst according the current 2.7.2 a
priority 2

gregory.

  ------------------------------------------------------------------
                Gregory J. Rosmaita <oedipus@hicom.net>
  Camera Obscura:           http://www.hicom.net/~oedipus/index.html
  VICUG NYC:          http://www.hicom.net/~oedipus/vicug/index.html
  Read 'Em & Speak:   http://www.hicom.net/~oedipus/books/index.html
  ------------------------------------------------------------------

Received on Wednesday, 21 April 1999 19:47:21 UTC