Re: Your comments on WCAG 2.0 Last Call Working Draft of December, 2007

[To: public-comments-WCAG20@w3.org; BCC: BenToWeb Consortium]

After discussion on the BenToWeb mailing list, 
the consortium is satisfied with all the responses except for the following:
Comment 3: contrast algorithm for 1.4.3: Contrast (Minimum)
Source: 
<http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0084.html>
(Issue ID: 2535)

The original comment was based on research that 
is reported in a project deliverable at 
<http://webcc.fit.fraunhofer.de/downloads/projects/bentoweb/deliverables/BenToWeb_D3.5_rev.pdf> 
but which was not yet publicly available when the original comment was written.

This research investigated equations for 
calculating colour contrast and appropriate minimum levels of contrast.
Four diferent sets of equations were investigated:

* WAI Accessibility Evaluation and Repair Tools 
(Ridpath and Chisholm, 2000), brightness equations ("AERT/B"),

* WAI Accessibility Evaluation and Repair Tools 
(Ridpath and Chisholm, 2000), colour contrast equations ("AERT/CC"),

* W. S. Thune (2003) [3] has provided a series of 
equations, known as the Catman equations, using 
linear, quadratic and cubic functions (Catman1, Catman2, Catman3),

* WCAG 2.0 ­ Working Draft 17 May 2007: contrast ratio definition (WCAG2).

No evidence-based support for these ratios and 
equations could be found in the literature. (The 
references in Understanding SC 1.4.3 [4]) mostly 
predate WCAG 1.0; it is not clear from the text 
whether any of these references is the source of 
the proposed colour contrast equation or not.)

As providing user evidence from across the entire 
colour spectrum could require a very large amount 
of user testing, it was decided to use a sample 
of colour combinations that are commonly used on 
the Web for text and background combinations. 
Therefore a survey of 100 popular and important 
websites was undertaken to provide information 
about common colour combinations and the 12 most 
popular combinations were used in the main 
testing. This set of combinations was 
supplemented with a number of subcombinations, 
which resulted in a total of 54 combinations (see 
3.4.4 - Colour combinations used in stimuli). 
These were presented in a random sequence.

In the user testing, 165 people with full colour 
vision each viewed 54 simple web pages showing a 
single sentence in one colour on a different 
coloured background (more details on the 
methodology can be found in chapter 3 of the 
report). Effects of font type and size were also 
investigated by presenting the sentences in 
either Arial (a sans serif font) or Times New 
Roman (a serif font) and in either 10, 12 or 14 
point. Participants were asked to rate how easy 
the sentence was to read on a 1-5 Lickert scale and to comment on their rating.

Font type and size, as varied in this study, had 
little impact on the results, accounting for only 
4% of the variance in user ratings.

Colour contrast accounted for approximately 
20-40% of the variance (a significant and 
substantial proportion), depending on the 
equations used. (A series of non-linear 
regressions was conducted, using the different 
equations to predict the ease of reading ratings. 
In each case, linear, quadratic, and cubic 
equations were used in the prediction, to 
investigate which form of relationship accounted 
for the greatest proportion of the variance. 
Table 4.1 in the report summarizes the results of 
the regressions.) The equation which accounted 
for the greatest proportion of the variance in 
user ratings was the AERT/B equation when used in 
a cubic relationship to user ratings.

Using this equation, thresholds for adequate 
contrast between text and background were 
calculated, and the appropriateness of the 54 
colour combinations used in the experiment 
calculated to provide initial examples of good and bad contrast.
Section 4.4.4 - Readable threshold values - 
contains thresholds for each of the equations. 
The "readable threshold value" for AERT/B is 
66.8; the "highly readable threshold value" is 85.5.


[1] <http://www.w3.org/TR/WCAG20/#contrast-ratiodef>

[2] <http://www.w3.org/TR/AERT#color-contrast>

[3] Originally availabe at 
<http://www.iastate.edu/~class.12003.engl.313/cps/contrast.html> 
(URL is now dead); now at 
<http://www.public.iastate.edu/~class.12003.engl.313/cps/contrast.html>.

[4] 
<http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20071211/complete.html#visual-audio-contrast-contrast>

Best regards,

Christophe Strobbe
on behalf of BenToWeb


PS: Apparently, ANSI/HFS 100-1988, American 
National Standard for Human Factors Engineering 
of Visual Display Terminal Workstations  has been 
replaced by "ANSI/HFES 100-2007, Human Factors 
Engineering of Computer Workstations" 
<http://www.hfes.org/Publications/ProductDetail.aspx?ProductId=69>.

