Chair: Jon Gunderson
Date: Wednesday, November 24th
Time: 12:00 noon to 1:30 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000
Chair: Jon Gunderson
Scribe: Ian Jacobs
Gregory J. Rosmaita
NOTE: Ian will chair next week. Jon back 7 December.
IJ: No Comm Team input.
IJ: Not done.
Status: DC will review. Also Steve Mendelsohn (who is on the board) will also review the document.
Status: Partially done.
RS not here.
DB: He didn't think there was much that pertained to SAMI. But will take a look at it. Is anyone looking at HTML+Time? I'll ask him about that.
Status: Done. I've also asked Tim Lacy to do a review. He'll be back next week. I'll also send to the IE Team.
Status: Pending. The IE Team may consider the Ian/Charles meeting at MS part of their review.
Status: Pending. Some email sent already.
IJ: Re links to middle of a document; Team seems to think this is a good idea.
Status: ALmost done.
DB: I can't make it. Can I conference in?
IJ: We could use IRC and possibly a W3C bridge.
DB: MS could pay for the setup.
Action JG: Talk to Rich about setting up teleconf.
CMN: I'll be in Australia. It would be a big help to me.
DA: Much better for me.
DB: No problem for me.
IJ: Works for me.
KB: May be a problem for me.
MRK: May be a problem for me. Later better.
Proposed time at 13:00 ET.
Action Jon: send to the list.
JG: Rich isn't here, I'd rather hold off on this.
DA: Any language that would refer to the most recent DOM REC should be ok.
We will wait until Rich is on the call.
CMN: In ATAG, we decided on a model that unless someone complained about a technique, it made it into the document.
IJ: That's the way I've been working on the techniques.
GR: We are anticipating a final techniques review?
IJ: What form would that take? I think a teleconf doesn't work.
IJ: I propose:
a) Ask for review
b) If no objections, I'll just add and edit.
IJ: Will there be a new GL draft for the ftf? I propose that we do, that take into account Eric's edits.
Action IJ: Ian will produce a new draft 6 December for the ftf that takes into account suggestions from Eric. People can send comments/objections and we can discuss issues at face-to-face.
DP: Comment on the introduction: In the bulleted list in the intro, put cognitive in the same group with visual, auditory, physical. Might separate disabilities from universal access issues.
IJ: Eric Hansen thought 6.1 should be relative priority.
Proposed: new checkpoint "Provide single-stroke access to user agent functionalities".
DA: Not enough keys to go around.
DP: I think the proposal is too vague.
KB: Do we want the UA developer to make the choice of what should have single-key access? Second level is allowing the user to make that choice? I worry about the case where the developer builds in a lot of single key access and that the user inadvertently activates functionalities.
MRK: You could have some single-key defaults.
JG: Highlight in navigation section? for high-frequency functions.
GR: Point to common single-key defaults per platform (conventions).
KB: What's an example of single key access? Is "Alt-F" a single keystroke?
CMN: In Opera, there are a lot of single-key ways to access functionalities ("F5") and Lynx.
IJ: I don't think "Alt-F" is single key.
CMN: Tricky on a smaller keyboard like Intellikeys or switching devices.
DB: What need are we meeting?
JG: People with motor disabilities.
DB: Single key can be tricky since so few keys. What can't Bryan do with current browsers?
KB: Opera allows him to jump from header to header with a single letter key.
CMN: Or link to link in IE or Lynx.
CMN: You need to be able to configure access. You may have a strong need to include single key access.
IJ: That's what the current checkpoint 10.3 currently says.
IJ: I think EH misunderstood the checkpoint text and based on that, I propose that we leave as is.
From EH's comments:
I feel that the _requirement_ for single-stroke changing of configuration is too restrictive.
We didn't mean that configuration had to be single stroke but rather that one be able to activate important functionalities with a preferred keystroke.
Resolved: Leave as is.
IJ: I understand this to mean "UA developers should implement what WCAG tells them to do."
KB: The "until user agents".
IJ: We already cover all the "until UA" clauses in other checkpoints.
MRK: Having a generic checkpoint means less maintenance over time.
IJ: I have some problems with future-looking checkpoints. "I can't forgive you for things you haven't done yet." (Elvis Costello).
DB: How can I miss you if you won't go away?
CMN: If you can't live without me, why aren't you dead yet?
/* End country western quotes */
DP: If there will be a later version of UAGL, wouldn't it be better to evolve in a new draft?
CMN: The ATAG does both: we say "Do what WCAG says." This ensures modularity. You don't want to have to change one document everytime every other one changes. I think a new checkpoint is not a bad idea in principle. But you don't want to write too many blank checks to other working groups.
JG: Is a redundant checkpoint a problem?
Action IJ:Ian to work with Eric on a proposal.
MRK: I think the change is ok. We would need to define it.
JG: Any objections?
Resolved: Use "caption". In definition of caption, make clear that in context, may refer to table captions not accessibility captions.
- "Braille" or "braille"?
GR: Capital "B" is the convention in print since derived from a proper name, although lowercase "b" also used. I think uppercase "B" would stand out more. Websters prefers capital "B".
IJ: My issue is inconsistency with WCAG. Websters online shows small "b" preferred.
Resolved: uppercase "B" is chosen since no objections.
GR, CMN: No.
IJ: What about contractions?
GR: Braille is an abstraction. There are implementations with contractions.
Resolved: Remove from defn of natural language.
- Is braille also haptic?
CMN: Yes. But refer to Al's comments.
IJ: EH proposes "synchronized equivalent" instead.
IJ: Fits with WCAG. Any important info other than the the synchronized part?
MRK: I prefer "continuous" since it captures time-dependency.
DP: I prefer "continuous" as well.
JG: This refers to alternatives, you would want the content synchronized.
Action IJ: Take "synchronized equivalent" to SYMM WG.
JG: We use "rendered" consistently.
Resolved: Add "relevant". Use of "synchronized equivalent" pending SYMM WG feedback.
IJ: EH wants a requirement to render text to speech within a year of a W3C spec on that topic.
MRK: In what language?
CMN: I don't think we should require this.
DB: I think the expectation is that the system as a whole will do this and the UAs will take advantage of those capabilities.
MRK: Does spoken text have to be synchronized? It's not easy to synchronize auditory descriptions. How do you synchronize automatically?
CMN: This is very techniquey, but if your text if synchronized already, you can use that.
MRK: But text sync is different than audio since you have to mix different audio tracks.
MRK: My problem is that WCAG doesn't make sense because of the difficulties of synchronization.
IJ: Two options:
a) WCAG is wrong
b) "User agents" in WCAG doesn't necessarily mean mainstream browsers. Therefore, since UAGL not catering to all user agents, no need today for an additional checkpoint.
c) Also, if you already support text to speech, your UA will already be required to render the text equivalent as speech.
Resolved: No additional checkpoint.