- From: David MacDonald <befree@magma.ca>
- Date: Tue, 12 Apr 2005 13:29:22 -0400
- To: "'Michael Cooper'" <michaelc@watchfire.com>, "'Ben Caldwell'" <Caldwell@trace.wisc.edu>, <w3c-wai-gl@w3.org>
- Cc: <wendy@w3.org>, "'Chris Ridpath'" <chris.ridpath@utoronto.ca>, "'John M Slatin'" <john_slatin@austin.utexas.edu>
I was given the task to review tests that apply to the object tag. #75, 76, 77, 78¸ 79, 27, 128, 129, 183 <section on accessible test files> I posted this to the list and there was some discussion around it. I am willing to follow the group conscience on this but here are my feelings on it. In general I have a problem with tests that are designed to pass a certain accessibility principle but are inaccessible in other respects. I realize that there is a disclaimer above the test files saying that they may contain accessibility problems peripheral to the issue being tested, but I still have a problem with an inaccessible file getting a "passing" grade. I think it gives a confusing message to web designers. If the tests were only being looked at by machines it would not be as important to me, but when humans look at these tests I think it gives a mixed message. I would not recommend inaccessible test files that are supposed to pass a certain WCAG criteria. I think they can still be granular and tiny and be compliant. At least in this object tag tests, where webmasters are so messed up anyway, I would hate to add to the confusion. But I will follow the group conscience. </section on accessible test files> It seems like some of the "passing test" files that should be designed for a Human Inter-rater-reliability test are set up so that they will pass a machine test, and miss the point. For instance in order to make it machine passable, there is no content. To me that defeats the purpose of the test. Perhaps the human tests should be set up so that they can only pass if a human does it. To me that is a issue regarding where we stand on human tests that we don't want to skip over in our discussions. There is a quirky thing with ALT text in an object tag in the HTML spec. John brought this up and I think it is a good point. Suppose there is a file with: <object dtata="ihaveadream.au"> Martin Luther King's "I Have a Dream" speech, August 1963. Transcript: yatta yatta... </object> Say I am hard of hearing. However, I have several media players on my machine because I love video! so I've got Real, and Quicktime, and Windows Media Player, not to mention Flash... Under this scenario there will *never* be a time when my browser would display the text inside the body of the <object> element. This is not a problem with WCAG. This is a problem with the HTML spec itself. The alternative inside the body of the <object> is meant to be rendered if and only if the user agent cannot render the content specified in the data attribute. It is "alternate" content only in that it will replace a missing plug in. It is not alternate in the sense that it will expose the alternate content for people who perceive information in other ways (when the plug in exists on the target machine). I think the only solution is to provide alternate text or descriptions outside the <object></object> tags. If that is the case most of these files will not be useful to us. Files that this applies to are: 80-2, 80-4, 127-1, 128-1, 79-1, 79-2, 78-1, 78-2, 129-1, But in case we decide to go ahead anyway I will evaluate the tests below: 1) Document must be usable when OBJECTs are disabled. http://www.w3.org/WAI/GL/WCAG20/tests/test75.html This test is referring to Guideline 2.1-all functionality via a keyboard but then the test is to remove each object element and then see if the content works. TO me that is not testing for what the guideline is calling for. In Test 75-1, codebase is used for the text "Hello" rather than a url, I think this is a wrong use of Codebase...Even though this is presented as a failing file, I think it should have the proper use of codebase because the fail condition is specified for an entirely different reason. 2) OBJECT user interface must be accessible. http://www.w3.org/WAI/GL/WCAG20/tests/test76.html 76-1 I think there is a wrong use or "codebase" see above. 76-2 The pass condition is a file that has no object tag. 3) OBJECT link to multimedia file must have text transcript. http://www.w3.org/WAI/GL/WCAG20/tests/test77.html I think the test file 77-2 is confusing because it gives an example of a file that will pass because there is no object tag. Since the test is testing for a text equivalent on an object, I think it should have a test using a text equivalent for a video file in the object tag rather than just showing some code that has no object tag and therefore passes. Apart from that, I would reject the entire test because it seems redundant to Test 80, in 77 it says to look for a "type" attribute and if it is a video then look for a text equivalent...in test 80 it says look for a text equivalent (no matter what kind of object it is) so doesn't that mean that text alternatives for video are included in 80? 4) OBJECT must have a TITLE. http://www.w3.org/WAI/GL/WCAG20/tests/test78.html This test is ok except the alt text is in the object tag which may a problem depending on what we decide. 5) OBJECT must have a valid TITLE. http://www.w3.org/WAI/GL/WCAG20/tests/test79.html Test OK 6) OBJECT must have a text equivalent. http://www.w3.org/WAI/GL/WCAG20/tests/test80.html 80-1 to 80-4 files have classid="some url" but to my understanding a classid is only used by windows to reference a registry type of key, e.g., <object classid="clsid:22D6F312-B0F6-11D0-94AB-0080C74C7E95"> not a URL. 80-3 is supposed to be an example of a pass condition, but it offers an image as the alternative to a .py file with *no* alt text. To me that is a fail condition. There is a typo in test 80-4. "object-description" is spelled wrong. 7) Text equivalents for OBJECT should be updated if OBJECT changes. http://www.w3.org/WAI/GL/WCAG20/tests/test127.html Test 127-1 has the alt text inside the object tag. Test 127-2 is an example of a passing test file that is inaccessible. The test passes because there is no text equivalent. 8) Document must be usable when OBJECTs are disabled. http://www.w3.org/WAI/GL/WCAG20/tests/test128.html I don't understand why 128-2 is a pass. When the object is removed there is no content. I do not recommend this test 9) OBJECT user interface must be accessible. http://www.w3.org/WAI/GL/WCAG20/tests/test129.html There is no way to know if 129-2 is a passing test because it has not been accessed with a keyboard and the test calls us to test with a keyboard. 10) Use the EMBED element within the OBJECT element. http://www.w3.org/WAI/GL/WCAG20/tests/test183.html The Embed element is not a W3C spec. Although it does help access. Is it kind of a hack to fix a broken object model or overcome non-compliant user agents. If so it would better be a repair technique. Embed --- 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, 12 April 2005 17:29:34 UTC