At 02:18 11/03/2008, Loretta Guarino Reid wrote:
>Dear Christophe,
>
>Thank you for your comments on the 11 Dec 2007 Last Call Working Draft
>of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
>http://www.w3.org/TR/2007/WD-WCAG20-20071211). The WCAG Working Group
>has reviewed all comments received on the December draft. Before we
>proceed to implementation, we would like to know whether we have
>understood your comments correctly and whether you are satisfied with
>our resolutions.
>
>Please review our resolutions for the following comments, and reply to
>us by 31 March 2008 at public-comments-wcag20@w3.org to say whether
>you accept them or to discuss additional concerns you have with our
>response. Note that this list is publicly archived.
>
>Please see below for the text of comments that you submitted and our
>resolutions to your comments. Each comment includes a link to the
>archived copy of your original comment on
>http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may
>also include links to the relevant changes in the WCAG 2.0 Editor's
>Draft of 10 March 2008 at
>http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20080310/.
>
>Note that if you still strongly disagree with our resolution on an issue,
>you have the opportunity to file a formal objection (according to
>3.3.2 of the W3C Process, at
>http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
>to public-comments-wcag20@w3.org. Formal objections will be reviewed
>during the candidate recommendation transition meeting with the W3C
>Director, unless we can come to agreement with you on a resolution in
>advance of the meeting.
>
>Thank you for your time reviewing and sending comments. Though we
>cannot always do exactly what each commenter requests, all of the
>comments are valuable to the development of WCAG 2.0.
>
>
>Regards,
>
>Loretta Guarino Reid, WCAG WG Co-Chair
>Gregg Vanderheiden, WCAG WG Co-Chair
>Michael Cooper, WCAG WG Staff Contact
>
>On behalf of the WCAG Working Group
>
>----------------------------------------------------------
>Comment 1: H36: Using alt attributes on images used as submit buttons
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0082.html
>(Issue ID: 2533)
>Status: VERIFIED / ACCEPTED
>----------------------------
>Original Comment:
>----------------------------
>
>When we developed test case sc1.1.1_l1_240 [1], we discovered that
>the test procedure defines no requirements for the alt text. The
>description states: "This label indicates the button's function, but
>does not attempt to describe the image." However, the test procedure
>only checks for the presence of the alt attribute.
>
>Proposal:
>
>* Add a second step: "Check that the alt attribute indicates the
>button's function."
>
>* Update the expected results: "#1 and #2 are true".
>
>(This comment was previously submitted at
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Sep/0003.html.)
>
>[1] http://bentoweb.org/ts/XHTML1_TestSuite3/metadata/sc1.1.1_l1_240
>
>Christophe Strobbe
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>We have changed the test procedure as proposed.
>
>----------------------------------------------------------
>Comment 2: G14: Does example 2 fail the success criterion?
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0083.html
>(Issue ID: 2534)
>Status: VERIFIED / ACCEPTED
>----------------------------
>Original Comment:
>----------------------------
>
>When we evaluated test case sc1.4.1_l1_011 [1] for technique G14, we
>thought that the second example in that technique fails the success
>criterion. The example describes the use of text alternatives on
>colour icons (for coding the tracks in a conference). The text
>alternative is not good enough (as the test procedure points out)
>because that is conditional content; the SC requires that the
>colour-coded information is "simultaneously visually evident". That
>is not the case for alternative text.
>
>So example 2 appears to fail both the test procedure and the success
>criterion.
>
>Proposal:
>
>Remove example 2 (or modify it?).
>
>[1] http://www.bentoweb.org/ts/XHTML1_TestSuite3/metadata/sc1.4.1_l1_011
>
>Best regards,
>
>Christophe Strobbe
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>Thank you. We had modified the Success Criterion but didn't catch the
>example. We have removed the example.
>
>----------------------------------------------------------
>Comment 3: contrast algorithm for 1.4.3: Contrast (Minimum)
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0084.html
>(Issue ID: 2535)
>Status: VERIFIED / PARTIAL/OTHER
>----------------------------
>Original Comment:
>----------------------------
>
>Success criterion 1.4.3 relies on an algorithm
>for relative luminance [1] that is different from
>the algorithm in the draft for "Techniques For
>Accessibility Evaluation And Repair Tools" [2].
>Research in BenToWeb investigated four different
>formulas for calculating colour contrast:
>
>* WAI Accessibility Evaluation and Repair Tools
>(Ridpath and Chisholm, 2000), brightness equations ("AERT/B"),
>
>* WAI Accessibility Evaluation and Repair Tools
>(Ridpath and Chisholm, 2000), colour contrast equations ("AERT/CC"),
>
>* W. S. Thune (2003) [3] has provided a series of
>equations, known as the Catman equations, using
>linear, quadratic and cubic functions (Catman1, Catman2, Catman3),
>
>* WCAG 2.0 ­ Working Draft 17 May 2007: contrast ratio definition (WCAG2).
>
>AERT/B turned out to be closer to real user
>experience (based on user testing) than the other
>algorithms. User testing led to the
>recommendation of a brightness difference of at least 66.8.
>
>[1] http://www.w3.org/TR/WCAG20/#contrast-ratiodef
>
>[2] http://www.w3.org/TR/AERT#color-contrast
>
>[3] http://www.iastate.edu/~class.12003.engl.313/cps/contrast.html
>
>
>Best regards,
>
>Christophe Strobbe
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>All of the algorithms will look better for one sample vs another.
>Since the old formula was non-linear, it is likely to be better for
>some samples and not for others.   We tried to look at the study you
>cite, but it appears to be a student project and it is no longer
>available.  So, we cannot comment on it.
>
>Some more specific notes on the new and the old algorithms.
>
>The WCAG 2.0 contrast algorithm does not test for good color
>combinations, just for those combinations with sufficient contrast
>(based on brightness or relative luminance). The new WCAG 2.0
>algorithm was chosen because it is much more consistent in its
>results. For one thing the old algorithm was calculated in non-linear
>color space while the new algorithm is calculated in in linear terms.
>There is no way to correctly calculate contrast in non-linear space.
>It will give you irregular results (good results in some areas of the
>color space and bad results in others). The new WCAG 2.0 rule also is
>based on luminance contrast alone - whereas the old measure included
>color contrast as well. This causes the old algorithm to fail things
>that have plenty of visual contrast for people with all types of color
>limitation. For example some color combinations will fail the old tool
>even though they are eminently readable and have a luminance contrast
>of 15:1 or more (where 21:1 is pure black on white). Very dark
>charcoal gray on yellow (contrast ratio of 16:1) would fail the old
>algorithm. 100% green on black (same as old CRTs) (contrast ratio of
>15:1) would also fail the old algorithm.
>
>Having said all that, the new contrast ratio was chosen to be somewhat
>less stringent than the old - in order to provide a larger color
>palette for authors who are trying to meet the provision.
>
>IN SUMMARY: The new algorithm is a better overall algorithm. However,
>the values chosen for use with the new algorithm (5:1) do result in a
>somewhat less strict level for some color combinations. This was done
>to allow a somewhat less restricted number of colors when creating
>pages that could meet the criterion. However, the new criterion is
>more strict than the old in some areas, but it is much more consistent
>in its results. For one thing, the old algorithm was calculated in
>non-linear color space while the new algorithm is calculated in in
>linear terms which better match vision.
>
>----------------------------------------------------------
>Comment 4: Language Subtags (Techniques H57 and H58)
>Source: 
>http://http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0085.html
>(Issue ID: 2536)
>Status: VERIFIED / ACCEPTED
>----------------------------
>Original Comment:
>----------------------------
>
>Techniques H57 ("Using language attributes on the html element") and
>H58 ("Using language attributes to identify changes in the human
>language") are silent on language subtags. However, the BenToWeb
>project found unexpected behaviour when language subtags were used.
>At least one screen reader (JAWS 8.0, both with Internet Explorer 6
>and Firefox 2) ignored the language markup and used its default
>language for speech synthesis when a language subcode was used on the
>'html' element.
>
>We developed several test cases with language subcodes. With JAWS set
>to American English, sc3.1.1_l1_006 [1] (American English),
>sc3.1.1_l1_007 [2] (British English) and sc3.1.1_l1_008 [3] (language
>code for British English) are read as American English; with JAWS set
>to British English, sc3.1.1_l1_006, sc3.1.1_l1_007 and sc3.1.1_l1_008
>are all read as British English. So it seems that language subcodes
>can't be relied on by web developers.
>
>[1] http://www.bentoweb.org/ts/XHTML1_TestSuite3/metadata/sc3.1.1_l1_006
>[2] http://www.bentoweb.org/ts/XHTML1_TestSuite3/metadata/sc3.1.1_l1_007
>[3] http://www.bentoweb.org/ts/XHTML1_TestSuite3/metadata/sc3.1.1_l1_008
>
>Best regards,
>
>Christophe Strobbe
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>We have clarified the use of language subcodes by adding a note to the
>description of these techniques, and adding a user agent note about
>the JAWS behavior upon encountering lang tags that use subcodes.
>
>----------------------------------------------------------
>Comment 5: SC 3.1.3: Glossary without Links Should Fail?
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0086.html
>(Issue ID: 2537)
>Status: VERIFIED / NOT ACCEPTED
>----------------------------
>Original Comment:
>----------------------------
>
>Test case sc3.1.3_l3_004 in the second version of the BenToWeb test
>suite [1] contains text with jargon and the jargon is explained in a
>glossary below the text. However, there are no links between the
>occurrences of jargon in the text and the corresponding glossary
>entries below the text. User testing did not convincingly show that
>this is sufficient for users of a screenreader or magnification
>software. So technique G62 (for Situation A) may need to specify
>stricter requirements on how the glossary can be located.
>
>[1] http://www.bentoweb.org/ts/XHTML1_TestSuite2/metadata/sc3.1.3_l3_004
>
>
>Best regards,
>
>Christophe Strobbe
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>Although a tight linking between the word and its meaning is desirable
>and recommended, a glossary in the document is felt to be sufficient
>to meet 3.1.3.
>
>
>----------------------------------------------------------
>Comment 6: SC 3.3.1: Providing client-side validation and adding error
>text via the DOM (future technique )
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0087.html
>(Issue ID: 2538)
>Status: VERIFIED / PARTIAL/OTHER
>----------------------------
>Original Comment:
>----------------------------
>
>Test case sc2.5.1_l1_025 in the second version of the BenToWeb test
>suite [1] (for the April 2006 working draft) tried to implement this
>technique but failed. The test file contains two mandatory text input
>fields (first name, last name) that are already filled and set to
>read-only. In addition, it contains one text input field for entering
>the date of birth with mandatory input. If the user submits and no
>date is entered or the date is invalid, the error is identified and
>described to the user in text below the form (JavaScript adds text to
>the DOM). However, screenreader users may not notice the text below
>the form because the focus remains on the submit button after
>"submission" (JavaScript catches the missing input, so nothing is
>submitted to the server); when tabbing off the submit button, the
>focus moves to the URL bar instead of to the message below the form.
>We tried different variations on this technique, one of which
>included a change to the text of the submit button to draw attention
>to the error message, but that did not solve the focus problem.
>
>[1] http://www.bentoweb.org/ts/XHTML1_TestSuite2/metadata/sc2.5.1_l1_025
>
>Best regards,
>
>Christophe Strobbe
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>We have removed the technique "Providing client-side validation and
>adding error text via the DOM (future link)" until it has been
>implemented and proven to work.
>
>----------------------------------------------------------
>Comment 7: Failure F70 Does not Prohibit Duplicate Attributes
>Source: 
>http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0088.html
>(Issue ID: 2539)
>Status: VERIFIED / ACCEPTED
>----------------------------
>Original Comment:
>----------------------------
>
>When we evaluated test case sc4.1.1_l1_007 [1], which contains an
>image with two alt attributes (one empty, the second with a text
>alternative), we found the following behaviour: if the image cannot
>be loaded, Internet Explorer 6.0, Firefox 2.0, SeaMonkey 1.1 and
>Opera 9.0 (all tested on Windows XP) don't display alt text. This
>probably means that the second alt attribute is ignored by these browsers.
>
>This situation is not clearly covered by success criterion 4.1.1 nor
>prohibited in failure F70.
>
>Proposal:
>
>Add to SC 4.1.1: "start tags have no duplicate attributes."
>
>
>[1] http://bentoweb.org/ts/XHTML1_TestSuite3/metadata/sc4.1.1_l1_007
>
>
>Best regards,
>
>Christophe Strobbe
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>We have updated Success Criterion 4.1.1 as follows:
>
>4.1.1 In content implemented using markup languages, elements have
>complete start and end tags, elements are nested according to their
>specifications, elements do not contain duplicate attributes, and any
>IDs are unique, except where the specifications allow these features.
>
>Note: Start and end tags that are missing a critical character in
>their formation, such as a closing angle bracket or a mismatched
>attribute value quotation mark, are not complete.



-- 
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/ 


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on Monday, 31 March 2008 18:40:35 UTC