- From: Earl Johnson <Earl.Johnson@eng.sun.com>
- Date: Thu, 2 Dec 1999 17:22:39 -0800 (PST)
- To: ij@w3.org
- Cc: w3c-wai-ua@w3.org
Hi Ian, I wish I could have turned this around as fast as you did. Below are responses to some of your comments and questions posed on my first review. Comments start on lines beginning with EJ and are done once the > symbols start showing up again. Thanks, Earl ========= > > > Adding the forgotten words... > > > > C. The guidelines and checkpoints in the document should stand alone so > > the reader has a pretty good idea of what they mean without having > > to rely on the Techniques document to explain what is meant. > > Yes, I agree. Please indicate specific problems you found. EJ The ones I found were addressed in the review. I'll suggest clarifications where you haven't already made them. > > > Translating what was said originally into English... > > > > D. Sometimes the same basic checkpoint is found in more than one guideline. > > For example, checkpoints 1.3 and 10.3 seem like they could just as > > easily be merged into a single checkpoint under guideline #1 or #10. > > Some checkpoints are specializations of others, so 1.3 is a special case > of 1.1 (this is noted in the text). > > Checkpoint 1.3 is about device-independent activation of active > elements. > Checkpoint 10.3 is about user control of keyboard, voice, and other > input configurations. I don't see how they would be merged. EJ Sounds like an interesting exercise. I'm interested in exploring possibilities that might jump out after getting what's proposed below. > ONE GENERAL COMMENT ON YOUR COMMENTS: > > You apparently have an entirely different model for organizing > the checkpoints in mind. It would be useful to me if you > were to repropose each Guideline based on the model you have > in mind. In short, how would your table of contents for the > Guidelines look read? > EJ There may be some guideline wordsmithing but I don't imagine much in today's TOC will change with my suggestions. If there are changes it would be in the checkpoints. The basic structure I had in mind for making things clearer to developers was similar to what is used in guideline #4. Using the work you've done breaking up guideline #5 below hopefully conveys the basic idea that all the guidelines would present. Guideline 5. Sub-guideline Important for Content Display accessibility 5.6 Important for UI accessibility 5.2 5.3 5.4 5.8 Important for Content Display and UI accessibility 5.1 5.5 5.7 > > Section 2 - UA Guidelines > > > > Guideline #1 > > > > Checkpoint 1.1 - The second sentence should be removed because it feels > > like a design decision. It's a good point though so move it to the note > > or Techniques document. > > The second sentence: > > <QUOTE> > User agents are not required to reimplement low-level > functionalities (e.g., for character input or pointer motion) > that are inherently bound to a particular API and most > naturally accomplished with that API. > </QUOTE> > > Has been included to address the concern expressed by some that > people might think checkpoint 1.1 means that users have to be > able to enter text with the mouse. If we move the sentence to > an informative note or the techniques document, the "requirement" > is lost. So it has been included directly in the checkpoint as > a clarification. If it's not clarifying anything, we may need > to change the wording. > EJ Ok. How about something like "Ensure that the user agent supports all input device APIs support on the platforms it is designed to work on." > > > Guideline #2 > > > > A. In the description paragraphs, are there formats from other areas that > > should be called out? SMIL is mentioned, is there anything from TV > > or other areas? I'm just wondering because th UA enables all sorts > > of technology convergence. > > SMIL and HTML are listed as examples, and while I wouldn't want the > rationale section to grow too much, nothing prevents us from including > references to other technologies. It would be even more appropriate > to do so in the Techniques Document, but we have not had the resources > to address more than SMIL, CSS, and HTML for now. SVG and XML should > be included soon. > > We are always welcoming text for the Techniques document, so if you > have proposals, don't hesitate to send them. > EJ I defer to any input Larry Goldberg and others can provide on the convergence technology standards part. > > > Checkpoint 2.3 - I think of speech recognition when I see the term > > natural language. Is that what is meant here? If no, perhaps a better > > description can be provided so the reader doesn't need to leave the > > guidelines to verify what natural language means in the checkpoint. > > The term "natural language" is defined in the glossary of the > Guidelines, EJ That should be sufficient. I missed the link to the glossary entry, sorry > > Checkpoint 2.7 - What if the object isn't video or audio? Is this > > checkpoint just for timed media or does it cover things like graphics > > or interactive objects that say nothing about themselves? > > The checkpoint reads: "When no text equivalent has been supplied, > indicate what type of object is present." > > This applies to any object for which an alternative equivalent > has not been provided. EJ What if the object isn't recognized by the UA? As an example, browsers that don't recognize Java applets can only tell the user it's an applet they aren't viewing if the author identifies it as an applet in the tag (appologies if this is no longer a relevant example but hopefully you get the drift). I can think of no alternate wording to propose but do feel the checkpoint should be worded so it makes a nod to this reality. > > > Guideline #3 > > > > A. A number of the checkpoints mention rendering. Should they be under > > Guideline #10 since it's sub-guideline calls out rendering or should > > rendering be moved from #10 to this guideline? > > Meta-comment: It is true that some checkpoints might appear logically > in more than one location. We've tried to group tightly related > checkpoints > even though one or more might appear in other Guidelines and still make > sense. > EJ I rose this general flag because it looked like some reduction in the number of checkpoints was possible. It also looked like some re-categorizing of checkpoints into different guidelines was possible too. Then again neither may be possible. I think you are in the best position to making this assessment given how close you two are to these guidelines. > > Guideline #4 > > > > A. Mentioning speech rate and pitch suggests to me the UA is the one > > providing the audio service. > > 1. Does this aspect of the guideline still hold true if the platform > > the UA is running on provides the service? > > If the UA makes use of services provided by the operating system, that's > great! > > > 2. Isn't it the audio service that should provide the control? > > If the audio services is not "native" to the User Agent, then yes. > > > 3. Does this mean the UA will need to provide a controller UI for > > all the audio services the user might have (e.g. different TTS > > devices)? > > I'm afraid I don't understand the question. EJ My confusion in speech's mention is what is a developer supposed to do in the way of enabling control when their UA is meant to rely on the platform's speech not provide it itself? I think the only resources that should be mentioned in the sub-guideline are only those a UA will always be providing (e.g. color for a GUI UA). Since speech and the others are just examples how about just removing them or moving them to the descriptive text? > Guideline #4 isn't about the user interface in general; it's about > control of the user interface. Your suggested checkpoint would be > better under #5. > > > B. As noted in the Techniques document Java Accessibility API and MSAA > > are public APIs. They enable the designer to easily make the feature > > control aspects of the UA's UI accessible and can be extended to > > cover many accessibility aspects of the content display. For > > example, JAAPI directly supports not only buttons and comboboxes but > > editable text also. But unlike DOM, SMIL, and other W3C specs they > > aren't mentioned in the main guidelines. Since they are relevant, > > why aren't the JAAPI and MSAA standards specifically mentioned as > > examples in this document also? > > My personal take is: the guidelines should remain vendor/platform > neutral where possible. MSAA and JAAPI are implementations of the > checkpoints and as such appear in the Techniques document. DOM is > required explicitly, so is mentioned in the Guidelines. It is true > that HTML, SMIL, and other markup languages are not required in > the Guidelines document; they are examples only. There are checkpoints > for style sheets explicitly, so CSS and XSL could appear in the > Guidelines. > > This merits some discussion. Refer to issue 124 > http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#124 > EJ If nuetrality is the goal then why shouldn't the guidelines also be organizationally nuetral? You have a bully pulpet here in that you are telling all developers only W3C standards are acceptable for content and that everything else can use someone else's API or no as long as the base functionality defined in the guidelines is met. This example seems far fetched but what happens if someone comes up with a better than W3C standard that the industry widely adopts, competes directly with one of the W3C standards mentioned in the guidelines, and will never be submited as a W3C standard? If the answer is put it in the Techniques document then shouldn't the answer, for fairness reasons, be the same for the W3C standards? > > Checkpoint 5.7 - > <snip> > > > 1. General related document comment: the guidelines contain both > > specific and general guidelines all mixed together. > > Do you mean general checkpoints or guidelines? Assuming you mean > checkpoints, the answer is: yes, there is a mix. First of all, > I don't know what it would mean (or how one would know) that all > the checkpoints have the same level of precision/generality. > EJ Whoops, I meant checkpoints. > > Guideline #6 > > > > A. Guidelines #5 & #6 without the checkpoints say the same thing to me. > > Current text: > > Guideline 5. Observe operating system conventions and standard > interfaces > > Guideline 6. Implement open specifications and their accessibility > features > > > But as I read the descriptions and checkpoints associated with each > > guideline #5 seems to be oriented towards the feature control aspect > > of the UA UI and #6 seems to be content display oriented. > > Guideline 5 contains some information about content and some > information about UI: > > Content: 5.6 > UI: 5.2, 5.3, 5.4, 5.8 > Both: 5.1, 5.5, 5.7 > > > > 1. The wording of the 2 guidelines should be worked on so it's clear > > what they cover without the need of looking at the checkpoints to > > ascertain what they're covering. > > Please suggest wording that would clarify the distinction. > EJ One possible way is Guideline 6. "Implement open specifications and their accessibility features in the content display (parser?)" This way guideline 5 could stay as it now is. And if a structure something like what is suggested in the above "GENERAL COMMENT ON YOUR COMMENTS" response to you is used, you wouldn't need to move the checkpoints around like you've done below unless it still made sense. > > > > 2. If my impressions of #5 & #6 are right then #6 should only contain > > content oriented checkpoints and #5 should only contain feature > > control oriented checkpoints. > > We could move checkpoints around to match that expectation: > > 1) Move checkpoint 5.6 (DOM) to G6. > 2) Move checkpoint 5.5 (promgrammatic notification) to G9 on > notification > (will that be consistent with other checkpoints in G9? to be > verified...) > 3) Checkpoint 5.1 needs clarification anyway. > 4) Checkpoint 5.7 (timely notification) refers to "information", which > may be about content or controls. That could stay in G5 and, having > moved 5.6 to G6, we could refer to it from the DOM checkpoint. > > That would leave all G5 checkpoints about the UI. > > Thoughts? > EJ Nice reorganizing, see above response tho. > > Guideline #7 > > <SNIP> > > > 3. The Note covers search, navigation, and location of input focus. > > The input focus shouldn't be mentioned here since it's covered in > > guideline #8 or the connection between input focus and > > search/navigation should be made clearer in the Note or > > descriptive paragraphs. > > I'm not sure which Note you're talking about. Please clarify. > Here's it is: Note. For all search and navigation functions, the user agent should follow operating system conventions for using selection and focus mechanisms. For instance, the selection should be used to identify the results of a text search, the focus should identify active elements during sequential navigation of active elements, etc. > > > > Guideline #8 > > > > A. Regarding the sub-guideline: "Provide information about resource > > structure, viewport structure, element summaries, etc. that will > > assist the user understand their browsing context." > > 1. The wording as I read it says it's aimed at the content author not > > UA. How about the following as a possible clarification > > alternative: "Enable user to get at content meta data to assist > > in understanding of browsing context (e.g. resource structure, > > viewport structure, element summaries, etc.)" > > > > It's more than just giving access to author-supplied metadata. User > agents can actually generate useful information (such as a structured > view). Some of the checkpoints in this section refer explicitly to > "author-supplied" information where that is meant. > > Perhaps we need an extra statement saying that information may > be author-supplied or generated (usually based on content, nonetheless) > by the user agent. > EJ I don't know if this captures the main point of the sub-guideline but how about something like "Provide information that allows the user to know where they are in the UA and what the structure of the content is to assist the user in understanding their browsing context."? Then use the descriptive pragraph to add verbiage on things like resource structure and viewport structure that should be specifically mentioned. As it now stands the only place resource structure and viewport structure are mentioned, whose meaning I don't think is obvious, is in the sub-guideline. > > > > Guideline #9 > > > > Checkpoint 9.1 - > > Current text: "Provide information about user agent-initiated > content and viewport changes directly to the user and through APIs." > > > The "to the user and through APIs" part isn't clear. > > This isn't right either (because not all UAs will have a visual > > display) but "visually and programmatically" seems closer to the point > > it appears to me the checkpoint making. > > It's not only visually. It can be through audio cues. > EJ Since the example caused confusion, perhaps I should have said something that encompases the presentation aspect more generally. How about "...through the UA's primary mode of presentation and through externally available APIs." instead? Externally here means it's a a part of the UA however it's a public (provided by the UA and available to developers) not private interface. Of course then the question is, since API I assume means an accessibility API, what happens if the developer decides to use the older fashion of suporting access - use a standard toolkit that provides no but makes it possible for AT to get at what they need (at least in that rev) - to support? It's for this reason I originally suggested saying programmatic instead of API. What does API mean if API is broader than accessibility API? > > 1. I'm confused about the user part because the user gets the > > information regardless of how the information is made available. > > How does the user get the information regardless? > EJ Either thru the UA's primary presentation mode or thru the API their assistive technology taps into. > > 2. Specifically stating API sounds like the document is prescribing > > what is necessary to successfully acheive this checkpoint. As > > nice as it would be to do this, I don't think that's the > > intention of the document. Stating programmatic allows the > > developer to choose whether or not an API is the way tthey'll > > achieve this checkpoint. > > What other programmatic means are there? Are we always talking > about APIs when we refer to communication with Assistive Technologies? EJ No. It's only recently that there have even been accessibility APIs. Before that, assistive technology vendors had to wade thru the individual components to find out which calls to make to them to get the information they needed. > > > Checkpoint 10.4 - > > Current text: "Use operating system conventions to indicate the input > configuration." > > > What's this checkpoint saying? It's descriptive > > paragraph doesn't add enough clariuty for me. The example is mnemonics > > oriented but what should happen if, for example, speech input is used? > > The checkpoint says use OS conventions. What are the conventions > for speech input? If there aren't any, then the UA doesn't have to > do anything (it would seem). > EJ Never mind, I missed the glossary entry. I understand now.
Received on Thursday, 2 December 1999 20:23:38 UTC