- From: Al Gilman <asgilman@iamdigex.net>
- Date: Thu, 31 Aug 2000 21:31:33 -0400
- To: w3c-wai-ua@w3.org
At 02:02 PM 2000-08-31 -0400, Ian Jacobs wrote: >Hello, > >Al's comments below suggest both that (a) the current checkpoint 7.6 >may not provide adequate navigation support to the user and that >(b) without additional study of the problem, he would not feel >comfortable offering an alternative. [Al, please correct me if >I've misstated these points.] AG:: I think you have escalated some of my comments one notch. It is at the "minimum implementation" level that I have demurred on providing an alternative, not the checkpoint. At the checkpoint level, I would prefer to summarize my last comment as "the latest change to add a list of element types to the checkpoint does not add [enough] value to the checkpoint and should be rolled back." The idea is that the checkpoint adds value to the document but then in addition adding the refinement of the checkpoint in terms of element types does not. But that leaves us with a 'checkpoint' that some may find unenforceably vague. So I am still working on this. "Does not add [enough] value" is short for "taken on balance, does not appear to add enough value to justify the attendant cost and risk." In this case, the proposed clarification saves cost [don't think, just code] but adds risk [may not do what is intended]. > >Based on these comments, here are some ways of moving forward: > >1) Leave the checkpoint as is. Add commentary to the > techniques document (e.g., based on what Al has written) > to give developers a clear sense of what users > need, even if the checkpoint is only about element types. > >2) Lower the priority of the checkpoint to a P3. Rationale: if the > checkpoint is not known to lower important barriers to access > as written, but is likely to improve accessibility, then it should > only be a P3 checkpoint. > >3) Delete the checkpoint. > >Al's comments suggest that his expectations about what the user >needs may not be easily turned into an algorithm ready-made >for developers, without further study. I do not have an alternative >checkpoint to propose at this time. AG:: Is there also the option to remove the detail, leave the checkpoint in the document at its present priority without benefit of a minimum implementation? One question is whether the other checkpoints for this guideline fully cover the guideline or not. I will have to look at it that way. I haven't tried to defend the guideline without this checkpoint. If removing this checkpoint leaves a hole in the coverage of the guideline, it may be better to leave it vague than leave it out. Al > > - Ian > >Al Gilman wrote: >> >> The text of checkpoint 7.6 now reads, with link numbers inserted: >> >> 7.6 Allow the user to navigate efficiently to and among important >> structural elements identified by the author. For markup >> languages with known semantics, allow forward sequential >> navigation to important structural elements. For other markup >> languages, allow at least forward sequential navigation of the >> document object, in document order. In HTML 4 [381][HTML4], the >> list of important elements is: A, ADDRESS, BUTTON, FIELDSET, >> DD, DIV, DL, DT, FORM, FRAME, H1-H6, IMAGE, INPUT, LI, MAP, >> OBJECT, OL, OPTGROUP, OPTION, P, TABLE, TEXTAREA, and UL. In >> SMIL 1.0 [382][SMIL], the list of important elements is: a, >> anchor, par, seq, and switch. In SVG 1.0 [383][SVG], the >> important elements are a and g. [Priority 2] >> Note: Structured navigation of headings, tables, forms, lists, >> etc., is most effective when available in conjunction with a >> configurable view ([384]checkpoint 8.4 and [385]checkpoint >> 8.5). User agents should follow operating system conventions >> for indicating navigation progress (e.g., [386]selection or >> [387]content focus). >> [388]Techniques for checkpoint 7.6 >> >> I am concerned that here we may have gone a bit too far in striving to be >> concrete, so as to be easy to implement. >> >> A key phrase is "important structural elements identified by the author." >> >> The catch is that while motion is only required to elements that the author >> has identified as elements, it is not safe to assume that the author has >> identified which elements are important, or that these can be determined by >> their element _type_ alone. >> >> * More factors than element type: >> >> My current working model for effective structural navigation, and >> identifying the "important elements" in any sub-document context, includes >> some propositions that do not necessarily turn into an algorithm directly: >> >> - The navigation is hierarchical; the identification of "important >> sub-elements" recursive. If one choses to scan the content below them on >> the tree they can move breadth-wise over the subtrees attached at the >> current node. >> >> - The navigation tree is an abstraction of the syntax tree. Not all nodes >> in the parse tree are stops in the navigation tree. >> >> - Fanout matters. The abstraction of the parse tree will be managed so >> that under a given node the number of children tends to cluster around some >> sweet spot, perhaps "seven give or take two." >> >> - Balancing quantitative measures of content matters. The abstraction of >> the parse tree will pay attention to the division of content as measured at >> least by a) time to read the text and b) number of links enclosed in a >> sub-part. The abstract navigation tree will attempt to approach >> eqi-division of these measures or predictors of how likely any given branch >> is to contain what the visitor is actually looking for. >> >> - And there are exceptions. In saying "select ranges should not be too >> long" it is an error to break up the list of two-letter postal codes for >> the U.S. states and the District of Columbia. Because the list of these >> jurisdictions is something where most users already know the entries (at >> least the names of the states) it is not an appeal to short-term recall and >> the "seven give or take two" rule does not apply. This is just one >> important exception. >> >> * Limitations of markup. >> >> Markup languages such as HTML and XML provide both sequence and hierarchy, >> but the markup format specifications do not provide adequate support to >> know when the hierarchy or sequential order is significant or accidental. >> My attitude on this may be unduly colored by my ambition to provide user >> agents with something better in the way of markup in the future. But we >> don't yet have either the authoring tool techniques nor the standard markup >> practices to implement this 'better' solution. >> >> The problem is that in order to pass critical threshold in the >> effectiveness of the abstract navigation tree, I am concerned that it will >> take applying more techniques than just checking the element type, but that >> reducing the formula to something that is reasonable to ask for will take >> more experimentation than we have calendar time for. If we try to nail >> down the navigation tree extraction method with what we know now, there is >> a risk that we will not meet the users' needs, impose unreasonable demands >> on the User Agent suppliers, or both. >> >> * Summary >> >> I have reservations about classing element types in the definition of this >> checkpoint as either "important" or "not important." >> >> It is a sufficiently multi-dimensional problem, as I see it, that I am >> relunctant to draw by guessing a line in the sand on one axis only. >> Element type is a very helpful hint in compressing the parse tree, but it >> may not be enough information to make the results a winner, and worth >> demanding. >> >> What element types have to tell us can probably be represented by an >> ordered list of [more than two] groups of element types. Some types are >> definitely more likely to be one of the "important elements" than other >> types. But given just this type-based knowledge, I am not sure we are >> above threshold for specifying what constitutes a "reasonable >> accomodation." The end result is at what depth the element shows up in the >> navigation tree structure, and not just is it in or out. >> >> Al > >-- >Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs >Tel: +1 831 457-2842 >Cell: +1 917 450-8783 >
Received on Thursday, 31 August 2000 21:17:18 UTC