W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 1999

Re: Proposed changes to structure

From: Wendy A Chisholm <chisholm@trace.wisc.edu>
Date: Mon, 04 Jan 1999 15:07:21 -0600
Message-Id: <199901042110.PAA04288@trace.wisc.edu>
To: w3c-wai-au@w3.org
I like the structure as well and agree with Daniel's suggestions for
tightening up the organization.

--wendy

At 04:04 AM 1/4/99 , you wrote:
>
>I also prefer this new flatter structure, I'll add a few comments to
>make the bulk section (2) even shorter.
>
>> * 2 Ensure content generated is accessible
>>   + 2.1 Generate standard markup
>>   + 2.2 Support all accessible content recommendations
>>   + 2.3 Identify all inaccessible markup [was 2.5]
>>   + 2.4 Provide mechanisms for authors to add missing alternative
>>     representations for the content of converted documents [was 2.6]
>>   + 2.5 Provide comprehensive accessibility help to authors [was 3.1]
>>   + 2.6 Package multimedia files with pre-written descriptions [was 3.3]
>>   + 2.7 Integrate accessibility solutions into relevant automated tools
and 
>>     wizards [was 4.1]
>>   + 2.8 Allow the user to check for and correct accessibility problems 
>>     automatically [was 4.2]
>>   + 2.9 Ensure that all markup inserted by the authoring tool is
accessible 
>>     [was 4.3]
>>   + 2.10 Ensure that conversion tools produce and retain accessible markup 
>>     and content [was 4.4]
>>   + 2.11 Offer text representations of site maps [was 5.3]
>>   + 2.12 Emphasize accessible authoring practices [was 2.4]
>
>Some look duplicates to me.
>2.3 and 2.8 for instance.
>
>2.4 seems like it's a technique (applied to Word Processor kind of
>tool) more than a guideline. 
>
>2.7 is really a specialization of 2.1 and 2.2 (i.e. it's already
>included in these 2 guidelines). Same for 2.9.
>
>I'd put the emphasis for 2.10 on the "retain" side (the produce side
>is already in other guidelines)
>  Never remove existing accessible structure 
>
>2.11 (textual site map) is just one aspect of other guidelines, I
>don't see why we need to put it forward as a first class guideline.
>
>I would add 
>  Allow for user configuration (never force user, provide different mode)
>
>So to summarize, my table of content for section 2 would be:
>
>* 2 Ensure content generated is accessible
>   + 1 Generate standard markup (for save-as HTML function as well) 
>   + 2 Support all accessible content recommendations (latest HTML and CSS)
>   + 3 Provide comprehensive accessibility documention (help, examples, etc)
>   + 4 Package multimedia files and clipart images with pre-written
descriptions
>   + 5 Provide integrated checker and validator (alert box, one-pass, etc)
>   + 6 Never remove existing accessible structure 
>   + 7 Emphasize accessible authoring practices (CSS for font change, etc)
>   + 8 Allow for user configuration (never force user, provide different
mode)
> 
Received on Monday, 4 January 1999 16:10:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:52:54 GMT