September 09, 1999
4:00 - 5:00 PM EDT
Longfellow Bridge: (617-252-1038)
Gregory Rosmaita
Charles McCathieNevile
Chuck Letourneau
Jason White
Wendy Chisholm
Ian Jacobs
Greg Vanderheiden
Jon Gunderson
Dean Denman
1. Raise awareness with AC Members about enhancing accessibility in HTML 4.01. Ian has agreed to do this tomorrow. Charles has also drummed up some interest. People were aware of issues and thought it was important. WC: should this be an ongoing item?
CMN: it is ongoing really.
IJ: the goal was to get MAP issues into 4.01.
WC: should GL submit a comment to the WG.
IJ will take the action to send to the HTML WG that the point should be clarified.
2. WC: Propose techniques based on this discussion.
WC: sent a proposal but it is not clear there was consensus so it is on the agenda for later.
3. IJ: Send proposal to GL list about broadening language of checkpoing 1.5 to refer to device-independence, not just text.
IJ: did that, and Jason, I believe, slammed me
IJ thus it is still up for discussion.
1. re: Partial support in browsers. Wendy and Ian will review the checkpoints for meeting the new conditions. Ian and Jason will review the wording.
WC: some work done, but hasn't proposed it back to group yet
2. CMN - EO should look at how to educate people how to upgrade browsers to get the most accessible features.
CMN: started a thread across EO and GL that he thinks went nowhere. No resolution that he remembers.
WC: maybe we will raise this again later.
3. Ian to pursue browser support with Microsoft and Opera. And others with information to post to the list.
IJ: meeting with Haakon ; Judy has an outstanding response from Microsoft, so both are pending.
4. WC to link the matrix to the GL page.
WC: done.
5. WC to send list of browser support page references to list.
WC: done.
6. WC to find out about possible contact with netscape to get info from them re: the browser support page.
WC: has a contact but hasn't contacted them yet. As well as contacting Al Gilman re: Lynx
WC: Al said we should coordinate with Gregory on Lynx, and TV Raman re: Emacs. And Al said we should coordinate with Jason on Emacs.
WC: considers this 2/3 complete, with Jason and Gregory helping.
1. Make the errata page more visible from the WAI GL home page.
Editors did this.
2. Draft a proposal on clarifying 3.3 thread and send to GL list. Once "approved", add to Techniques, FAQ, and errata page.
WC: thinks we did this, but still need to come to consensus.
3. Request to EO WG that they point to/highlight Techniques as place for clarifications.
CL: what was the point of this?
WC: in any EO awareness, the Techniques document and errata should be referred to as the best place to clear up confusions about things.
4. Rob: Send us usability data to GL list.
WC: he did send some.
5. Chair: In two weeks, put on agenda a discussion of what questions to ask about guidelines to Rob's users (and for others as well).
Done, and EO deferred (but thinks they know what questions they need regardless)
1. CMN - check out resources that are available such as browsercaps (see what their plans are) and find out about WAI staff that could help. perhaps they can create a version for us.
JW: wasn't this subsumed by a later work on browser support?
WC: the browser page should be finished by GL. Several of us should take action items to populate it.
2. Consensus: "Guidelines" is more appropriate than "standards" or "specifications." We need to collaborate with EO where needed.
3. Consensus: leave priorities and conformance as is.
4. Consensus: we do need another version. We need to find the balance between releasing one to update errors and waiting long enough to find out more information. There are several things to consider for the next version such as waiting for browsers to implement more of the features and how that will affect the "until user agent clause." Another thing to keep in mind for the next version is how to deal with new technologies such as XML, RDF, etc. that will become more widely used.
5. CMN will answer #6 (see list of questions below), "do we examples of standard pages that have been modified for non-readers?".
CMN: has not done this yet.
6. Anne Pemberton will make a list of strategies to use to create pages for non-readers (question #1).
WC: Ann has submitted these, and we need to review them.
7. Consensus: questions 2, 3, and 4 can not be answered until we have AP's list.
8. WC will send articles and other information she has found in the last couple of weeks (applies to question #5).
9. CMN will take the issue regarding meta data to PF (see list of potential strategies).
CMN: no consensus on meta data in PF yet.
WC: should GL and PF get together to discuss this?
CMN: Yes.
What should UA's do for metadata included by authors? Is there any general schema? What suggestions do we have for the use of metadata? Which types of semantics are we referring to in checkpoint 13.2?
JG: what information would be useful to people? How did GL mean for meta data to be used when it was included as a checkpoint.
WC: I don't remember… anybody else remember?
IJ: DD said we don't have meta for keywords.
WC: also raised as a strategy for labeling sites for non-readers (measures of reading levels).
JW: yes, that was a potential use.
WC: in techniques, we mentioned in the TITLE element.
W: might be helpful for Jon to take the issue to the PF WG since there are some things going on there.
CMN: has an example of an SVG document that uses meta data to describe the structure of an image.
JG: would this meta data be represented as something like a longdesc? UA's concern is the dependency with GL. If SVG is the primary type of issue, then UA already adequately covers it. Was concerned that GL had other ideas for the use of metadata. PF is more future oriented.
WC: only general recommendations are that using the LINK elements the user should be able to request the documents. Should be also be able to retrieve the TITLE. If there is metadata (LINK and any RDF stuff that the users can get at it easily.
JG: do we specify a checkpoint that says "let users view metadata" and just have it pop up in a window.
IJ: not just this, but might show document structure.
CMN: in HTML 4 there are defined things you can do with a link, and a couple of browsers support display of the NEXT/PREV LINK (like LYNX) and Amaya lets you form a single document from a collection of LINKs.
JG: should this just be an HTML issue?
IJ: if the HTML spec doesn't say anything, it is the responsibility of the guideline groups to specify how they should be displayed/handles.
JW: must consider the issues separately and look at them as time goes by.
CMN: the reading level and conformance to WCAG might be implemented using PICS which is well understood system. If there is a PICS schema that impact on accessibility then it should have a requirement to implement these things in a browser.
JG: we already have checkpoints related to using W3C specifications/technologies. And support W3C recommendations. Under the techniques for these we should include an example of using meta data. What priority is the use of metadata in GL?
WC: priority 2.
JG: doesn't think there are any problems.
WC/JW: LINK is important (for tables of contents, active contents). SVG meta data might be better put off to a future time.
JG: sound pleased with the resolution. Will put some examples in the techniques document.
IJ: proposes the following rewording of checkpoint 1.5:
Until user agents allow users to activate client-side image map links in an input device-independent manner, provide redundant text links for each client-side image map link.
Jason's response (email) was read, as was Charles's response to Jason.
Consensus: Do not change the wording of 1.5 at this time. In future, if UA comes up with a technique that would make changing the wording worthwhile then look at it.
WC: In the errata, we point people to the Introduction and add the following text:
The entry in the errata page might read something like this:
Clarification of rationale for Guideline 1
Added: 1 September 1999
Class: clarification
The rationale for Guideline 1 is confusing because it implies that people with deafness benefit from the use of synthesized speech ("...Synthesized speech is critical for individuals who are blind and for many people with the reading difficulties that often accompany cognitive disabilities, learning disabilities, and deafness....")
The issue that some people with deafness, cognitive and learning disabilities may share is a difficulty reading written text. Sign language is often the primary language for many people with deafness, thus written text is secondary and they may not be as fluent. Please refer to the discussion of text and non-text equivalents in the Introduction to the Web Content Accessibility Guidelines.
(http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#Introduction)
CMN: thinks that deaf people should be taken out of the paragraph altogether.
JW: would prefer showing old version and new version, and not bother going through the entire explanation.
CMN would not mind seeing this but thinks it is too long.
WC: will reword this and propose a new wording and likes Jason's suggestion.
WC: how should we handle this one? Is this the appropriate example? Are there any objections? JG: fine, JW: looked but not a problem.
ACTION ITEM : WG to review this issue and comment.
GV: was asked by CG to bring up LONGDESC URI issue. He is uncomfortable with longdesc pointing off to ANY html page. Thinks it should be just text. Also worried about using longdesc for other clever constructs. Does anybody else share the concern?
JW: thinks there are also PF issues.
CMN: does not think longdesc should not be limited to text.
GV: thinks it could be anything as long as it also includes text.
JW and GV disagree with CMN.
Decision: finish this on the list and take it to PF, where it is on their agenda.
September 17, 1999, 4:00 - 5:00 PM Eastern Time
Copyright © 1999 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.