- From: Ian Jacobs <ij@w3.org>
- Date: Sat, 04 Dec 1999 18:07:17 -0500
- To: Richard Premack <richardp@akamail.com>
- CC: jbrewer@w3.org, w3c-wai-ua@w3.org
Richard Premack wrote: > Last Call review of User Agent Accessibility Guidelines 1.0 > W3C Working Draft-November-1999 > > Prepared by: > Richard Premack, interNext > richardp@inter-next.net > 1-888-576-8932 (USA) 1-727-578-1059 (Int'l) > > The following is our response (attached in both Microsoft Word and HTML > formats) to an invitation by Jon Gunderson, Chair -- W3C WAI User Agent > Working Group to review and provide comment on the " User Agent > Accessibility Guidelines 1.0 - W3C Working Draft-November-1999". Thank you for the comments, Richard. I will add issues that you raise to our issues list [1]. My comments are below. For your comments that are purely editorial, I will make the appropriate corrections. Thank you, - Ian [1] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html > 2.1 Legal Considerations > [snip] > > In any event, I think it would be advisable to have the draft document > reviewed by W3C legal counsel or an attorney well-versed in web content > copyright law to determine if there might in fact be a conflict between > providing accessible functionality in user-agents and the rights of web > content authors. These comments are very interesting and I will take them to the W3C Team for discussion. Though I am not a lawyer, I would split the issue into two: 1) Rendering changes The HTML specification describes in very few places how content should be rendered. Therefore, anyone who writes a Web page in HTML and expects it to be rendered in a specific way is using the wrong language for designing their page. The fact that HTML says so little is one reason why browsers differ in behavior today. If we extend the discussion to style sheets, user override of style is built into the CSS specification (CSS2 reinforces the override by ensuring that users can have final say). Therefore, anyone using CSS who expects to have final control over styles is using the wrong language for style. In short, I don't know how one would defend an argument that user agents MUST render content in a particular manner. 2) Content changes It is possible for users to add content to Web pages (through transformations, style sheets, and other mechanisms). If I make these transformations for my personal use but do not republish them, do I infringe the author's copyright? Is it illegal to tear pages out of a book because it has been bound too tightly and I can't read the inside margin of the pages? I look forward to interesting discussion on this topic. > 3.0 Specific Comments > > The abstract, in an effort to define/distinguish between "user-agents" and > "assistive technologies" cites several examples in each category. However, > the glossary definition seems to imply that both components are > (necessarily?) part of the user-agent. This may be a nit to some, but the two > sections do seem a little inconsistent with each other. Eric Hansen has pointed this out as well ([2], Issue #1) and the definitions will be cleaned up in future drafts. [2] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0338.html > [Checkpoint 1.3] > > Be careful that when converting/rendering one content object as another the > object's original characteristics are maintained. I'm not sure what your comment refers to. Checkpoint 1.3 in the last call draft [3] reads: "Ensure that the user can interact with all active elements in a device-independent manner." [3] http://www.w3.org/TR/1999/WD-WAI-USERAGENT-19991105/ > [Checkpoint 2.8] > > What about so-called "proximal text" that may be used to describe a link > when no ALT text is available? This is text that occurs immediately after or > before the HREF tag. In this case of either unspecified ALT text or specified > null ALT text we would use proximal text to describe the link if available. Checkpoint 2.8 reads: When alternative text has been specified explicitly as empty (i.e., an empty string), render nothing. Authors should be able to specify empty alt text when they mean, for example, "this image is purely decorative and has no function in the page." Thus, we ask UAs to not attempt to guess what the function of the image is since the author has (we hope) meant "no function" by specifying empty alt text. Our current techniques for checkpoint 2.7 (missing Alt text) refer to the "altifier" tool heuristics [4]. Your suggestions could be added as another technique. [4] http://www.vorburger.ch/projects/alt/ > [Checkpoint 2.9] > > The changing from a supported natural language to an unsupported language > could be very disorienting to a user and therefore the user "should" (Priority > 1) be notified. Are you suggesting that the priority of checkpoint 2.9 be raised to Priority 1? > [Checkpoints 3.5 & 3.6] > > As mentioned previously, inhibiting blinking or animated text (or images) as > suggested in this checkpoint could have the effect of inhibiting a copyright > notice, or more commonly, a paid advertising "banner". Ignorance of the copyright statement doesn't mean that it doesn't apply. Important information on the screen might just as easily be obscured by the placement of my windows. > [Checkpoint 3.8] > > The ability to turn on and off [foreground] images "should" (Priority 1) be > provided and is at least as important as checkpoint 3.1. The Working Group elected to reduce the priority of turning off (static) image rendering because rendering images did not raise barriers to accessibility. Background images may make text impossible to read and thus the WG made checkpoint 3.1 a priority 1 checkpoint. Do you have significant arguments for raising the priority level of checkpoint 3.1? Please refer to the 12 October WG face-to-face minutes [5] for information about this resolution. The checkpoint number in the document under review at that meeting was 4.1. [5] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0105.html > [Checkpoint 4.1] > > While Checkpoints 4.2 - 4.4 address important controls for site impaired > (low-vision) users, it is unclear to me that font family plays a Priority 1 role in > ensuring readability. I would recommend Priority 2, although I understand the > tendency to want to group font type and size together. I'll add this as issue 158 > [Checkpoint 4.13] > > Normal audio playback controls are important and should have the same > priority (Priority 1) as playback controls on Text-To-Speech (checkpoints > 4.14 & 4.15). Certainly these controls would be considered more important > than say, changing the gender of Text-To-Speech output. Added as issue 159 http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#159 > [Checkpoint 5.1] > > This checkpoint is much too vague to be useful to a developer without further > elaboration. What are "accessible APIs" as opposed to standard APIs? Which > "other technologies" are being referenced? This checkpoint deserves a more > complete explanation in view of the fact that it is fundamental to other > checkpoints involving APIs and carries a Priority 1 rank. This checkpoint is already on our issues list as issue 125 http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#125 > [Checkpoints 5.4 & 5.5] > > The more I read checkpoints 5.4 and 5.5 the less difference I can discern > between them. You should stop reading them. That helped me. <wink> > If Checkpoint 5.5 was embellished slightly to clarify that > Checkpoint 5.5 is a superset of Checkpoint 5.4, this would improve the clarity > of both checkpoints. Good idea. That's how we handle other checkpoints that are important special cases. However, I think 5.4 is more a special case of 5.3 than 5.5 (which is more about change than read/write access). > [Checkpoints 6.1 & 6.2] > > Again, the distinction between these two checkpoints, besides their priority, > is barely discernable from the description. Both call for implementation of > applicable accessibility features except that one enumerates the > specifications. 6.1 is specifically about accessibility features. 6.2 is about conformance to specification; all features in addition to accessibility features. I agree that 6.1 is a special case of 6.2 for W3C specifications. However, 6.1 is not limited to W3C specifications (it would include, for example, Java, in my opinion). > [Guideline 7. Provide navigation mechanisms] > > "So that users of serial devices are not required to view an entire page or > presentation to find information, user agents should provide more direct > navigation mechanisms" > > The statement above has definite legal implications that should be apparent > from the previous discussion of copyright law. It is important to remember that > when viewing a page visually, almost all of the information is presented to the > user instantaneously through their eyes. In this case, the use of direct > navigation mechanisms does not prevent the user from processing the other > information contained within the page since that information has already been > viewed. I don't think that's true. If I enter a long page (that requires scrolling to view the entire contents) but I leave the page via a link at the top of the page, there is no guarantee that I have viewed anything below the first screen (nor that I have viewed a piece of content in the first screen that I may have missed, or understood if written in a language I don't understand, etc.) > In contrast, direct navigation features on a page presented serially, > such as through Text-To-Speech conversion may cause entire sections of > content to be missed and "context may be lost". I think the Web is mostly about direct access through links and therefore, there are few guarantees of sequential access to information. The traditional narrative structure is lost (or rather augemented) in the hypertext model. > [Checkpoint 7.5] > > Navigating just among active elements seems at least as important as > navigating through the elements of a table (Checkpoint 7.3). Checkpoint 7.3 is already up for discussion. Refer to issue 160 http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#160 > [Checkpoint 8.8] > > This checkpoint appears to be a fundamental mechanism and deserving of at > least a Priority 2 ranking. Added as issue 161 http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#161 > [Checkpoint 8.9] > > Software re-usability and backwards compatibility are important features to > provide and "should" be > provided. Added as issue 162. http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#162. > [Missing Checkpoint 10.X ?] > > It seems there should be a checkpoint in this section describing a feature > similar to the "Favorites" folder implemented in some browsers whereby > previously visited links may be stored, named, categorized and retrieved with > a single keystroke or a single voice command. I think that a "Favorites" functionality is useful (like a Back/Forward functionality) but is probably a technique for another checkpoint related to navigation. Added as issue 163 http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#163
Received on Saturday, 4 December 1999 18:07:40 UTC