- From: <thatch@us.ibm.com>
- Date: Tue, 28 Sep 1999 18:41:19 -0500
- To: menovak@facstaff.wisc.edu (mark novak)
- cc: Ian Jacobs <ij@w3.org>, w3c-wai-ua@w3.org
IJ: However, Thatch doesn't like the change from "content" to "structure" in the proposal, so I don't think we're settled here yet. Refer to his email [2]. JT: The new rewording referred to structure: IJ: Ensure that the user has access to the document structure expressed by markup in an output device-independent manner. JT: The reason I worry about the new rewording is that I believe a tree view of the elements (The Dom without text nodes) satisfies the new rewording and misses the point. That gives total access to the structure with no content. Is this close to your intent: Ensure that the user has access to content based on document structure as expressed by markup.... Followed by the 'for example.' I elided "in an output device-independent manner." I don't object to it but it seems gratuitous. I like the reworded ' for example' getting rid of 'understanding.' IJ: For example, ensure that the user has access to the content of a table cell, the content of a list item, the content of a header, etc. Jim Thatcher IBM Special Needs Systems www.ibm.com/sns HPR Documentation page: http://www.austin.ibm.com/sns/hprdoc.html thatch@us.ibm.com (512)838-0432 menovak@facstaff.wisc.edu (mark novak) on 09/27/99 04:15:52 PM To: Ian Jacobs <ij@w3.org> cc: w3c-wai-ua@w3.org Subject: Re: Proposed changes to UAGL to address conformance issues. hi Ian my comments below at MN2 mark >Hi Mark, > >My comments preceded by IJ: below. > > - Ian > >mark novak wrote: >> At 10:32 AM 9/15/99, Ian Jacobs wrote: >> >Hello, >> > >> >Please consider the following changes to the UAGL >> >(27 August version [1]). This proposal attempts to resolve >> >various questions (e.g., [2]) about how different types of user >> >agents will conform to the document. The proposed changes >> >remove the need (I hope) for a graphical/dependent split >> >while keeping the goals of the checkpoints intact. The >> >last change suggests a split of a different sort to >> >address interoperability. >> > >> >[1] http://www.w3.org/WAI/UA/WAI-USERAGENT-19990827 >> >[2] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#79 >> > >> >PROPOSAL 1) Checkpoint 1.1. The current text: >> > >> > Ensure that all functionalities offered through >> > the user interface may be operated through standard >> > input device APIs supported by the operating system. >> > >> > I propose that we split this checkpoint into two: >> > >> > a) Ensure that all functionalities offered through >> > the user interface are available through all supported >> > input devices. Note: The device-independence >> > required by this checkpoint applies to functionalities >> > described by the other checkpoints in this document >> > unless otherwise stated by individual checkpoints. >> >> MN: my first question would be, who determines what are >> "supported" input devices. Is it the user agent developer, is >> it the user, is it the operating system, etc...follow below > >IJ: That's a good question I also asked myself during my review > of NN [1]. There are a number of checkpoints, in fact, where > finding the answer requires intimate knowledge of the > software's specs. That's an issue I'd like to discuss > elsewhere. However, to answer this specific question, > in my opinion, the developer > must make claims (somewhere) about what APIs are supported. > >[1] http://www.w3.org/WAI/UA/uagl-checklist-nn4.60 > >> > >> > b) Use standard input device APIs provided by the >> > operating system. >> > >> > The text of (a) comes from previous versions of the >> > guidelines. However, I think checkpoint 1.1 in [1] mixes >> > two very important points: all functionalities must be >> >>available >> > AND use standard input device APIs. Thus, I propose the split. >> > >> > I have noted that while reviewing Netscape Navigator, that verifying >> > (a) is near impossible unless you are a developer or have access to >> > details about how the tool's internal APIs connect to the interface. >> > I propose that we include a note in the document that informs users >> > that it may be difficult to verify certain checkpoints without >> > detailed software documentation. >> >> MN: Yes there are two important points in 1.1, but the second point (b), >> as you say >> is near impossible to determine unless you are a developer. > >IJ: Yes, I agree. MN2: I'm thus still in favor of the original wording, and not splitting 1.1 into two parts. >> However, >> the user ought to be able to use, on a graphical desktop user agent >> designed for an operating system that fully supports the keyboard >> and mouse, either the keyboard and/or the mouse to operate the graphical >> desktop user agent (which isn't saying anything not already stated >> in numerous design guidelines for accessible software...) >> >> What I'm trying to point out, is that the "supported input devices" >> from 1.1 above would seem to be those input device APIs supported by the >> "operating system/platform", and thus I don't see any good reason to split >> 1.1 into >> two checkpoints. > >IJ: So should all UAs be required to support all input-device > APIs available for the operating system? > I don't think so, even though we hope that mainstream > browsers support at least mouse > and keyboard APIs. That's why I think in the end it's not > the available APIs that matters, but the available APIs that > the software developers claim to support. > >> >PROPOSAL 2) Checkpoint 3.2. The current text: >> > >> > Ensure that the user has access to the content of >> > an element selected by the user. >> > >> > This checkpoint is the evolution of a requirement for access >> > to individual cells, list items, etc. However, I think some >> > of the intent is lost in the current wording. I propose >> > the following: >> > >> > Ensure that the user has access to the document >> > structure expressed by markup in an output >> > device-independent manner. >> > >> > For example, ensure that the user can clearly >> > understand the content of a table cell, the >> > content of a list item, the content of a header, >> > etc. >> > >> > Techniques: >> > a) Provide a view of the document structure (e.g., >> > a tree view of all elements). >> > >> > Note that "output device-independent manner" means >> > for output devices supported by the software. >> >> MN: I'm not disagreeing that some of the "intent" is lost >> in the current wording for checkpoint 3.2, but I actually >> am more confused with the wording proposed. I don't think >> we can ensure the "user can clearly understand the content >> of a table cell", for example. I think we can provide access >> to the content, but understanding the content is an entirely >> different issue. > >IJ: I agree. > >> Maybe just minor word smithing here, but >> important non the less. > >IJ: So I'd change to something like "For example, ensure that > the user has access to the content of a table cell, the > content of a list item, the content of a header, etc." > >IJ: However, Thatch doesn't like the change from "content" >to "structure" in the proposal, so I don't think we're settled here yet. >Refer to his email [2]. > >[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0375.html MN2: I don't understand. To me "structure" and "content" imply two different things. I prefer the original wording using "content" when refering to an "element", which to me also implies some kind of markup, otherwise I'm not sure what determined I have an element. My first wording change was trying to give the "element" some identity, by describing a table cell, list item, etc. , which was what I thought the original checkpoint dealt with versus the proposed change to structure, that's all. > >> I'm also not clear as to how the technique >> of "Provide a view of the document structure (e.g., a tree view >> of all elements)" satisfies the access to the content of >> an element. I think this is a good technique, but maybe in the >> wrong place? > >IJ: The idea would be that by respecting the structure in the view, the >user would have easier access to content. This needs clarification. MN2: Ahh, certainly, that helps and I agree, that this is indeed one method to provide easier access to the content, via a structure related/organized "view". >> >PROPOSAL 3) Checkpoint 3.3. This checkpoint should not be >> > for dependent user agents only. Refer to issue 84. >> > >> > [2] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#84 >> >> >PROPOSAL 4) Checkpoint 8.3. The current text: >> > >> > Allow the user to navigate just among table cells of >> > a table (notably left and right within a row and up >> > and down within a column). >> > >> > I propose that this checkpoint be for all users agents, with >> > the following note afterwards: >> > >> > Navigation techniques include keyboard navigation from >> > cell to cell (e.g., using the arrow keys) and scrolling. >> > Note, however, that users must be able to navigate in >> > an input-device independent manner. >> >> MN: Suggest the following rewording instead ? >> >> Allow the user to navigate while staying within the cells >> of a table (notably left and right within a row and up >> and down within a column). > >IJ: I don't understand "staying within". The problem is that > navigation and access are intimately linked here. Navigation > is just a technique for more efficient access to cell content > (just as tabbing navigation provides efficient access to links > and form controls). One day I want to delete this checkpoint > and make it a technique, another I think it's important as > a checkpoint in its own right. Can we shorten to "Allow the > user to navigate the cells of a table" along with the good > examples you provide below? MN2: Perhaps I jumped ahead of things here a bit, but my concern is that navigating a web page, and navigating a web page table, might in fact be best done using the same keyboard keys, for example. Thus the UA or dependent UA must some how distinguish when the user is in one mode or the other. Thus my adding "staying within". Also, what I don't think we address, although I'm not sure we have to, is how the user gets into a table to start with, prior to navigating it. >> For example, keyboard navigation from cell to cell >> might be accomplished using the using the arrow keys >> where as voice navigation from cell to cell might be >> with voice commands like up, down, right, and left. > >IJ: Sounds good. > >> I'd like to see this be a checkpoint for *all* users agents >> as well, since it is certainly a needed function, > >IJ: That's the kind of comment that makes me shift towards >favoring this as a checkpoint, not a technique... > >> however >> reality tells me that it won't fly as a P1 for all user >> agents, but it is certainly something to shoot for. > >IJ: So P2? MN2: I think it depends upon the final wording. I'd certainly like all user agent's to provide this capability. >> >PROPOSAL 5) Checkpoint 9.2. The current text: >> > >> > Provide the user with information about the number >> > of viewports. >> > >> > I suggest that the principle of this checkpoint applies to >> > all user agents. I suggest that it be rewritten: >> > >> > List all viewports (including frames). >> > >> > Netscape 4.6 lists windows and frames, Lynx >> > lists frames, Opera 3.51 lists windows and allows keyboard >> > navigation of frames, IE 4 lists windows (but I don't see >> > how to list frames). All of NN, IE, and Opera allow you to >> > view the HTML source, which is a clunky way to find the >> > frame structure. >> >> MN: "Clunky" is a polite way of saying, their user agent is broke! >> >> I would not even think about the idea to "suggest" a user have >> to look at the HTML source to understand something about a web page >> in the context of these guidelines...which is not to say that we >> all don't do this at some time or another, just that it doesn't belong >> here. > >IJ: But is the proposed checkpoint text ok? MN2: sure > >> >PROPOSAL 6) Checkpoint 9.3. The current text: >> > >> > Allow the user to view a document outline >> > constructed from its structural elements >> > (e.g., from header and list elements). [Priority 2] >> > >> > I don't think this should be for dependent user agents only. >> > My question is this: does a view of the markup count? It is >> > not navigable, but it is searchable. I realize that this forces >> > users to read markup, which is not desirable. >> >> MN: Are we saying we'd like to allow the user to "view" a >> particular element, or set of elements in an outline form? For >> example, a list of headers, a list of forms, etc.. If so, I don't >> understand why a user would have to read the markup, or are >> you implying the UA would? >> >> Or are we saying we'd like to allow the user to "view" the >> entire document in an outline form, built using the structural >> elements of the document ( i think Amaya does this)? > >IJ: In my opinion, we're talking about the latter: A > generated table of contents (of sorts). Furthermore, the > outline should be navigable, which is not expressed in the >current wording. MN2: I guess if the later, more a table of contents (TOC), then i'd opt for adding "navigable" as well. >> >PROPOSAL 7) I propose that we move checkpoint 6.6 (operating system >> > conventions) to Guideline 7 and rename Guideline 7 as >> > "Support standard interfaces, conventions, and languages". >> >> MN: I'd rather see checkpoint 6.6 left alone and combine >> checkpoints 6.1 and 6.5, something to the effect of "use >> ???? technology which provides access to all the *information* >> in a timely manner." This needs work, but you get the idea. > >IJ: I don't object to this proposal. I'd like to hear from > developers. > >> I'd also propose moving checkpoint 6.4, which talks about complying >> with the W3C DOM model into Guideline 7, and then leave Guideline 7 >> as the catch-all for the W3C technologies, kind of like it is now. > >IJ: I guess it depends on which slice you're interested in. I'm more >interested in slicing along functional lines (communication >v. stand-alone) than W3C lines. MN2: As long as the points are covered, I'll leave the slicing up to the expert. MN2: no new comments from me beyond this point of this email >> >PROPOSAL 8) >[snip] > >> > I propose that >> > we allow two other types of conformance: >> > >> > a) Conformance as a stand-alone user agent: >> > You don't have to satisfy any checkpoints >> > in Guideline 6. >> > b) Conformance as an interoperable user agent. >> > You have to satisfy all the checkpoints >> > in Guideline 6. >> > >> > This split is natural - it is precisely about interoperability >> > and not other user agent functionalities. >> > >> > This proposal may seem to undermine the goal >> > of interoperability. I don't think it does. If a user >> > agent developer doesn't care about interoperability, >> > they won't satisfy these checkpoints anyway, even if the >> > the software highly accessible in other ways or to >> > targetted users. We are still saying >> > that interoperability is important and also "If you >> > want to ensure interoperability, you must do these things." >> > However, interoperability is not the only element of >> > accessibility. That's why there are other guidelines. >> >[snip] >> >> However, I think you make a very important point above, and if we really >> agree on this, I don't understand why we'd propose changing the >> UA guidelines from our current split of graphical desktop UA and >> dependent UA. As I read this..... >> >> ""If a user agent developer doesn't care about interoperability, >> they won't satisfy these checkpoints anyway, even if the >> the software highly accessible in other ways or to >> targetted users. "" >> >> ...is a decision the developer has made, and we should not change the >> guidelines, in the area of conformance for such decisions. > >> If I'm >> developing a product for a GUI that supports a keyboard and a >> mouse as the standard input devices, and I as the developer choose >> to not support one or the other standard input device, I've already >> choosen not to be interoperable. That in no way implies that I >> as a developer have a good or bad product, etc. , or that I don't >> care about accessibility, etc., I've made a development >> decision, based on whatever reasons that developer has. > >IJ: I'll respond to this in a separate email. > >> >OPEN ISSUE: There are two remaining checkpoints currently listed >> >as being for dependent UAs only: 9.8 and 9.9: access to cell headers >> >and table dimensions. Checkpoint 9.9 is Priority 3, and it might >> >be simplest just to make it apply to all user agents. Checkpoint >> >9.8 is priority 1. I haven't figured out yet how to modify these >> >checkpoints. >> > >> > - Ian >> >> MN: More reasons why I think the method we've used to date to >> develop the guidelines along the two classes has been the best >> way to create a set of guidelines applicable across the intended >> audience which sets obtainable goals for user agent and dependent >> user agent developers while also raising the bar for providing >> improved accessibility to web based information for users. >> >> glad to discuss anything I've missed/mis-understood further. > >Thanks for the comments Mark! > > - Ian > >-- >Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs >Tel/Fax: +1 212 684-1814 >Cell: +1 917 450-8783
Received on Tuesday, 28 September 1999 19:51:35 UTC