Conference Call
October 29, 1998
Start: 4:00 PM Eastern Time
In particular, we are interested in looking at:
DD: need to say something about DHTML events, and we need more definition of complexity or simplicity of tables in techniques.
JW: Braille needs definition in the glossary. Abstract. Perhaps an explanation of why well-designed documents are more accessible. An introduction for people who haven't come across the issues that these guidelines are meant to address. Stems from comments on the list a few weeks ago about how "real users" had problems with the guidelines. A proper well-structured document does not require much more work. Also the "disclaimer" issue re: Eric Hansen.
CL: concur with JW on introductory and disclaimer;
AG: dynamic HTML and language complexity issue - we must be prepared to ship with these things not.
CMN: DHTML
AI: will look at Eric's/Jason's disclaimer and try to work at it.
DD: The guidelines document may be frozen for one year (for example) while the techniques document might continue to change. Or, the model might freeze both Guideline and Techniques. We have to decide on the model we want to pursue. Regardless, "Version 2" can be released a year later, for instance.
GV: we were assuming the first model (frozen guideline/dynamic techniques). Therefor, the only the Guideline document would be the Proposed Recommendation. The Techniques document would not be part of the formal recommendation, but a reference adjunct.
JW: something about the complexity of tables should go into the Guideline since it is critical and will not change over the life-cycle of the recommendation.
There was some discussion of what algorithm to use for definition of simple or complex tables. GV, DD and JW had thoughts on the topic. DD working on simple table linearizer in the ER WG.
GV: we will take this topic off call and onto list for further discussion.
JW: obviously an improvement. Thinks the style could be improved somewhat, but the content is generally OK.
GV: should we have a professional editor go over it?
JW: thinks Gregg and Wendy should be able to do it.
There was some concerns that we weren't all looking at the same abstract. Everybody to check for the latest version and review comments. CMN to look at the wording of a particular paragraph.
AG: a good look at language complexity.
DD: should mention level of knowledge needed by users.
GV: and point to the easier stuff being done by EO and others.
DD: it is a very complex area, including some things not controlled by W3C: Includes DOM, scripting languages (JavaScript, Visual Basic, etc.), Java. We need to give the users some indication of the complexity of the issue.
DD: If we don't say what scripting language is the best for accessibility, we will have a hard time defining accessibility of the results.
GV: the guideline says that you must only use W3C technologies, and since there are no W3C scripting languages you must create an alternate page.
JW: if there is some content in the document that is exposed to the user which depends on the dynamism then the alternative page is necessary.
GV, WC: some confusion about why script accessibility is under Approved W3C features and Technologies - no script languages are W3C technologies, but the ability to run scripts is a W3C feature.
GV: will remove W3C Technologies from guideline A9 and look at wording of C1
AG: if people are going to script their pages, the author takes on the responsibility of ensuring the script results is accessible.
JW: but only if the user agent supports the scripting language
AG: are we going to tell people not to use DHTML?
All: NO.
AG: then we should tell them that we can't tell them everything about how to make scripts accessible.
JW: we can tell them to make scripts as accessible as possible and to duplicate the functionality if necessary
5:00 PM - - Jason White had to leave at this time.
GV: thinks that most of the wording we need is already in the guidelines, but scattered. Maybe we can define what DHTML is, and point users to the various aspects of it that are covered in the existing guidelines. They are just not grouped.
AG: all events that don't require a keyclick or mouseclick are expendable
CMN: likes Al's comment about a disclaimer of having to say more later since the event model is a bit of a mess at this point, and there will be changes to what you will be able to do. We should be looking forward to what will be coming. (Even though we don't really know what that will be.)
WC: need to feedback into other groups, like UA and DOM
AG: user agents should be able to present some events in accessible way.
CMN: thinks that UA will have a harder time than we might guess.
AG: the ideal thing is that the script tells you what it will do if you activate it. (e.g. "title" on a link)
All: There was a lot of discussion around this issue.
GV: Are there any key issues about DHTML that we haven't touched on?
5:10 Ian Jacobs joined the call. Asked if we could start at the beginning. <grin>
IJ: want use of the term DHTML dropped from the guidelines.
GV: would like to define it for the purposes of our guidelines as "such and such" and the problems are addressed by looking at its components and functionality.
IJ: user agent be required to provide all functionality through accessible means. E.g. "ondoublclick" must be made available in some accessible means.
CMN: had in mind mouseover, mousemove, etc.
GV: say they should be expendable or redundant.
We need to continue on discussion of these issues via e-mail.
IJ: will dredge up the information he has done for AU on dynamic stuff and transfer it to PA.
WC will work on C1.
AG will take a shot on writing up thoughts on handled events. Will dredge it up.
IJ tot post something on separation of events, and work with Charles.
CL will try to schedule the next few conference calls.
GV: proposing conf call once a week for the next the next few weeks. Wednesday 4:00 PM
AI: Chuck to verify and try for the required dates and times.