- From: David MacDonald <befree@magma.ca>
- Date: Tue, 3 May 2005 15:31:32 -0400
- To: <w3c-wai-gl@w3.org>
- Cc: <lguarino@adobe.com>
- Message-Id: <200505031931.j43JVWZ8016793@mail3.magma.ca>
Sorry to take so long on this. Here is 4.2. As we all know 4.2 is in a state
of flux/transition right now but I will do my best to sum up to issues as I
see them. I read thought the archives regarding this issue, the Bugzilla
entries I could find and the documents. I honestly don't think we should
make any major decisions until we are stable in the Guidelines document.
Let's first look at HTML techniuqes as mapped here:
http://www.w3.org/WAI/GL/2005/02/11-sc-techniques-mapping.html
I think the mapping presented in this part of this experimental document has
some problems. It only links:
* 12.10:
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#download-vie
wer> Plugin viewers
* 14.5:
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#frames_html>
Frame sources
To 4.2.
12.1
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#markupnotima
ge> 0 Markup and style sheets rather than images: the example of math
I don't think this belongs here because an image is not a programatic
object. I like the editorial note that says move it to general. But I'm not
sure that we still need to
* 14.5:
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#frames_html>
Frame sources
I don't think this applies to 4.2.
In the mapping document there is a list of HTML techniques that are not
mapped to any guideline. I noticed that the HTML techniques that were mapped
(12.1 and 14.5) were also on the "unmapped" list. It was also the case for
all the SCC techniques. So I think there are problems with the algorithm of
this mapping document.
I think the following map to 4.2.
12.
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#programmatic
objects> Programmatic objects and applets
* 12.2
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#progobj-fall
back> Programmatic object fallbacks
There is the following editorial note:
Editorial Note: As a "technology not supported" technique this depends on
the outcome of our discussion
<http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0513.html> on
baseline. This also should not in principle be needed if authors follow
<http://www.w3.org/TR/WCAG20-HTML-TECHS/#progobj-da#progobj-da> Direct
accessibility of programmatic objects.
Although it could be argued that Alt text for objects is covered in 1.1, I
will examine them here because of some of the issues specific to alt content
as it allies to objects.
I don't think we want to say that fallbacks are unnecessary, given the
current poor support of many plug-ins. I think we can remove the note and
use the technique as written.
* 12.3
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#progobj-altc
ontent> Alternative content for programmatic objects
I think we should delete this technique because it is covered in 12.4.
* 12.4
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#object>
Text and non-text alternatives for object
This gets into the big issue we are dealing with right now regarding where
to put alternate text in an object. Right now I reluctantly suggest a "D"
link type of alt text as a "repair technique" for reasons given here:
http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0117.html
Although, perhaps one of the reasons the "D" link idea flopped is that
nobody understood what the "D" stood for. Many people though of it as a sort
of artifact that was on the page by accident. So perhaps it should be a link
to something like "Text Alternative for [insert title of object]" I wish the
spec wasn't broken and that User Agents could go in and look at the Alt text
in an object but that is just not the way it is right now and there is no
hint of a change coming in the spec.
That means the example is not good because it suggests putting the Alternate
in the Object TAG which doesn't work when a player is present.
* 12.5
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#applet-conte
nt> Alternative content for applet
Deprecate this. Applet is discontinued in XHTML
* 12.6
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#applet-alt>
Alt text for applet
Deprecate this. Applet is discontinued in XHTML
* 12.7
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#noembed>
Alternative content for embed
Ouch this is a rough one because it is not part of the spec but it actually
works better than object for some things. I think we should leave it as a
repair technique for the broken or poorly supported object element
* 12.8
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#embed-alt>
Alt text for embed
Ouch this is a rough one because it is not part of the spec but it actually
works better than object for some things. I think we should leave it as a
repair technique for the broken or poorly supported object element
* 12.9
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#embed>
Embedding multimedia objects
Needs to stay in the document as a repair technique
* 12.10
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#download-vie
wer> Plugin viewers
Keep this as is but add a : after the word "Not"
We may need to discuss the Form element, as a plugin because it is the chief
hook into the HTML used for the Microsoft .NET framework.
*CSS*
I don't think there are any clean hits in the CSS Techniques for Guideline
4.2
* The mapping document listed
* 5.5: Creating
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#creating-invi
sible-labels> Invisible labels for form elements
* 1.1: Using
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#units-that-ch
ange> em or percent for properties that need to change
* 1.2: Using
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#units-for-sta
tic> px for properties that do not need to be changed
* 5.2: Creating
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20050211/#layout>
layout, positioning, layering, and alignment
I would not tie these into Guideline 4.2.
JavaScript
The mapping document liststo following Javascript techniques:
* 2.1: javascript:
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-SCRIPT-TECHS-20050211/#js-uri>
URIs
The editorial note discusses whether this anti-technique is valid given our
baseline direction. At present Javascript URI are not well supported but
Richard & Becky's work over at IBM may change that.
* 2.2: Dynamic
<http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-SCRIPT-TECHS-20050211/#doc-write>
content generation
The deprecated examples should be better marked so people will know that is
*not* what to do.
Test Cases
I covered the test cases applying to this here.
http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0117.html
There is much work to be done on the tests. For instance having real objects
that are accessible. I have some calls out to get someone to build something
for us, but nothing back yet. The issue came up about whether we should
worry about making WCAG compliant test in every respect other than the
infraction that is demonstrated. The group felt that it would put undue
burden on the test case effort and bloat the test files. So we will be using
a disclaimer instead. As noted in the post above there are quite a few
issues with the test and I'll be working on them with Chris Ridpath in
coming weeks.
Bugzilla
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1183
Michael writes "4.1 and 4.2 Should specify xml:lang along with lang except
in XHTML 1.1 where
lang is not allowed. Some assistive devices use the lang attribute while XML
renderers will use the xml:lang attribute."
I don't think of plug-ins being written in HTML. Are we sure it belongs in
4.2??
1056 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1056>
to
P2
Oth
michaelc@watchfire.com
ASSI
Enter captioning information for object and embed
915 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=915>
non
P2
Oth
michaelc@watchfire.com
ASSI
OBJECT must have a TITLE
895 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=895>
non
P2
Oth
michaelc@watchfire.com
ASSI
Propose solution for text alternatives of accessible non-...
712 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=712>
que
P2
Pri
bugzilla_wcag@trace.wisc.edu
NEW
what constitutes sufficiently documenting required techs?
1289 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1289>
que
P2
Pri
bugzilla_wcag@trace.wisc.edu
NEW
innerhtml() technique
314 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=314>
que
P2
Oth
bugzilla_wcag@trace.wisc.edu
NEW
Technology features not formal parts of the spec: how do ...
1056 This is Joe Clark's suggestion of writing a DTD to include <embed>
element. I think this is a good hack but, very few Johnny lunch box web
designers will do it. And they may end up just using embed. If we want that
then I'm ok with including it, but if we are perhaps more purists we could
turn it into a repair technique.
915 In this issue Michael is suggesting we don't require a Title on Object.
I would say that as a non-normatie document, everything we write is only
suggestive. And not necessary for compliance. So I would recommend including
a technique for "adding a Title to the Object tag" in our technique doc. The
Object tag is so messed up that I think it needs all the help it can get.
895 Michael raises a good issue. Do I need a text alternative for an
*accessible* Flash file. It opened a huge can of worms on the list, and lots
of strong opinions all around. Do I dare make a recommendation? Uhhh yes..I
recommend that if the baseline accommodates the object, and the object is
accessible, then no alternative is necessary. Otherwise an alternative is
necessary.
712 applies to 4.3, which no longer is in the guidelines. I think we can
close them "overcome by events"
1289 This bug by Alex at SAP is about the Javascript write command, I will
have to study this some more before making a recommendation
314 This revisits the EMBED element and other "out of spec" techniques. I
covered the EMBED element above and recommended it as a repair technique.
Hey that is it for now.
Cheers
David MacDonald
Access empowers people.
.Barriers disable them
www.eramp.com <http://www.eramp.com/>
Received on Tuesday, 3 May 2005 19:32:28 UTC