WCAG 2.0 Comment Submission

Name: Roger Hudson
Email: rhudson@usability.com.au
Affiliation: 
Document: W2
Item Number: Success Criterion 1.3.1
Part of Item: 
Comment Type: TE
Comment (Including rationale for any proposed change):
It appears that SC 1.3.1 encompasses many separate guidelines that were specified in WCAG 1.0, including the requirement to associate data table cells with the appropriate row and column headings and requirements relating to the labelling and grouping of form controls. I presume part of the reason for combining such a diverse range of accessibility needs in single success criteria is the desire to have criteria that are \"technology-independent\".



In my experience, a lage proportion of the problems assistive technology users now experience when using web sites result from the sites failing comply with the WCAG 1.0 guidelines that are now nominally covered by SC 1.3.1. Nearly all web content is currently presented using (x)html and this is likely to continue to be the case for the foreseeable future. However WCAG 2.0, which is the normative document, provides web developers with no practical guidance or clues in how to avoid these problems.



The link \"How to meet 1.3.1\" leads to information in the \"Understanding WCAG 2.0\" document, which describes techniques for addressing the criterion. The \"Understanding\" document contains links to eleven HTML techniques, which are presented in yet another document, \"Techniques for WCAG 2.0\".



Frankly, I don’t imagine many developers when faced with the prospect of preparing a data table will bother to troll through three documents in order to see why it is important to associate data cells with row and column headers in a non-visual way. On a related point, why don’t the \"Understanding WCAG 2.0\" HTML Techniques include the need to use TH for tables with single levels of row and column headers?



I am concerned that the failure to provide guidance in relation to crucial html issues in the WCAG 2.0 document will lead to a decline in awareness on the part of developers regarding their importance and this will contribute to a fall in the overall accessibility of websites and the web as a whole.



I believe the Working Group should get over their hang up with developing some sort of technology neutral standard and recognise that the way to bring the greatest accessibility gains to the greatest proportion of web users is by providing practical advice in how to improve the accessibility of (x)html sites. 



Proposed Change:
In my view, WCAG 2.0 Guideline 1.3 should include success criteria for the specific issues that are addressed in the following WCAG 1.0 Checkpoints: 3.1, 3.5, 3.6, 5.1, 5.2, 5.5 and 12.4.



Since this is unlikely to happen, I would like to urge the Working Group to consider providing HTML example for each of the issues covered by the checkpoints above in the core WCAG 2.0 document so that SC 1.3.1 is able to provide the majority of web developers with a clear indication of how to meet this criterion.

Received on Sunday, 14 May 2006 00:26:11 UTC