WAI Authoring Tool Guidelines Working Group
Chair: Jutta treviranus, <jutta.treviranus@utoronto.ca>
Date: Wednesday 21 July 1999
Time: 3.30pm - 5:00pm Boston time (1930Z - 2100Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990720.
Note that in most cases there is a thread of discussion following the message which has been referred to here.
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0017.html
JT: Should we put something in our guidelines as well?
DB: I think so.
IJ: Use document order.
WC: Several programs may be used to generated a graphical front end to a database application. Drag and drop possible. There's a function that allows you to view all controls/fields and create a tabbing order for them. Appearance separate from document (tabbing) order.
JR: What if the user doesn't care about logical order?
JT: Difficulty is that physical order is different from order in HTML.
WC: Often times, order is creation order. Display order may be very different.
JT: What is logical order if not specified by author. How to go from physical to logical order?
DB: Not clear that left-to-right mapping would always work.
JT: What about tables, e.g., that don't serialize well.
JR: Perhaps if something moved on the screen, we should recommend that logical order be changed as well.
JT: And that author be able to specify the logical order.
IJ: Not sure there's an easy mapping in the general case from physical order to logical order (e.g., tables). Also, overlapping lines: what to do when they overlap?
DB: Cultural differences (localization) also important.
IJ: Is there total independence between physical position and final document order?
JT: Yes.
JT Proposes:
CMN: Technique: Render the content linearized. Ask author to confirm/change order.
DB: Does this mean developers need to create another view?
CMN: The requirement is to produce accessible content, and that's one implication, yes.
DB: This is tricky area since involves a new prompt, a new view, control of logical order, ...
CMN: E.g., with Publisher, you can drag text and not change flow order. In Word, it would be moved in logical order as well. So linear view is not always required if logical order is preserved during editing.
CMN: Another approach is to check that the CSS layout flow is a straight-through flow. Checkpoint 6.1 covers checking for resulting accessibility problems.
JT: In Tools WG, discussion of automatic validation of WCAG.
CMN: We can incorporate info into techniques document. No size limit. Can change later on.
JT: There's a significant list of techniques for verification and repair.
CMN: Guideline 6 fits into this category.
Resolved: Add physical/logical mapping techniques to Guideline 6.
Resolved: Look at work of ER Working Group
Action CMN: Send edited version to list. Others may send their comments to Charles.
CMN: I noticed in minutes from last week [ http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0038.html ] that some techniques removed. I would like to re-open that decision.
JR: Techniques are ok, but why placed here (under integrating features into overall look and feel)? Ok to keep the techniques, but not here.
CMN: Rather than remove, add more techniques!
JT: But how does this technique fit into this section?
CMN: Putting alt into every image seemed obvious to me.
Resolved: Leave technique in. Change the emphasis from "that something happens" to "where it happens".
Action CMN: Write an introductory sentence and reword.
CMN: For other removed technique, put in a new example and leave the old one. Demonstrating is useful. This is not a contentious technique.
DB: Would rather have one really good example than several medium quality.
JR: Also, null alt text is still a contentious technique.
GR: This morning in ER teleconf, Len Kasday talked of forwarding summary of arguments to WAI CG. There needs to be "word from above" about the alt text problem to allow us to move one.
Resolved: Leave current technique, add note that will be modified based on outcome of WAI CG decision.
DB: Issue: Need to ensure that developers understand that Techniques are examples only, not required. Talked with people this week about people doing Office 10. They fear not being able to meet some Priority 1s. They are intimidated. I told them better to implement a few than none.
CMN: Similar discussions with Amaya team. There were some very easy ones (already existing or easily done) and others really difficult. How to prioritize? A/AA/AAA helps in this case. But within a given level, internal working decision about which to do. "What do we need to do first?" I sat down with them to work out a plan. The plan included testing of AU Guidelines, but also real-world W3C Team needs.
Jutta proposal [4] [4] http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0051.html
JT: Do we wish to mention linking in Bobby, A-prompt or other checking and verification tools? How do we reference ER document in development?
CMN: I'd like to refer to ER materials. If it's brief, we should incorporate a snapshot.
JT: Not brief. It's very specific.
GR: Bobby folks came up with a bunch more information that will make the ER materials even larger.
CMN: So probably we'll have to reference rather than include. Will ER materials be stable published?
GR: Not yet determined. Bobby folks say that WCAG Rec makes their work is easier, but in refining, they open cans of worms.
CMN: It would be best for AU to be able to refer to ER materials at stable published URI.
Resolved: Refer to ER materials (not include)
Resolved: Ask ER to create stable public reference.
IJ: I propose listing ER tools at W3C Web site, not including in techniques (since more volatile than techniques doc).
Resolved: Jutta's proposal for 6.1 accepted. Refer to ER doc about checking/alerting.
"Allow authors to control both the nature and timing of the correction process." s a technique.
JT: Proposed
Resolved: Move technique to 6.3
JT: Do we want to add: "To make correction more efficient, the author can be given the choice to make corrections by type of error and where appropriate to make site-wide changes." In short: group correction process.
CMN: Important to point out "where this is the same error."
Resolved: Will keep the example, but will add Charles' phrase.
CMN: Put explanatory note in: When the tool doesn't recognize the markup, since the author may know, allow the author to keep.
Action CMN: Propose text for 6.4
JT: Should we have somewhere a checkpoint stating that the transformation should favor accessibility?
CMN: This is tricky since close to implementation level.
JT: Only area critical for access - human knows more. (Same as previous checkpoint).
CMN: I would be wary of changing.
Action JT: Clarify proposal for 6.6. CMN suggests talking to Harvey Bingham (who sent proposal about time of last IG review).
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile