[techs] Review of tests 143, 144, 97, 109, 64, 66, 194, 68, 65

Here are my reviews of test files assigned to me for review. I glommed them all into one email, even though many of the test files are not related to each other. There are two blank lines between each test. Also, I preface each test with a keyword indicating what I think needs to be done: ACCEPT, REJECT, MODIFY the test file, fix the TECHNIQUE, create a NEW test file, or DISCUSS.


[TECHNIQUE, MODIFY] Test 143 [1] Document must have an address for author.

It is under consideration to remove the HTML technique for ADDRESS [2] because it is unclear to us that there is an accessibility-specific reason to require it. This test file should have the same fate as that technique. I propose we make the decision now to remove the technique and therefore the test file. 

If we do not remove the technique, the second part of the test procedure should be removed. This duplicates the next test, #144 (discussed next here also). So the test procedure should simply be "check for an ADDRESS element".

[1] http://www.w3.org/WAI/GL/WCAG20/tests/test143.html
[2] http://www.w3.org/TR/WCAG20-HTML-TECHS/#address



[TECHNIQUE, MODIFY] Test 144 [3] address of page author must be valid.

This test should also have the same fate as the HTML technique. If we end up keeping it, we should remove first part of the test procedure, which is to check for an ADDRESS element. That is already covered by test 143, which is a prerequisite test for this one. 

[3] http://www.w3.org/WAI/GL/WCAG20/tests/test144.html



[ACCEPT] Test 97 [4] Document must be readable when stylesheets are not applied.
[ACCEPT] Test 109 [5] Document must be readable when stylesheets are not applied.
[NEW] test for STYLE element

These two tests seem fine as is. Test 97 checks for linked stylesheets, and test 109 checks for "style" attributes. However, we appear to be missing a test for the STYLE element. We need to create a new test for that, modeled on these.

Note the titles of these are identical. It might be useful if we differentiate the titles in some way, so it's clear they are indeed separate test files.

[4] http://www.w3.org/WAI/GL/WCAG20/tests/test97.html
[5] http://www.w3.org/WAI/GL/WCAG20/tests/test109.html



[ACCEPT] Test 64 [6] All area elements have an alt attribute.

This test seems fine. In fact, it has a status of "accepted" but somehow made its way into the list of test files for me to review. Since I created the list, I have only myself to blame. I'm just putting my review here so I can say I did my homework.

[6] http://www.w3.org/WAI/GL/WCAG20/tests/test64.html



[MODIFY] Test 66 [7] area link to sound file must have text transcript.

The spirit of this test seems fine. However, I have some concerns. 

- The test lists sound file suffixes. That is an ever-changing list, so I'm not sure how this test can ever be guaranteed to be current. Besides, sound files can be loaded without necessarily having a particular extension. 

- The test file requires that, if a link to a sound file is found, there be a text transcript. However, it does not specify how you can recognize that a text transcript has been provided. There are also no examples of a pass condition demonstrating the presence of a transcript. I don't think we can accept the test until this is worked out.

- The final test file 66-2 [8] for a "pass" condition is, in my mind, a "not applicable" condition. This example is for an AREA element that does not link to a sound file, not for an AREA that links to audio and has an associated transcript. Therefore, that example should be removed or marked as an applicability condition test.

[7] http://www.w3.org/WAI/GL/WCAG20/tests/test66.html
[8] http://www.w3.org/WAI/GL/WCAG20/tests/testfiles/66-2.html



[ACCEPT, MODIFY] Test 194 [9] Alt text for all area elements contains all non decorative text in the image area.

This test has a status of "accepted" but wound up on my plate. However, I do question the prerequisite test, which is a test for the alt text of image submit buttons. That seems to me to have nothing to do with AREA elements and is not a meaningful prerequisite. I propose we remove that. I think the proper prerequisite would be test 64 [10] All area elements have an alt attribute.

[9] http://www.w3.org/WAI/GL/WCAG20/tests/test194.html
[10] http://www.w3.org/WAI/GL/WCAG20/tests/test64.html



[MODIFY, TECHNIQUE] Test 68 [11] area should not open new window without warning.

Mostly this test sounds fine. But it requires that there be a warning if a new window will open, but it doesn't say what counts as a warning. I think we can't accept the test until that is cleared up.

Checking the HTML techniques document for the applicable technique [12], it appears the technique doesn't answer this question either. Therefore I think the onus is on the technique. At some point we had a big discussion about appropriate or acceptable ways to inform the user new windows will open (I'll have to dig up the references). We considered text in the link itself, text in the title attribute of the link, text near the link, and text towards the top of the document saying "some links open new windows". While we nerded out on the discussion I don't recall that we arrived at any resolution, and I don't see that discussion reflected in the technique. Much as I hate to say it, we may need to revive that discussion in order to close off this test.

[11] http://www.w3.org/WAI/GL/WCAG20/tests/test68.html
[12] http://www.w3.org/TR/WCAG20-HTML-TECHS/#links_popup



[ACCEPT] Test 65 [13] Alt text for all area elements identifies the link destination.

This test has a status of "accepted" and it seems fine to me.

[13] http://www.w3.org/WAI/GL/WCAG20/tests/test65.html

--- Signature ---

Michael Cooper
Accessibility Product Manager, Watchfire
1 Hines Rd Suite 200, Kanata, ON  K2K 3C7  Canada
Tel: +1 (613) 599-3888 x4019
Fax: +1 (613) 599-4661
Email: michaelc@watchfire.com
Web: http://www.watchfire.com/

Received on Tuesday, 15 February 2005 15:57:02 UTC