Summit meeting between the User Agent working group and the Page Author working group to resolve issues affecting both groups.
Al Gilman (AG)
Harvey Bingham (HB)
Ian Jacobs (IJ)
Chuck Oppermann (OP)
Gregg Vanderheiden (GV) - chair
Wendy Chisholm (WAC) - scribe
Jon Gunderson (JG)
Jason White (JW)
Judy Brewer (JB)
Charles McCathieNevile (CMN)
GV summary: need something so that user can easily reposition or jump over navigation bars. this will require markup so that it is clear what it is (a navbar) and so that UA or style sheet or what not can do this.
AG curious of status of start-reading bookmark.
GV if several tables, several start-reading bookmarks?
AG if a navbar before start-reading bookmark, then provide a jump. Only provide jump over initial navbar.
/* Disucssion about what this means and its implications */
GV have a link, that says jump to x point in doc.
JW use style sheets
CO so on ms.com, put a link at top of the pg before navbar, says, "jump to content"?
AG could be 1st or 2nd position in navbar. early in sequence of tabstops. and take you probably to first H1.
/* discussion of ms page and how this would look - it could not be visible, for instance (included in the navbar). */
AG or person may put an icon, make invisible, as long as functional.
GV gives us a skip function, but doesn't necessarily give ability to find navigation bar.
AG yes, a trade off. better penetration in short term.
CO how would it benefit someone? what if nothing happens? if content is already visible in viewport?
AG benefits when someone using tab to go through links. if too many to tab through before get to the meat.
CO because if viewport does not change, then the SR will not speak.
AG yes, here is where the UA comes in.
CMN simple solution is a 2-way set of links.
GV One at begin of navbar (start of navbar), one at end (end of navbar) so that you can jump to it (it can get focus)?
CO how differ from moving forward means to name rel link of navbar. so SR programaticaly get info and skip.
GV this an alternative.
CO benefit getting weakened.
GV so it seems we have two approaches on table: AG's advantage of jump link being today and tomorrow, vs other (programtic label) have to wait for a technology to implement.
IJ any reason to show a good way to create navbar, where first is link to interesting place in text. so, authors just learn to create good navbars. So, no need for rel or any UA anything. leave it up to authors.
JW so could use both techniques together, so that SS or other software could ID and skip. In techniques doc, show both used together.
CMN problem is the same as with d-link and longdesc.
GV maybe the hybrid is the way to go: operational today and takes us in the direction of tomorrow. don't want to get stuck doing a kludge.
CO maybe we're making more complex. "if page have a lot of links before content, provide a means of skipping links to get to content."
GV how do so that it is comprehensible to user?
CO every site do navbars differently. /* comment about ms page and where sighted find the "meat" */
GV many people look just at links.
CO we're telling people how to write sites
GV not telling what should look like, but what markup should be
/* discussion about how to progress */
CO concerned about how designers of large sites would feel about this.
/* consensus that this should be a P3 */
JW div and class as described last week is good
/* discussion about benefits of Style sheets */
IJ idea is to predefine class name, whereas rel is designed for that.
CMN rel and rev designed to relate links. with DIV that relationship doesn't apply. If you want to ID, probably use title to say "this is a navbar" class to control style. we say get away with not using title, have class that is recognizable. have reservations about that approach. like to see title and class.
/* JG drops out for a bit */
/* discussion about this */
IJ concerned about precedence to predefine class name
JW increasingly necessary as people predefine structures of text, styles, etc. so reasons for any way.
/* judy off */
GV consensus that good to mark-up navbars so that we can find or jump over. 2. techniques
CO i appear negative because people who are not gung-ho about accessibility will go "huh?" it weakens the rest of the guidelines. especially when they are ambiguous.
JW but, they are priority 3, no one has to deal with.
CO this be an excellent version 2 guideline. after judge reaction to initial set of guidelines. It is an idealistic guideline.
JW however it's forward looking, stable, doable today
GV when lists get longer, priorities of even the top items get weaker.
CO we try to look at the inverse - low-hanging fruit. easy and high-impact then is good.
GV feeling I get is that navbars are a nuisance. can tab through large numbers of navbars over and over again, since can't tell where begin and end. whereas visual person can easily skip by.
JW yes, become a major waste of time to tab through.
GV concern that invisible links start to look "kludgy?"
JW the visible part may go into techniques rather than technique in guideline.
CO who's using invisible d-links?
GV a number of sites.
CO would like to see a list of sites using to help push through at MS. Other than WGBH.
GV yep, can do. @@create list of sites using d-links, particularly invisible d-links
CO concerned about how to exactly tell how to solve.
GV why wouldn't div be a way to do it?
CO div is a great way. invisible links is the kludge. yes, there is a problem and should be solved.
JW but footnotes are a common thing. problem with where link to.
GV what if under the techniques we say something about nav clusters be appropriately marked (e.g., div, class, etc.) In techniques it would give an example, "it's even nicer for current (in the meantime) use ..."
JW no - should be in guidelines since doable and usable today.
CMN the problem is the link technique is the only one that will work today. a p3 problem for blind users, this is how you do it. so, will make access thing a hard sell. to shy away from doing that is not in keeping with the purpose of the exercise.
JW some sites will take it up. agree with CMN totally.
GV the d-link is a p1, so that's why we do there.
AG (rating) depends on the number of links.
CO agree with problem, but not with the technique.
/* continuing discussion about MS page */
/* JG back, IJ out */
AG push to off the call discussion
GV everyone agrees with div/class/title?
AG wrinkle - if in a frame, don't want to envelope further
JG different style on different buttons?
AG question is: do you have a container that collects navbar? then class that, otherwise then span/div and class. to coordinate with UA not clear what they are coming down on with the focusability and navigation of eleements. so may be able to skip w/or w/out class mark.
CMN nav by arbitrary element rather than specific elements.
GV but how now navbar link from other links if not classed?
AG it could focus on the div, and read the title, then user know to skip.
GV if div said navbar, then skip.
AG title then works without conventional class.
/* agreement */
GV only purpose of class - if user wants to do something with style sheet.
GV 1 if haven't already wrapped cluster of links (with frame, etc) then use div/span. /* consensus */ 2 whether or not need class? -
AG defer item, but clarify what happen on UA side.
GV so keep class, not enough to justify bumping it out. link from beginning of cluster to some meaningful location is good, but
JW link at start of nav cluster with an anchor whose target is at main text of doc or at end of nav cluster. in techniques, but example. show how achieved (a name=) first few words of doc.
CO disagree. not nav structures, but groups of links that people want to skip over. what if cluster at end?
JW then link take you to top.
CO not necessarily navigation, just groups of links.
AG the mention of the technique - you may provide a link that bypasses the problem area. example at acb site. worht mentioning as technique because of early impact.
GV capture - then take to the list. you may provide a link that bypasses the link cluster.
/* CMN and CO jumping off */
GV @@
IJ have people been considering coupling between UA and PA with LINK and basis for building navbar. UA could use to construct navbar so author not have to author specifically.
AG only be auto-generated if redundant.
GV another topic, interesting, but time flying. UA implications?
JG nav buttons exposed through DOM. if a p3 should deal with this on the list.
JW any problems with how choosing to define tables?
HB col heads at top and bottom, all referenced by ID. also row stubs at start and end of row, for western languages left to right, or possibly right to left for hebrew and some eastern languges)
AG should not take HTML defn, should determine what UA do. those that aren't clear treated as complex. how many people implemented the algorithm such that it will be understandable when reach a UA.
JW algo included in UA alg.
IJ if not there, it should be.
AG real coupling between UA and PA. PA predicated on UA, what UA do is under debate.
GV are you suggesting not use 4.0 defn?
JG 4.0 defn incomplete and one way to define headers, not only way
JW 4.0 defn an attempt to come up with an algorithm. thus the question from last week was to accep html 4 defn, or look for simpler. one that would satisfy the algo but considered complex.
GV DD's comment was he like to see it be more restrictive that what in 4.0. but consensus is to go with 4.0 defn. but means that UAs have to use that algo at least.
/* clarification of the 4.0 algo */
JW since stated as recommendation, then need some priority within UA guidelines.
AG so the issue is if UA not going to implement algo, then PAs must be more aggressive.
IJ editorial note in UA techniques doc - we have to define where header info comes from. some combo of HTML 4 algo, TH, etc.
GV, UA should be able to linearize those that are marked up using 4.0 spec. our end: if table more complex than what said in 4.0, then require further markup.
IJ /* read from 11.4.3 of 4.0 spec */
GV Daniel was suggesting that we modify that language to be stronger than what in 4.0 spec (ua side). pa - IF it doesn't work on algo, then have to mark up.
JW a way to define those characteristics that would make it fall outside of the algorithm? help people fit or not. ways to classify tables that won't work? @@
HB suggestion for techniques doc
WAC nested tables
AG can use header on TD that contain TABLE element.
GV do we want people to identify if tables used for layout.
AG if linearize in simplest way don't need.
GV if linearize table, then should have a "try again."
/* discussion of potential algo and current UA attempt*/
GV no recommendation that tables used for layout have identification as such?
HB use CAPTION to describe.
GV should it be a standard name to help UA?
AG the PA group should welcome nominations from UA group re: standard name.
JW status of table conversion to style sheet tool?
GV great idea. how do? help to UA?
JG if just layout, just use TD elements. don't use TH, or anything else. so don't need any special recommendation. people using TH for visual effects. @@ add to guidelines
/* IJ dropping out */
GV don't use semantic markup for visual effects.
JW specific example needed in techniques.
no discussion today
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. #2 in general - if create scripts to create a new user interface (pages that change based on user events) then need to follow UA guidelines (support keyboard, etc.) #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 #4 how does the user know what has changed on the page
JW what extent goes into the technique doc? harmonizing the techs. between both sets.
GV how much capture each of the diff. pieces, anything done further in g'lines or relegate to t'niques.
JW Do the recommendations on the avoidance of event bubbling, and description of the event on the page, warrant separate treatment in the guidelines?
AG if scripts transform gracefully then everything else P2 (i.e., direct access)
/* discussion about how UAs group preferences and configurability features */