4:00 - 5:30 PM EST
MIT Bridge
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
d-link sites.
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
re-post.
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
NOSCRIPT stuff.
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