Re: persistent QA problems with the W3C Validator

aloha, terje!

thank you for your quite complete response -- since you indicated 
that you could effect some changes this weekend, i will not attempt 
to reply to your emessage in its entirety, but to hit upon 3 
crucial issues...  i will endeavor to respond to your reply in full 
over the weekend or early next week, depending on time 
constraints...

TB1: The layout of the Validation Results page has changed yet again 
since your last comments. During this process, the indication of 
validity, or lack of it, was moved to the very beginning of the 
page. This was specifically to address your concerns. It was later 
moved away from there due to feedback indicating that it represented 
a usability problem for sighted users and because the accessibility 
gains for speech-output users as a result of the previous change 
were judged to be not very great.

GJR1: all i've ever wanted in this regard is the addition of a link 
in the "Jump to:" section, that would allow the user to jump right to 
the line "Below are the results of attempting to parse this document 
with an SGML parser" -- translated into code this would mean:

  <p>
    Jump to: <a href="#results">Results</a>, <a 
      href="#outline">Outline</a>, <a
      href="#source">Source Listing</a> or <a
      href="#parse">Parse Tree</a>.
  </p>
<!-- FORM markup skipped -->
  <p><a id="results" name="results"></a>
    Below are the results of attempting to parse this document with
    an SGML parser.
  </p>

and, while it is true that LABELs have been added to the form located 
at:
   http://validator.w3.org/
there are still no LABELs on the form that is included on the results 
page (that is, the page that appears after the validator has performed 
its analysis)

as for the markup used on http://validator.w3.org/, there is one 
correction -- the "Options" grouping of checkboxes comprise a 
FIELDSET, which means that you should use the FIELDSET, LEGEND, 
and LABEL elements in order to correctly reflect the relationship 
between the form controls and their labels, as well as the form 
controls and the meta-grouping indicated in the markup below as a 
FIELDSET:

<!-- extant source -->
          <tr>
            <th rowspan="2">Options:</th>
            <td><label><input name="ss" type="checkbox" value="" /> Show Source</label></td>
            <td><label><input name="sp" type="checkbox" value="" /> Show Parse Tree</label></td>
          </tr>
          <tr>
            <td><label><input name="outline" type="checkbox" value="" /> Show Outline</label></td>
            <td><label><input name="noatt" type="checkbox" value="" /> ...exclude attributes</label></td>
          </tr>

<!-- proposed source -->

<fieldset>
  <tr>
  <th rowspan="2"><legend>Options:</legend></th>
  <td><label for="output1"><input name="ss" id="output1" type="checkbox" value="" /> Show Source</label></td>
  <td><label for="output2"><input name="sp" id="output2" type="checkbox" value="" /> Show Parse Tree</label></td>
  </tr>
  <tr>
  <td><label for="output3"><input name="outline" id="output3" type="checkbox" value="" /> Show Outline</label></td>
  <td><label for="output4"><input name="noatt" id="output4" type="checkbox" value="" /> ...exclude attributes</label></td>
  </tr>
  </fieldset>

why?  otherwise, when tabbing through the grouping, the speech user 
will not be aware that the checkboxes in question belong to the 
"Options" grouping, something currently indicated through physical 
proximity only... (the 2 major windows-based screen readers, as well 
as IBM's HomePage Reader recognize this markup, but only where a 
for/id relationship between a LABEL and a form control exists)

i would also VERY strongly advocate for the addition of accesskeys to 
each form control -- the safest bet is to use numeric accesskeys, 
although mnemonic accesskeys are, at least in my opinion, easier to 
remember -- the suggested accesskeys reflect the tab-order of the form:

Address - accesskey = 1 (or "a")
Character Encoding - accesskey = 2 (or "c")
Document Type - accesskey = 3 (or "d")
Options (appended to encasing LEGEND) - accesskey = 4
   [note: not all accesskey implementations recognize accesskeys
   appended to LEGEND, so this could be bypassed PROVIDED that 
   the FIELDSET and LEGEND markup is used to indicate (a) a 
   grouping of related controls and (b) the purpose of the 
   grouping (i.e. the LEGEND) - if you decide not to add an 
   accesskey to the LEGEND, then subtract one from the following 
   numeric values]
Show Source - accesskey = 5 (or "s")
Show Outline - accesskey = 6 (or "o")
Show Parse Tree - accesskey = 7 (or "p")
...exclude attributes - accesskey = 8 (or "e")
Validate this page button - accesskey = 9 (or "V")

if you do decide to add accesskeys, they should be:

a) documented in the validator's "help" file;
b) be consistent throughout the validator.w3.org sub-domain; and
c) explicitly expressed in each form control's markup, using the "title" 
   attribute, e.g.:

 <th><label for="doctype">Document Type:</label></th>
 <td colspan="2">
 <select id="doctype" name="doctype" title="Document Type (accesskey: 3)">

note that, while it is "legal" to append an accesskey to a LABEL, the 
current state of support is far more robust for accesskeys appended 
directly to the form control itself...

TB2: If you could suggest some appropriate venues for soliciting help 
with improving the Accessibility of the Validator I'd appreciate it. 
I'm not in a position to pay anywhere near normal rates for such 
consultancy -- I'm a private individual with no access to any coffers 
the W3C may have for such eventualities -- but I should be able to 
give proper credit for such contributions on the web site, and I may 
be able to pay some symbolic fee out of my own pocket.

GJR2: during the testing/implementation stage, you should solicit the 
opinion of the subscribers to wai-xtech@w3.org, which is the emailing 
list where the work on reformatting the W3C mail archives, amongst 
other things, transpires - WAI-Xtech is a cross-working group mailing 
list, where issues that affect all of the WAI working groups are 
discussed, thereby eliminating (or at least reducing) cross-posting 
to individual WAI working group lists...  this means that you will be 
able to pick the brains of members of the Protocols & Formats, 
Authoring Tool, User Agent, Evaluation & Repair, Web Content 
Accessibility, and Education & Outreach working groups in one fell 
swoop...  once you have implemented the fixes, then send email to 
wai-ig@w3.org, the WAI Interest Group list, announcing the changes 
and soliciting feedback...  that being said, the individuals whom you 
cited as having provided feedback/advice in your reply are ALL 
excellent resources...

i personally would like to volunteer to oversee accessibility issues 
with the validator, but unfortunately health problems preclude me 
from making such a running commitment at the present time...

thank you, terje, very much for your conscientious attention to these 
concerns, and the work and effort you have already put into ensuring 
that the first step towards constructing accessible documents -- the 
use of valid markup -- is accessible to all...  again, i will address 
the other issues you raised in another emessage...

thank you again for your work, your time, and your patience,
gregory.

------------------------------------------------------------------
ACCOUNTABILITY, n.  The mother of caution.
                          Ambrose Bierce, _The Devil's Dictionary_
------------------------------------------------------------------
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
------------------------------------------------------------------
-------------------
Email sent using AnyEmail from http://www.hicom.net

Received on Friday, 7 June 2002 17:27:37 UTC