W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2005

RE: Test files review, #75, 76, 77, 78 79, 27, 128, 129, 183

From: David MacDonald <befree@magma.ca>
Date: Tue, 12 Apr 2005 13:29:22 -0400
Message-Id: <200504121729.j3CHTNrM005791@mail4.magma.ca>
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

<object dtata="ihaveadream.au">
Martin Luther King's "I Have a Dream" speech, August 1963.  Transcript:
yatta yatta...
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.

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.

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.

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.

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.
Test OK

6) OBJECT must have a text equivalent.
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.

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.

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.
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.

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. 


--- 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

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:07:39 UTC