- From: Hansen, Eric <ehansen@ets.org>
- Date: Wed, 14 Mar 2001 22:26:01 -0500
- To: "'Ian Jacobs'" <ij@w3.org>, w3c-wai-ua@w3.org
Following are a few comments: > -----Original Message----- > From: Ian Jacobs [mailto:ij@w3.org] > Sent: Friday, March 09, 2001 10:03 PM > To: w3c-wai-ua@w3.org > Subject: 9 March 2001 UAAG 1.0 Guidelines and Techniques available > > > Hello, > > I've published the 9 March UAAG 1.0 Guidelines [1] > and Techniques [2]. Changes are online [3] and quoted > as text below. > > Please review this draft! > > I *strongly* encourage you to review this draft of the document. > We have resolved all of our last call issues and I don't > anticipate any other major changes to the document > (unless your review reveals significant problems). > > The Working Group agree in the next couple of weeks that > we are done and wish to advance to last call (after which > I get to prepare the document for our third last call). > > -------------------------- > Important things to review > -------------------------- > > 1) Please review addition to checkpoint 4.5 about > playing audio during fast advance/reverse. > > 2) Please review checkpoints 4.13, 4.14, 4.15. I rely > on the expertise of the group to get the wording > of these speech requirements right. > EH: It is not obvious to me that checkpoint 4.15 (user defined extensions re: speech) expresses a clear minimum requirement. Seems to need refinement. > 3) Please review the first 7 checkpoints of Guideline 9; > I think they look great! EH: I think that these are really important improvements.... > > 4) Please compare 9.2 and 9.7 and see whether the difference > is sufficiently clear. EH: Maybe OK... > > 5) Please check out definitions of animation, enabled element, > interactive element, and focus. > EH: Enabled element entry is out of order. Re: Enabled it is not clear who or what is doing the 'choosing'.... Is it the user or the user agent or the state of the interaction causes it to be chosen? Also, if it can happen through an API then other programs can do it. Why not remove the parentheses? Also since it must happen during a session, it could not be enabled through prior configuration.... right? Old: Enabled element, disabled element, An enabled element is a piece of content that is subject to user activation through the user interface (or indirectly through an API) at a chosen moment during the user's session. The set of elements that a user agent enables is generally derived from, but is not limited to, the set of interactive elements defined by implemented markup languages. ... New: ? Enabled element, disabled element [REMOVED COMMA] An enabled element is a piece of content that is subject to user activation through the user interface or indirectly through an API at a chosen[???] moment during the user's session. The set of elements that a user agent enables is generally derived from, but is not limited to, the set of interactive elements defined by implemented markup languages. ... == Focus Can the first sentence be made more precise (at most, at least, etc.)? "When several viewports coexist, each may have one content focus and one user interface focus. At all times, only one viewport's content focus or one user interface focus receives input events; this is called the current focus." New [????????]: "When several viewports coexist, each may have AT MOST one content focus and AT MOST one user interface focus. At all times, AT MOST only one viewport's content focus or one user interface focus receives input events; this is called the current focus." Comment: Are these definitions incompatible with braille output viewport... Just checking robustness. > 6) Pleae review checkpoint 2.4 (new wording and new alert > requirement). > > 7) Check out the new section on how to refer to this document. Old: "For very general references to this document (where stability of content, anchors, etc. is not required), " New: "For very general references to this document (where stability of content, anchors, etc.,[ADD COMMA] is not required), " > > ------------- > What's next? > ------------- > > * Add executive summary EH: See separate memo. > > * Address concern about "contradictory" statements of > checkpoints 1.1/1.2 > > * Al Gilman may have some suggestions for us about > issue 464 [4] (How to account for captions in SMIL). > > * Now that we have resolved last call issues, I must > respond to all last call reviewers to see whether > they are satisfied or wish to register objections. > > * The Techniques document needs to be read! > > * The implementation report needs to be updated. I predict > that we now have requirements for which we have no > implementation experience, and we will need to > concentrate on these during Candidate Recommendation > (if we need to go to CR). > > ------ > Trivia > ------ > By the way, for those keeping score at home, this is the > fifty-fifth (55) draft of the Guidelines. Let's stop (at > Rec) when we hit 60. > > Cheers, > > - Ian > > [1] http://www.w3.org/WAI/UA/WD-UAAG10-20010309/ > [2] http://www.w3.org/WAI/UA/WD-UAAG10-TECHS-20010309/ > [3] http://www.w3.org/WAI/UA/wai-ua-wd-changes.html#WD-UAAG10-20010309 > [4] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#464 > > -- > Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs > Tel: +1 831 457-2842 > Cell: +1 917 450-8783 > > ---------------------------------------------------------------------- > CHANGES > > General > > * Editorial: General substitution of "Allow the user to configure > the user agent to" to "Allow configuration to" > * Editorial: Global substitution of "active element" with "enabled > element". Introduction of term "Interactive element". > * Editorial: Some changes based on comments from Aaron Leventhal. In > particular, changed "must" to "needs to" in a number of places > (e.g., guidelines prose, techniques) to avoid impression that > required for conformance. EH: Very good suggestion by Aaron Leventhal. > > Introduction > > * 1.3 (Known limitations): Added a limitation that there is no > requirement in this document for all user interface components to > be under final user control; this is covered to a large extent in > Guideline 5 and also in other software guidelines. > EH: Good. > Guidelines > > * Guideline 4 split into Guidelines 4 and 5. Moved checkpoints about > control of UI behavior to new Guideline 5. > * Guideline 5 split into Guidelines 6 and 7. > > Checkpoints > > * 2.4: Checkpoint wording changed per 1-2 March face-to-face. > Added alert requirement as well. Please review. ( issue 460). EH: Seems OK... I assume that it was thoroughly discussed. > * 2.5: Changed from "allow the user to specify" to "allow the user > to configure or control". > * 3.2: Content type "Animation", not "Image". But leave video as > well. EH: Not sure what this comment means. > * 4.4, 4.5, 4.6, 4.7: Changed "video and animations" to "animations > (including video and animated images)" per proposal from Ian > adopted at 8 March teleconf. > * 4.5: Important Based on discussion at 1-2 March face-to-face, > added the following statement: "The user agent is not required to > play synchronized audio during fast advance or reverse of > animations (though doing so may help orient the user)." EH: Good. > * 4.13, 4.14, 4.15: Important These are derived from one single > checkpoint per 1-2 March face-to-face resolution. These > checkpoints need review! (Didn't do much to move techniques around > yet.) EH: See my earlier comment about 4.15. > * 5.1, 5.2, 5.3: Changed per proposal from Ian, adopted at 8 > March teleconf. EH: Does confirming a prompt meet the definition of 'on demand'? Just not sure may be OK (checkpoint 5.3). > * 6.5: (Editorial) Selection and focus are no longer part of "UI > controls". > * 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7: Now form a coherent > content-focus navigation model (among viewports and among enabled > elements and among history). Changed per proposal from Ian > (adopted at 8 March teleconf) in conjunction with resolutions > from 1-2 March face-to-face. > * 9.1: Removed this Note: "Navigation among all viewports implies at > least allowing the user to cycle through all viewports." > * 9.2, 9.7: Based on comments from Aaron Leventhal, attempt at > making the differences between these two checkpoints more apparent > (note that the first sentence is the same in both, but the other > two differ). EH: Differences are really hard to spot. But I don't know if it is worth trying to clarify. Probably OK. > * 9.8: Clarification about where the default search starting point > should be (when user has not indicated). Based on resolution from > 1-2 March face-to-face. EH: For checkpoint 9.8, the idea of the 'alert' seems like only half the requirement. Do we mean to say the the person should have a choice about whether to terminate or continue the search wrap that is about to occur? Also, if one wants to terminate the search, what should happen to the focus/selection? Seems it should be made explicit... Old: 9.8 Allow the user to search within rendered text content for a sequence of characters from the document character set. Allow the user to start a forward search (in document order) from any selected or focused location in content. When there is a match (1) move the viewport so that the matched text content is within it, and (2) allow the user to search for the next instance of the text from the location of the match. Alert the user when there is no match. If the search wraps back to the beginning of content, alert the user prior to wrapping. Provide a case-insensitive search option for text in scripts (i.e., writing systems) where case is significant. [Priority 2] Note: If the user has not indicated a start position for the search, the search should start from the beginning of content. Use operating environments conventions for indicating the result of a search (e.g., selection or content focus). A wrapping search is one that restarts automatically at the beginning of content once the end of content has been reached. > * 10.7: No longer talks about current viewport; instead viewport > with current focus. Changed per proposal from Ian (adopted at > 8 March teleconf). > * 11.4: Browser history is not required, so history stage change > bindings moved to "if supported" section. EH: Cool checkpoint...! > * 12.2, 12.5: Edits to Notes based on comments from Harvey > Bingham. > > Conformance > > * Applicability: Added some comments about event bubbling to third > applicability provision. > * 3.5 Responsibility for Claims: Changed wording from "anyone may > make a claim" to "this spec imposes no restrictions about who may > make a claim". > * 3.1 (Content type labels): Made some adjustments based on > definition of Animation that includes Video and Animated Images. > In particular: Animated images are part of animation, not images. > The goal was to have video/image/animation conformance overlap as > little as possible. Also adjusted Speech label based on two new > speech checkpoints. > > Glossary > > * New term: "Animation" (per 8 March discussion. > * New term: "Enabled element" > * New term: "Interactive element" > * Deleted term: "active element" > * Deleted term: "current viewport" > * Per 1-2 March face-to-face, changes to the terms "focus" > (content focus and user interface focus), "selection", "point of > regard". > * "Event handlers": Added "An event handler is 'explicitly > associated with an element' when the event handler is associated > with a particular element through markup or the DOM." > > References > > * New section "How to refer to this document". Distinguishes this > version from latest version. Gives sample HTML markup. EH: Good. > * Added [SMIL20] > * Fixed some cross-linking bugs between Guidelines and Techniques > pointed out by Harvey Bingham. > > Techniques > > * 2.7: Added some examples of "required" conditional content. > * 3.5: Added technique to configure-content refresh based on CMN > example. > * 4.4, 4.5: Added some techniques for doing this in SMIL 2.0. Added > some info about applicability and streaming. Added techniques > pointing to digital talking books information. > * 5.1, 5.2: Some techniques added. > * 5.5: Suggest warning user that some fee mechanisms may not be > "caught" in this configuration. Added per 1-2 March > face-to-face resolution. > * 6.1: Added rationale about advantage of access to source content > to ATs (rather than offscreen access). > * 9.9: Added some comments about where important information is > identified from (e.g., specs, metadata). > * 12.3: Added a technique to document where UA diverges from system > conventions. >
Received on Wednesday, 14 March 2001 22:26:38 UTC