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

Re: Proposed changes to structure

From: Daniel Dardailler <danield@w3.org>
Date: Mon, 04 Jan 1999 11:04:04 +0100
Message-Id: <199901041004.LAA14792@www47.inria.fr>
To: Charles McCathieNevile <charles@w3.org>
cc: WAI AU Guidelines <w3c-wai-au@w3.org>

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 05:04:10 GMT

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