Chair: Jon Gunderson
Date: Thursday, April 6th
Time: 2:00 pm to 3:30 pm Eastern Standard Time, USA
Call-in: Longfellow Bridge (+1) (617) 252-1038
Chair: Jon Gunderson
Scribe: Ian Jacobs
Gregory J. Rosmaita
Next teleconference: 13 April
Next face-to-face: 10-11 April
1. FTF for Evaluation and Repair Tools working group in
2.Notice of Proposed Rulemaking: Electronic and Information Technology Accessibility Standards by the United States ARCHITECTURAL AND TRANSPORTATION BARRIERS COMPLIANCE BOARD Comments will be accepted until May 30th http://www.access-board.gov/sec508/nprm.htm http://www.access-board.gov/sec508/overview.htm
JG: If you have comments, consider drafting comments or coordinate with the W3C Team.
1.IJ: Draft a preliminary executive summary/mini-FAQ for developers. (No
Status: Not done.
2.CMN: Send a proposal to the list related to a note for Checkpoint 2.1
clarifying UI verses API access
3.DA: Review techniques for Guidelines 7 and 8
Status: Not done.
4.DB: Get Tim Lacy to review G+
TL: I haven't looked at them lately. I'll try to review before the meeting.
5.DB: Review techniques for Guidelines 3, 4, and 11
Status: Have read through them, will send comments to the list.
6.DP: Review techniques for Guidelines 1 and 2
Status: Will send editorial comments to the list
7.GR: Look into which checkpoints would benefit from audio examples in the
Status: Looking for software that works. I've made some requests for leads but haven't found anything yet. I may try to work on something in Princeton.
HB: Get samples of digital talking book work at Princeton.
8.GR: Review techniques for Sections 3.7 and 3.8
Status: Not done.
9.MQ: Review techniques for Guidelines 9 and 10
Status: Not done. I have a hard time finding things. Discussion
IJ: Still getting reviews. No substantial comments yet.
JG: 10 people have registered.
JG: We'll have a bridge for the meeting. Tim, Mark, Denis, Jim Allan have requested a telephone connection.
KB: I'll sit in with Mark.
DP: I want to call as well.
IJ: That means the entire bridge will be full. There are only six slots and the WG will need one.
IJ: The bridge will be available from 10am ET to 5pm ET Monday and for the whole meeting on Tuesday.
The number to call (the "Mystic" bridge) is +1-617-252-1859.
/* Discussion of speaker quality */
DB: If there's a problem, Microsoft will be willing to rent necessary equipment.
JG: Agenda items?
IJ: From the PR, one comment - people want us to track support for the Guidelines.
Furthermore, the WCAG WG would like the UA WG to take over support for the
UA Support page.
JG: Also, talk about long-term schedule, confs and meetings we might attend/hold. Other ideas: - Specialized guidelines for assistive technologies.
JG: Please send agenda items to the list.
DA: When you talk about conformance guidelines for AT, there's a group hosted in part by the US Census bureau working on a standard interface for ATs.
GR: There was a guy from the US Census at the WAI IG meeting.
Action DA: Look for name of this organization and send to list.
IJ: Our charter expires at the end of April.
/* IJ explains charter renewal process */
IJ: Send charter ideas to the list. (Consider this a call for charter ideas.)
IJ: Development of a requirements document. Look at what WCAG is doing for its requirements document.
JG: So I've got:
- Assitive Technology Guidelines
- improved techniques document
- reqs document
- education and outreach
- future meetings
DA: I'll try for Mac.
GR: I intend to go through the checkpoints with Netscape 6. I've already
sent problems to the list about installation:
GR: I don't think that I will have a full review done before WWW9.
DP: Please note that this is a pre-release.
IJ: The implementation report is not urgent to go to REC. We should keep it up to date, but not urgent to do so now.
Refer to Ian's proposal: http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0550.html
IJ: JG has made a point that making regular content available is not an accessibility issue: everyone suffers, not just users with disabilities.
IJ: So: all alternatives that can be recognized by the UA must be available through the UI.
DA: If you render content natively, you must render it accessibly.
TL: Another problem with source view: for large documents, doesn't show you all content.
JG: The critical piece of 2.1 is that alt equivalents be available through the UI. I don't think anything else would be lost.
Resolved: - Add a note to 2.1 that a source view, while useful, does not meet the requirements of 2.1. - It does not satisfy 8.6 ("outline view") either.
DA: In fact, the outline view is supposed to reduce signal-to-noise ratio, which is increased by a source view. (Ian reminds himself for the record that the content/ui division in G1 needs to be fixed. Action Ian: Fix this.)
IJ: "Source view" is for viewing the document source. I think that we need a definition of "document source". (Refer to Note at W3C for Note about Terminology for the Web: the source is what you get as a result of a request). It's what the client gets.
IJ: In DOM1, content generated by style sheets not in tree. This may change in DOM 3.
JG: MS's implementation of the DOM today gives this information...
TL: It's even more complicated than source/dom/rendered: you have server-side scripts that may or may not have an effect on the source.
TL: What comes down the wire is "the source".
- Define these erms:
* Document Source
* Document Object
* Rendered Content
What is content?
Action IJ: Propose three terms to the list.
IJ: How do you know something is an alternative equivalent?
What is lost if the scope is reduced to equivalent alternatives?
I haven't been able to come up with anything other than "content" (primary or alternative).
GR: In ATAG, we talked about "Content" (big "C") v. "content" (small "c").
IJ: If you define "content" to be what's meant for humans, then checkpoint 2.1 stays the same: it's what's meant for humans (primary or alternative content).
CMN: I don't like this. At the meeting, I thought we decided we would not require that everything that is human readable be available through the UI.
IJ: Why is this an accessibility issue?
If the information is not meant for anyone, why does it need to be available for accessibility?
GR: It's an authoring issue.
IJ: How do you know what will be useful to users if it's not specified as being useful to humans? E.g., some URIs may be useful and others not, but you're not supposed to rely on the text of a URI to get information...
JG: How many people think that what CMN is talking about was intended by 2.1 as written in the Proposed Rec? (Source information is important, not just content meant to be rendered, since it could provide access).
CMN: Three weeks ago the WG rejected the idea of making explicit what needed to be rendered through the UI.
JG: I don't think the WG understood the implications of 2.1 when it was discussed. When Phill asked about a source view, I woke up because I didn't think that 2.1 was about document source.
CMN: I have no disagreement that alt content needs to be available through the UI and that for that content, the source view was not satisfactory.
CMN: The only content that must be available through the user interface is what is meant for humans.
IJ: Summary of what I've understood: - Consensus that all information meant for humans be available through the UI. - Current 2.1 does not require that. - CMN considers that information meant for machines can make information more accessible. - UA Guidelines does not require a source view. J
G: Do people think we need a checkpoint that states that alternative content must be available through the UI?
Consensus: It must be available.
IJ: I just want to note that the above consensus may cause a change to the spec.
DP: If you don't render audio but there is an equivalent, you need to render it.
JG: If you don't tell anbody there is audio available, do you have to render an alternative equivalent for a user with a disability?
IJ, GR, DP: Yes.