4:00 - 5:30 PM EST
CL: Chuck Letourneau (scribe, co-chair)
WC: Wendy Chisholm
JW: Jason White
CMN: Charles McCathie-Nevile
JG: Jon Gunderson
GV: Gregg Vanderheiden
GV/WC: Haven't taken tables to the list, haven't prepared a list of
Some discussion about table types that aren't in the guide yet and might need further discussion on the list.
JW: the algorithm should go into the techniques document where it is appropriate
JG: #1 . device independent events. the UA guidelines are proposing a
simulation of mouse events by the keyboard, determine what author has to do -
bind event to specific element rather than rely on event bubbling.
On UA: there are some types of scripts that allow for keyboard interaction. Using ONFOCUS rather than ONCLICK.
JW: put it as a technique under scripts with a P2 priority.
CMN: cant rely on scripts anyway over a wide variety of browsers. He
has posted a message about this sort of thing and will try and find and
JW: the use of server-side scripts as a substitute for client side ones because of lack of support for client side, that technique isn't explicitly discussed in the guidelines, and should be included in the section on graceful degradation.
CMN: agrees that should go in. IN techniques there should be a corresponding example.
JG: the university uses server side Java that is invisible to the visitor to reformat data that they send.
JW: servers handle the validation rather than client side script that might be inaccessible.
WC: In A9? Ensure that newer pages will transform gracefully" Technique 2 add "or a server side script"
CMN: would make it more explicit by making it a separate technique: "wherever possible use a server-side script"
WC: since we aren't explicitly separating client-side or server-side scripts.
JW/CMN: use server-side scripts as much as possible at the present time.
JG: but what does this have to do with the original question.
CMN: For events triggered on device specific events, only make them expendable or trivial routines.
JG: if you can't do it on the server-side or do it in NOSCRIPT as Priority 1, but Priority 2 use independent events as triggers.
CMN: thinks it should be a technique in A12.
WC: sees techniques document developing into something wider than HTML, i.e. scripts, XML etc.
JG: #3 how does the user know what a script does apriori, only the author knows. What to do from the author side for author to provide information, then how does UA pass to user
JW: could be handled in UA by providing an option to display the
JG: several different elements do different things.
CMN: the NOSCRIPT contains the information about what the script will do.
JG: instead of using TITLE etc.?
CMN: Yeah, stay away from stuff that isn't supported and wont be for a long time.
JG: is it in the guidelines or techniques to have user events directly accessible? (sec. I am not sure about the question: too many talking at the same time... JG fill in if possible)
CMN: some techniques might be warnings rather than hard and fast techniques.
JW: Possible techniques: providing a textual explanation in the same or linked document of the function of the scripts where this is not immediately obvious. And, Try to associate scripts with the elements that activate the events. Priority 2 techniques.
CMN: these techniques might be a hard sell.
JG: but repair strategies in UA will require linking of the scripts to the events and elements.
CMN: At the moment, all techniques are going into the guideline document, but if we are going to update the techniques document in the next months?
WC: hopes the techniques in the guidelines are abstract enough
JG: #4 how does the user know what has changed on the page?
CMN: all the author can do is make it clear what will happen. Not much else you can do.
JG: question relating to elimination of priorities on the guidelines
themselves? He had proposed the same thing for UA and Judy didn't like it.
JW: there is some grounds for making some change since the guideline priorities are weighted very differently.
WC: we are not taking all priorities out of guidelines, leaving them on the techniques that are listed under each guideline, but off the guideline itself.
Consensus that the techniques in the guidelines have priorities.
JW: Why not keep priorities on the techniques, but put some indication of importance (eg a symbol or the word "important" on the guidelines that have priority one techniques. We need to separate the definitions of priority from importance.
WC: of the six guidelines that are priority 2 some are on the edge of importance, like LANGUAGE and W3C DOCTYPES, so there might be very few non important.
Prioritized list in the appendix
WC: Bobby checks only for priority techniques, and not priority guidelines.
JW: why not say in the introduction that all P1 Techniques must be implemented and some technique from every guideline.
JW: removing the priorities from the guidelines should be mentioned to the EO group.
Action Item: please respond to Gregg's message about priorities on guidelines on the list.
JG: there has been a lot about marking up Nav bars? Has consensus
been reached yet?
WC/GV: we haven't reached a consensus yet.
JG: the UA needs a consistent method to be able to ensure the right outcome.
GV: we need to achieve consensus quickly on this issue.
WC: thought that the user agent would allow navigation by element (walking the document tree) since the navigation links will be some kind of element (div, link, etc,) then by being able to walk the tree and get the element, you can either get the list of links or skip on to the next level
JW: 1. That might not be completely satisfactory since you would also have to have the title of any block level element, 2. If we decide to use map as the container (since it is INLINE) in that case, would we have to make some recommendation as to the uses of MAP that don't have an inline image.
CMN: no we don't have to ask UA to do anything special with MAP since it works backward compatible, and go back to HTML group to ask if they can change the way MAP is specified.
JW: that would mean waiting for the next generation of HTML
CMN: would be prepared to say: note that this contravenes the specification.
JW: would recommend against using it for that reason. IF it is going to be a validation problem, then use any container and use a class.
JG: anyway, this is a P3.
CMN: either put a link to jump past it or we could just ask that nav be put at the bottom of the page.
GV: what about "unless the nav bar is positioned at the bottom of the page, then include a jump to bypass it".
Action item: GV and WC will put out some key points and ask for a last call of discussion about handling the Nav Bar.
JG: more discussion about table linearization as a UA technique. Check that list. Also UA face to face on December 11 or 12. CMN please register.
Will try for Thursday, December 3 at 4:00 EST