Re: minority opinions

Jutta wrote:
>In preparing last call documents we discovered that what we called
>"minority opinions" in our group are actually "resolutions that were not
>unanimous." Minority opinions are opinions that would stop the document
>from going forward. Therefore, our previous "minority opinions" will be
>labeled as "resolutions that were not unanimous" in the supporting
>documents, with discussion of counter opinions.
>
>Does anyone have questions or concerns about this?

aloha, jutta!

i suppose that it is now too late to affect the presentation of the material
that was submitted to tim this morning, but (a) my phone line has been dead
since friday morning, so my ability to get online has been extremely spotty and
(b) i definitely think that the question as to whether the guideline which
addresses the accessibility of the tool itself should be the first or the last
guideline in the ATAG is (at least in my dissenting opinion) most definitely a
"minority opinion", and not merely a "resolution that was not unanimous"

and, while i did not -- and do not -- think that the issue was one that fatally
compromises the document (as a Priority 1 checkpoint is a Priority 1
checkpoint, no matter where it appears in the document), i do believe that it
was a grave error of judgement to place the accessibility of the tool at the
back of the bus, especially since the testing of various tools that i've been
performing for the past few months clearly indicates that -- of all the
guidelines in the document -- the guideline which the current crop of authoring
tools are furthest from satisfying is the guideline which addresses the
accessibility of the tool itself...

i also (still) take great umbrage at the justification which was advanced by
those who advocated moving the guideline from the beginning of the document to
the end -- after listening to all of the arguments advanced by those who
advocated moving the guideline, i am still convinced that it was done so, if
not to sweep it under the rug, then to place it on the back burner of any
development team who takes the time to read the ATAG, simply because the issue
it addressed is so sweeping in scope and because of the programmer-hours that
may be necessary in order to satisfy the guideline...

the accessibility of an application is a first principle of software design,
and as such, should be addressed up front...  why, because true accessibility
is achieved during the planning process, and built into the tool from the
ground up, not retrofit afterwards, in order to achieve the type of
trickle-down accessibility which is highly reliant upon assistive technology to
cover the shortcomings of the application itself, but which is still deemed by
those without a disability as "acceptable"

again, i ask everyone who voted to move the guideline that covers the
accessibility of the tool itself to turn off their monitors, unplug their mice,
and fire up a screen reader -- then let me know whether or not you can build
even a simple page using the tool of your choice

i promised myself that i wouldn't wax rhetorical on the subject, having done so
on list in the past [1], but this issue cuts to the heart of the matter, and i
am still concerned that the placement of the guideline addressing the
accessibility of the tool at the end of the document sends the wrong
(subliminal) message to developers -- "here is a list of the important things
you need to fix right now if you want to sell your products to any governmental
entity that has a directive mandating that software purchases should take
accessibility into consideration, and -- oh, yeah -- here is a really general
blanket statement that you can attend to when (and if) you have the time after
you address all the others..."

a paranoid delusion you say?  then why has the working group been repeatedly
asked to split the document into 2 documents (one which would address the
accessibility of the output and one which would address the accessibility of
the tool itself), even long after it became a mantra that the charter demanded
that we address both issues in the same document...  and what is the recently
resurfaced request for a conformance level that excludes the issue of whether
or not the tool is accessible to individuals with disabilities other than a
"kinder, gentler" attempt to undermine the guideline that mandates that it is
not enough that the tool produces accessible content, and guides the author
towards the use of accessible authoring practices, but that the tool itself
must also be accessible?

yes, i know that checkpoint 7.1 is rated Priority 1, and that it binds
developers no matter where it appears in the document, but i am still deeply
troubled by the message that moving the current guideline 7 to the rear of the
document sends, and the motivations underlying the move...

therefore, jutta, i'd ask that -- on this issue at least -- that the votes
against moving the guideline from the front to the back be considered a very
strong minority opinion, and not just a resolution that was not unanimous...

gregory

Utterly Superfluous References
[1] my past posts to AU on the topic of why the current GL7 should be the first
GL to appear in the ATAG:
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0140.html
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0086.html
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0183.html
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0189.html
--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
   WebMaster and Minister of Propaganda, VICUG NYC
        <http://www.hicom.net/~oedipus/vicug/index.html>
--------------------------------------------------------

Received on Monday, 25 October 1999 15:35:45 UTC