W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > July 2004

WCAG2.0 suggestions

From: Jeroen Visser [ vizi ] <j.visser@vizi.nl>
Date: Sat, 03 Jul 2004 18:27:09 +0200
Message-ID: <40E6DE5D.3060505@vizi.nl>
To: Gregg Vanderheiden <gv@trace.wisc.edu>
Cc: public-comments-wcag20@w3.org

Gregg Vanderheiden wrote:
>  Will be looking at your other comments as well.  They are quite good.   We
> do have to stay on the accessibility side of the usability / accessibility
> continuum.    
> If you have any specific wording suggestions - we would like to hear those
> as well.  

Hello Gregg (and all other WCAG people),

Sometime in April/May I offered you to read the working draft of WCAG2.0 
  and send you my suggestions. It has taken me some time to actually 
deliver on my promise, but here we go: my two cents. I've read the 
internal (June 2nd) version.

Overall, I think it's a very clear and readable document. Web developers 
generally should have no problems when checking their sites against 
these guidelines.

My suggestions on specific issues:

--- ---
1.4 In visual presentations, make it easy to distinguish foreground 
words and images from the background.

At the level 2 success criterium you state to seek an algorithm to make 
the guideline testable. I suggest to take the lightness channel of a Lab 
screendump as a starting point. In photography, transforming an RGB 
image to Lab and subsequently using the lightness channel to get to a 
black-and-white image has proven to give better (more dependable) 
results than simply grayscaling an image. Basically, you get more 
accurate contrast information using this technique. More on this 
technique is available on <http://www.designbyfire.com/000100.html> 
(scroll down to "The Rob Carr Color to B&W Conversion Technique").

I can imagine the WCAG algorithm to be something like this:
1 Take an RGB screendump of the page under consideration.
2 Convert to Lab color in PS.
3 Select only the lightness channel and convert to grayscale.
4 Measure text (foreground) and background lightness level using the 
color picker.
5 Check if the difference between these two numbers is greater than X%.

I see two problems with this algorithm, though:
- It requires Photoshop. This may not be an issue really, because the 
majority of web developers uses Photoshop anyway.
- It should be tested that the contrast in a transformed screendump 
actually is comparable to the original. Maybe showing both versions of a 
number of web sites to a color blind person would be a sufficient test, 
but I'm not sure about that.

Plus, but this is not dependent on this specific algorithm:
- How do you determine what is an acceptable contrast ratio (the X)? To 
illustrate this: <http://superfluousbanter.org/archives/000194.php>

[The above considerations also apply to the second level 3 succes 
criterium. Lightness in a Lab image is more dependable than grayscaling 
to assess foreground-to-background contrast.]

--- ---
2.4 Facilitate the ability of users to orient themselves and move within 
the content.

The editorial note on 'logical tab order' says that '"logical tab order" 
may not be testable.' Maybe 'clear' is a better (but still not testable) 
way to describe this criterium. Or set a measure for usability testing: 
"the tab order is as expected by 80% of the test subjects".
An example may clarify this enough: tab order 1-10 for a list of 
products on a shopping site, or tab order 1-7 for seven questions (form 
fields) in an online survey.

Maybe it's also needed to make a clear distinction in purpose between 
tab order and accesskeys. The former would (as I see it) apply to 
list-types of information, whereas the latter should be reserved for 
main menus and other sitewide controls (privacy and accessibility 
statement, sitemap, disclaimer). There's no need to 'tab' every single 
hyperlink, as this tabbing is part of most (if not all) UA interfaces.

--- ---
2.5 Help users avoid mistakes and make it easy to correct them.

I'm concerned about 'checks for misspelled words' being a level 3 
success criterium. I think this ought to be more in the direction of the 
second level 2 criterium: any web application requiring user input 
should have a solid error handling, guiding the user if his or her input 
is not understood or is not valid. For instance: if I misspell a train 
station's name in an online scheduler, the site should not correct the 
misspelling, but should return all train stations which are close to my 
input, with the most probable station already highlighted. This type of 
'spelling correction' would make for a more usable site than barebobe 
spell checking alone.

--- ---
3.1 Ensure that the meaning of content can be determined.

Under 'verbs' (level 3 success criteria) there's no further explanation.
Is this intended or do I miss a chunk of text here? :-)

--- ---
3.2 Organize content consistently from "page to page" and make 
interactive components behave in predictable ways.

Alternative wording: "Organize content consistently across the [entire] 

---------- ---
Appendix A Glossary

Content: "All explicit and implicit information present in a document."

I hope my suggestions and remarks will prove to be a useful contribution 
to the guidelines. If you have any questions, please contact me. I would 
be happy to clarify more, or to discuss an issue with you.

With regards,

Jeroen Visser

vizi fotografie & grafisch ontwerp

I  http://www.vizi.nl/
Received on Saturday, 3 July 2004 12:27:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:36 UTC