- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 05 Aug 1999 17:51:25 -0400
- To: w3c-wai-au@w3.org
Hello,
Whoops! I forgot to send these. Sorry about that!
WAI AU Teleconf
28 July 1999
Jutta Treviranus (Chair)
Dick Brown
Jan Richards
Wendy Chisholm
Gregory Rosmaita
Kynn Bartlett
Charles McCathieNavile
Ian Jacobs (Scribe)
Agenda: http://www.w3.org/WAI/AU/telecon-28jul99
Doc: http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990720.
1) Logical vs Physical Order
[1]
http://lists.w3.org/Archives/Public/w3c-wai-ig/1999JulSep/0097.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:
a) Provide basic physical to logical mapping
b) Allow user to control logical order.
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.
-Look at work of E&R WG.
2) Proposed Introduction text.
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0017.html
Action CMN: Send edited version to list. Others may send
their comments to Charles.
3) Technique Reviews
CMN: I noticed in minutes from last week [3] that some
techniques removed. I would like to re-open that
decision.
[3]
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0038.html
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.
/* On developer response to Guidelines */
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.
4) Review of Technique 6
Jutta proposal [4]
[4]
http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0051.html
GENERAL.
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.
CMN: 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)
- 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).
CHECKPOINT 6.1.
RESOLVED: Jutta's proposal for 6.1 accepted. Refer
to ER doc about checking/alerting.
CHECKPOINT 6.2.
"Allow authors to control both the nature and timing of the
correction process." s a technique.
JT: Proposed
1) Add "correction process" to 6.2, or
2) Put technique under 6.3 (assist author in correcting).
RESOLVED: Move technique to 6.3
CHECKPOINT 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."
RESOLUTION: Will keep the example, but will add Charles' phrase.
CHECKPOINT 6.4
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 will propose text.
CHECKPOINT 6.6
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 Jutta: Clarify proposal. CMN suggests talking
to Harvey Bingham (who sent proposal about time of
last IG review).
Received on Thursday, 5 August 1999 17:43:20 UTC