Re: Suggestions

> Item-1. Advancing the Art and Science of Accessible Web
> Design
.. 
> The main point of this discussion is that we need to provide
> information that will help Web developers select a method
> that will be successful in achieving these outcomes.

The intent of the split guideline/technique is to provide some kind of
"selection method" to implement each guideline: a list of possible
fixes. I'm not sure a better paradigm can be devised given the
contextual dependency on each technique applicability.

> Item-2. An Automated Tool

http://www.cast.org/bobby ?

> Item-3. Represent Material to Support Diverse Queries or
> Compilations

We talked some about that a while ago, where it was question to have
guidelines organized by browser compatibility, but it didn't
concretize. Too much back-office-brain power needed I guess.

> Item-4. Only the Guideline Statements Should Be Normative 
> 
> I suggest that the working group seek W3C approval only for 
> the guideline statements (A.1 through B.3.). Everything else
> would be non-normative and therefore changed more readily.
> (The W3C might require that the title a very brief statement
> of purpose and scope also be among the normative portion.)

Yes, I suggested that too, make the technique document a non-normative 
annex.
 
> Item-5. Eliminate the Distinction Between "A" and "B"
> Sections

Yes to this one as well, I don't think the current separation brings
in much.
 
 
> Item-9. A Quick Analysis Information Attached to the
> Guideline Statements of the WAIGL-PA
> 
> How hard would it be to automatically compile a document
> like the WAIGL-PA document? What are the major pieces of
> data that are involved? 

Without looking at automatic generation as the only goal, trying to
formalize the guidelines structure a little more might be helpful.

But this might go against your earlier argument in favor of shortness
of normative the guideline info.

> 
> Item-10. Inclusion of Exceptions

A good improvement.
 
> Item-11. Advantages of Automatic Compilation of Documents
> Representing Diverse Views and Perspectives

No question about that.
 
> Item-12. Some Different Perspectives and Views
 
Good list, should go to the EO group (I will forward it there, check
w3.org/WAI/EO for followup)

> Item-13. Orientation to "Products and Services"
> I suggest considering orienting the guidelines around the
> concept of improving the accessibility of "Web-based
> products and services" (rather than of "pages" or "sites"). 
> Isn't it the services and products that need to be
> accessible? Who knows how relevant the term "page" will be
> in a few years? The term "Web site" seems all the more
> problematic. I have not thoroughly examined the implications
> of a wholesale change. Perhaps even a partial shift in that 
> direction would be helpful. (See my revised Abstract for the
> WAIGL-PA document.)

I still favor "Content" over Product & Service, Page and Site, etc.

> Item-14. Make Guidelines One Sentence Long
> 
> I recommend that all guidelines be one sentence long.
> Guideline A.14 is currently two sentences long and reads:
> "Wherever possible use a W3C technology in accordance with
> guidelines on its proper use. Where this is either not
> possible, or results in material that does not transform
> gracefully you must provide an alternative version of the
> content that is accessible." I suggest reducing it to one
> sentence or splitting it into two guidelines. All other
> guidelines are one sentence long.
..
> #1. "Use W3C technology in accordance with guidelines on its
> proper use."
..
> #2. "When material that does not transform gracefully, then 
> provide an alternative version of the content that is
> accessible." 

Yes, it could indeed be splitted in two, along the lines

 - use latest W3C format (HTML4 with CSS)
 - for non W3C format, provide alternative representations so that no
   information is lost when data is inaccessible, unsupported, or turned off. 

 
> Item-15. Refine the Abstract
> 
> Following is a partial rewrite of the first paragraph of the
> Abstract of the WAIGL-PA.
> 
> "This document is a list of guidelines that developers of
> Web-based products and services should follow in order to
> make their pages more accessible to people with disabilities
> and more usable by both disabled and nondisabled people
> operating in variety situations and using a variety of
> technologies. For example, following these guidelines is
> expected to improve usability by people (a) who use new page
> viewing technologies (mobile and voice), (b) who rely
> heavily on search technologies, (c) who use older browser or
> modem technologies, (d) who are unfamiliar with the language
> of the content, or (e) who are operating in hand-free,
> noise-free, or sight-free environments.

As I said in a prior posting to this list, putting the emphasis on the
non disability market first is a better option (first mobile and web
phone, e.g. temporary visual impairment, then permanent visual
impairment: blind users) 
 
> Item-16. Why Refer to Issues Not Addressed?
> 
> Why refer to issues that are not addressed (economic, legal,
> cultural, etc.)?  

where exactly ?

> Item-18. Some Thoughts on the Name of the WAIGL-PA Document
> 
> I think that the current name is OK, though as noted
> elsewhere in this document the use of the term "page" seems 
> a bit archaic.
> 
> I am against using the term "universal design" in the title.
> "Universal design" -- i.e., usability by everyone everywhere
> -- is a great design objective, but it suggests a note of
> impracticality and also, in the minds of some, the phrase
> may carry other meanings that we might not want associated
> with the guidelines. 

Can you elaborate on the "impracticality" and the "other meaning"
aspects ?

> Besides, the document does not deserve 
> the title because no where does it acknowledge the wide
> range of considerations that should go into the design of
> accessible and cost-effective Web-based products and
> services.

These guidelines promote the design of web content so that it can be
accessed no matter what operating system, device, or modality of user
interface one has, hence the universality.

In which way are we not considering enough universality in the
design (given our limited context of web content production) ?

> Item-19. Should B.3 and A.7 Be Combined in Some Way?
> 
> I wonder if B.3 and A.7, both of which related to language, 
> be combined in some way?

A.7 is really about machine comprehension (if you don't have the lang
attribute indicating the language of the content, voice output can be
messy) whereas B.3 is about human comprehension (consistency, simple
icons, etc), for learning disability for instance.

The term language used in both cases in confusing I agree. How about
"Use terms and formats that facilitate comprehension of information"
for B.3 ?


> Item-20. "[P]ronounce or interpret ... foreign text"
> 
> Should A.7 be revised to change the word "foreign" to
> "unfamiliar"?

No, again, it's for the machine to parse, not the human.

Received on Friday, 4 December 1998 11:06:26 UTC