Participants: Gregg, Daniel, Jason, Chuck, Eric, Ian (scribe), Wendy, Charles
CL: What about substantive issues?
Wendy: let's wait until Gregg arives to tackle that one. until then, let's start in the list where we left off, with Eric Hansen's issues.....
Issue 8. Bug-16. The document does not say how to handle conformance ratings for inaccessible primary pages that have accessible alternative pages.
Proposed resolution: Checkpoints that may be satisfied by having an accessible alternative page say so in the checkpoint. For example, 6.3 may be satisfied either by ensuring the "page is usable when scripts, applets, or other programmatic objects are turned off or not supported" or by providing "an equivalent mechanism on an alternative accessible page." The editors will read to make sure that wherever this is the case, it is stated properly.
JW: It's paradoxical, but true, that a document can fail to have a rating but, thanks to alternatives, a site can have a higher rating. Thus, the set conforms more than the member.
Does anyone disagree with that principle: the combination of a page and its alternatives is accessible.
JW: But the accessible alternative has to be prominently linked from the inaccessible one.
WC: Pairing is an important idea and navigation between them is very important.
EH: I don't want to require linking between accessible and inaccessible pages.
DD: Be careful because most of what you get as alternative pages is not really accessible. Alternate pages can't be poor in structure.
EH: Proposes removing "link to" an alternative page in 11.4. This allows two branches (accessible branch v. non-accessible branch) and not just pairwise linking.
IJ: Leave concept of linking.
WC: Links to accessible versions are important from all documents since you may end up in the middle of a set of documents.
CONSENSUS: Yes, compliance with alternatives is possible. E.g., longdesc.
Where do you put the icon?
Ian: Say explicitly in conformance statement.
CMN: Why different from any other checkpoint?
GV: Note the "best efforts" part. If no effort spent on the primary page, no right to put icon. If effort spent and there are alternative pages, you can since you've abided by the checkpoint.
JW: Stating scope clearly helps.
EH: But if you say the scope is a page, that *specific* page has to be accessible.
GV: Don't agree. A page includes page and its supports (e.g., graphics).
CONSENSUS: No change required.
JW: I'd like to see the document be the best it can be.
Also raised by Wendy Chisholm, but not to the working group. Issue 17. Checkpoint 3.8 is incorrect and contradicts the HTML4.0 spec [3.8 - Provide individual button controls in a form rather than simulating a set of buttons with an image map.] The idea this checkpoint is trying to convey (to avoid using server-side image maps in form input controls) is a technique of "avoid server-side image maps" (checkpoint 9.1).
Proposed resolution: Delete checkpoint 3.8 and discuss in the techniques document in the Forms section, and point to it from the Image map section.
WC: Nothing inaccessible inherently about a client-side image map. We're talking about server-side usage. But covered by 9.1.
CONSENSUS: Remove 3.8 and make a technique of 9.1.
Raised by Wendy. reference: http://lists.w3.org/Archives/Public/w3c-wai-gl/1999AprJun/0003.html
Issue 15. It seems that checkpoint 10.2 ought to be a note for checkpoint 12.4. [10.2 - For all form controls with implicitly associated labels, ensure that the label is properly positioned. 12.4 - Associate labels explicitly with their controls.]
Proposed resolution: Reword 12.4 to read, "Associate labels explicitly with their controls. Note. when controls are not explicitly associated, ensure that the label is properly positioned. The label must immediately, ....rest of 10.2..."
CMN: I am against making this change.
CMN: Label/"for" is a UA issue.
RESOLVED: Add "Until user agents" to 10.2.
Issue 9. The example for 6.3 focuses too much on NOSCRIPT and should highlight graceful transformation [For example, in HTML provide a text equivalent with the NOSCRIPT element or via a server-side script. Or provide a non-text equivalent (e.g., a snapshot in place of an animation, a video equivalent of an applet, etc.). For applets and programmatic objects, provide text equivalents. Refer also to guideline 1. ]
Proposed resolution: For example, when using JavaScript in an HTML document, do not use "javascript:" as the URI for a link. If it is not possible to make the page usable without scripts, provide a text equivalent with the NOSCRIPT element, use a server-side script instead of client-side script, or provide an alternative accessible page. An example of an alternative mechanism for an applet simulation is a video recording of someone interacting with the applet simulation. Refer also to guideline 1.
IJ: What's the "javascript" part mean?
WC: The "javascript" is generating the URI.
IJ: I don't like the first "for example" part up front.
ACTION editors: Propose example text to list.
Issue 10. 6.4 is device dependent - "keyboard operable". [6.4 - For scripts and applets, until user agents provide device-independent means to activate event handlers, ensure that event handlers are keyboard operable.]
Proposed resolution: reword 6.4 to read, "For scripts and applets, ensure that event handlers are device independent."
CMN: You can make things keyboard operable in ways that make them inaccessible with keyboard simulators.
GV: How do you make them device-independent?
WC: It's hard today. You have to use all of the handlers, but they all use the same subroutines. (onfocus, onmouseup, all at once.).
GV: What browser doesn't have a keyboard?
CMN: Something that only uses voice input?
GV: So to do it today a programmer would have to attach the same script for the action for each handler. They won't want to have to repeat things 6 times.
CMN: There's an IE bug: they require links around something for correct behavior.
JW: We want device independence. Several event handlers is a technique.
IJ: Do we want to say in the techniques that keyboard is sufficent.
CMN: Only sometimes sufficent.
CONSENSUS: Change "keyboard operable" to "device independent".
ACTION Editors: Ensure that "device independence" is clearly defined in the glossary.
(WC: Recall that EO shoulders part of this burden.")
Issue 11. in checkpoint 6.4 - are we sure that user agents will provide device-independent means to activate event handlers? Even if they do, shouldn't authors be encouraged to ensure that script and applets are written to be device independent?
Proposed resolution: Delete the phrase, "until user agents provide device-independent means to activate event handlers," from the checkpoint.
CMN: The HTML 4.0 event model is broken. To say "use a device independent model" until one exists, seems tautological. Things won't disappear from HTML.
JW: The goal is device-independence. It's a technique how this is done (e.g., with several attributes).
RESOLVED: Delete "until user agents" from 6.4.
/* So checkpoint 6.4 now reads: "For scripts and applets, ensure that event handlers are input device-independent." ******/
Issue 13. 6.5 is too loosely defined. [6.5 - Provide an alternative presentation or page when the primary content is dynamic (e.g., when frame contents change, when scripts cause changes, etc.).]
Proposed resolution: The scripts and applets portion of this is handled in 6.3. Move the NOFRAMES portion to Guideline 10 [Use interim solutions] as the new 10.6 - "Until user agents are able to navigate and display multiple pages laid out in one window (as with HTML Frames), provide a means to access the pages one at a time. For example, in HTML use the NOFRAMES element with links to each frame in the frameset. [Priority 2]"
CONSENSUS - to keep as it is, but delete the phrase "provide a NOSCRIPT for every script" from the example.
Chuck and Gregg will chat with Judy about setting up a call for next week. Primary question is: may we call a meeting without one week's notice?