link to table version of issues list
Last updated on: Sun Apr 9 12:43:14 2000
In the introduction, the paragraph with "Furthermore, it is important to maintain consistency" gives the wrong impression. The words clearly and correctly state that functionality and usability are more important than consistency, but the order and amount of space given to consistency strongly conveys the opposite message.Proposed IJ: Adopt suggestion.
Great feature, but why is it limited to graphical controls? Is it not equally important to allow rearranging textual controls, such as menu titles and toolbar buttons with textual labels?CMN: Priority of text controls less important since designed for users with CD (but a good catch anyway). IJ: I would have assumed that text labels were included in this requirement since if they don't follow their controls, then that would be even more confusion. Also, I believe this is referring to all controls of a graphical user interface.
It seems strange to include this and not include a Pri 3 recommendation that the user be able to navigate in the outline, and ideally be able to use that method to navigate to the corresponding location in the non-outline view.IJ Proposed: That is covered by structured navigation requirement.
This seems like Pri 2 instead of Pri 1 to me, because it is not reasonable to require the user to be able to move captions to any arbitrary location. Most media players don't support moving the captions to arbitrary locations, and I see lack of this feature as making things difficult but not impossible.CMN: A problem arises under magnification, zooming for languages that do not have text flow (e.g., SVG).
If the author failed to provide alt text for graphical links, the user may not be able to use the page effectively unless the UA provides some information about the links, such as their link destinations.
Technically I think the priority of documenting a feature is the same as the priority of providing that feature. The Web Content guidelines use such linkages. For example, it should not be a Pri 1 requirement that you document Pri 3 features: the fact that the feature is only Pri 3 means the user does not really need it, and thus failing to document it won't make it "impossible" for users to access the Web.CMN Proposed: The WG intentionally did not choose a relative priority rating for this and other checkpoints related to Web content. In this case, knowing the featureis there is critical to being able to learn to use the tool.
I cannot justify this being priority 1, because although it certainly makes access easier and more convenient, the lack of it does not prevent use of the Web content.IJ Proposed: It is disorienting for users with CD, or who are blind or accessing information serially. I can see that it doesn't prevent access to content, however, it may make it near impossible for some users (e.g., with short-term memory problems) to locate where they were.
[This checkpoint] seems like it should be Pri 1 or 2 instead of Pri 3. That is because images can be extremely distracting for users with some cognitive disabilities, who may need to have them replaced by the text in order to be make the page useable. (It also seems a bit strange that letting the user turn off images is Pri 3 but letting users choose to see the alternative text is Pri 1.)IJ Proposed: The WG decided that background images were more distracting than other images. Hence two different checkpoints. CMN Proposed: This is just a special case of 2.5 since an image is an alternative to its text equivalent.
I would categorize this as Pri 2 rather than Pri 1. Blind users may need this information but that means making it available programmatically for use by their screen reader should be sufficient, and that is already covered in checkpoint 5.1 ("Provide programmatic read access to HTML"). If the UA provides its own UI to display this information directly to the user, that would only benefit blind users running "older" screen readers that fail to take advantage of technological innovations such as the DOM and MSAA. Also, any UI for this it probably won't be usable with the keyboard unless they allow navigation to non-active content, and that is not even a Pri 3 recommendation at this point.
"Follow operating system conventions and accessibility settings. In particular, follow conventions for user interface design, default keyboard configuration, product installation, and documentation." I'm all in favor of consistency when it is appropriate, but I cannot justify this being a Pri 2 requirement. I would find it acceptable if the UA provides equivalent functionality through other means, especially one that is more accessible than the system standard. For example, if a UA provides an entirely automated installation using a batch file, or a product for blind users provides a self-voicing installer, those might be more accessible than using the system installer and I would find them an acceptable and even laudable approach. I am hoping that the authors really meant ?Follow operating system conventions for accessibility? and did not mean to include every mainstream operating system convention. If so I would recommend clarifying the wording.CMN Proposed: There are accessibility conventions that amount to the software equivalent of an alternative page. For example, editing a batch script to run the installation. I agree with GL's proposal "Follow operating system conventions for accessibility" and consider this an editorial clarification.
"Ensure that the user can interact with all active elements in a device-independent manner," seems overly broad. What is the real goal? I doubt it is that everything, including text input, needs to be supported using the alone mouse. Does it also imply that if voice input is supported for dictation it also needs to be supported for command-and-control? Or is the real intent just "make sure every active element can be navigated to and manipulated using the keyboard," which is mostly redundant to other checkpoints.Proposed CMN: Implies that active elements, command and control, etc can be done through keyboard, voice (using an appropriate API), etc. A particular failing of most user agents here is to buy the HTML mouse-specific event model for creating active elements and not allow that to be done except with a mouse.
In some cases it is unclear when the UA must expose information directly to the user (by providing UI to show the information on the screen, etc.) and when the UA can simply expose the information programmatically (such as through the DOM). This should be clarified by stating that in all cases the information should be exposed to the user directly through the UI except where the wording explicitly says that the information may be exposed programmatically.IJ and CMN Proposed: Adopt suggestion.
"Document changes that affect accessibility between software releases."IJ Proposed: Agreed. However, it must be made clear that there are many changes that affect accessibility, including all of those features discussed in this document. The difficulty is how do the authors of the documentation realize what affects accessibility? (Proposed answer: Read WAI Guidelines).
[This] should not be a checkpoint, but moved to a technique for Ckpt 6.2 "use appropriate W3C recommendations".IJ Proposed: WG chose to make some checkpoints stand out due to importance and to label them as important special cases.
[S]hould be a priority 2 (not a priority 1) because selecting a larger size is covered in checkpoint 4.1IJ Proposed: Size is only one issue here. People may not be able to read a Gothic font. Question: Is this a general usability issue or an accessibility issue? The same goes for very small fonts: I may be able-bodied and still not be able to read the text.
[E]xplain that in-line prose should not be considered an equivalent alternative that the user could choose to not view. See the definition of "equivalent alternative" that is used in checkpoint 2.5IJ Proposed: Yes, this is a clarification. Refer also to issue 207 on checkpoint 2.1 - If the scope of 2.1 is reduced to alt equivalent, this needs to be made clear in general.
Change "... make available to other..." to "... ensure that the user has access to other ..." so that it matches the wording in checkpoint 2.1IJ: Editorial. Refer also to issue 207 (on checkpoint 2.1 scope).
Change "message (e.g., prompt, alert, etc.)" to "user-interface object (e.g., prompt, alert, button, etc.)"IJ Proposed: The WG expressly did not include the entire user interface (covered by checkpoint 5.9, a P2). However, if adopted use the term "component".
Not imperative but to demonstrate this guideline's broad applicability you may want to add power users to the laundry list.IJ Proposed: Adopt suggestion.
"... if a functionality is available from a menu, the letter of the key that will activate that functionality is underlined..." I assume you are talking about mnemonics. With them the underlining only occurs within the menu or in the area you are directly interacting with (e.g. a dialog box) and they must be explicitly set by the developer. The wording makes it seem like the underlining occurs someplace other than where the command or setting is actually set by the user plus it reads like the setting of them happens automatically. I recommend rewording of the example.IJ Proposed: For example, on some operating systems, when developers specify which command sequences will activate which functionalities, standard user interface components display those bindings to the user. For example, if a functionality is available from a menu, the letter of the activating key is underlined.
"Allow the user to configure the user agent so that the user's preferred one-step operations may be activated with a single input command" This will be problematic in a text area or region because it will consume the single keystroke if the command is invoked by an alpha-numeric key press. Perhaps the following should be tacked onto the end "... single input command when the focus is outside a text input region (..."IJ Proposed: Add a Note that in text entry mode, this functionality is not expected.
I assume "mobility access keyboard modifiers" means AccessPak, AccessX, EasyAccess (can't check techniques to verify, the site keeps killing my browser). If so, perhaps a definition of "mobility access keyboard modifiers" should be in the glossary. Does this also cover things like the use of I/O ports? Shouldn't it also cover mnemonics, accelerators (aka AccessKey I believe), and in general the platform UI's keyboard navigation sequences?
In opening description - "User agents must ensure that notifications are available in an output device independent manner." How about adding "... thru a standard programmatic interface." after manner? See Checkpoint 5.7 discussion for why.IJ Proposed: Add cross-ref to 5.7, which should include note about how the checkpoints for APIs apply to other checkpoints.
"Make available to the user the author-specified purpose of each table ..." Does HTML support this? [Does the techniques document] say how to support this? Is it a bunch of D description links?IJ PRoposed: Add CAPTION and summary as examples. Note also that this is a special case of both 2.1 and 6.2. IJ Proposed: Add explanation in section 1.3 of document that some checkpoints are important special cases of one another or of several different checkpoints. They are included to make the requirement explicit.
In the opening description - "Proportional scroll bars on graphical ..." Whatever is mentioned in the opening description should have at least one associated checkpoint under it, this one doesn't. The other bullets do however. This should have one, be removed, or be moved (with a checkpoint or 2) to Guideline 5.IJ Proposed: This is part of checkpoint 9.4 and the requirement should be moved to G9.
"Allow the user to navigate according to structure." Does structure just mean text or can it be more? This should be clarified. Should the definition of structure be added to the glossary?IJ Proposed: Identify structure as document object (to be defined in a separate proposal). Note that it could also be interesting to navigate by semantics, but this would have to be addressed elsewhere (e.g., metadata that provides a navigation order or links documents).
It's confusing to me that assistive technologies (AT) are considered UAs in the context of this document. [Guideline 7] adds to my confusion. AT of the type highlighted in this document does not act by itself in "displaying" web content but instead, as noted in the doc, works with other UAs. AT can and do for product distinguisher reasons provide some of their own navigating mechanisms, as screen readers and magnifiers do, but they don't provide all that the user needs (they only do some of what is highlighted in this guideline). Instead they mostly tap into and take advantage of functionality provided by the platform's UI toolkit and custom components used in the UA the AT is interacting with. By placing AT in the UA category in this document, does that mean the AT and UA developers should both be supplying the same navigation methods? If no, where should the line be drawn and what checkpoints need to be added to make that clear for developers? I ask because while it may be appropriate for something like the HPR to be put under the scrutiny of these guidelines, ATs of the type highlighted in these guidelines shouldn't have to be - they're interacting with the information and functionality that came to the UA they are paired with. I agree in the broader sense that an AT is a user agent but for this document I don't think they should be clumped together. Or AT, for this document, should be defined as HPR, Opera, or some other technology that is specifically focused on web content.IJ Proposed: We may need to make clearer that this document's requirements are not intended for "dependent" UAs (though they could try to conform if they wished) To do this: - Clarify how UAs in general and ATs are meant to interact. - Refer to dfn of UA in UA responsibilities. http://www.w3.org/WAI/UA/2000/03/ua-resp-20000308
I started down a comment path thinking this guideline was meant to cover W3C -and- non-W3C specs (e.g. Java and Java Accessibility). It finally occurred to me that this was meant to cover only W3C specs.... [H]ow about something like "Implement W3C's accessible specifications." If this whole guideline is meant to cover all specs for technology that might be used in the content of a web page then perhaps a specific set of statements should be made in the opening guideline description or a guideline added that says something like "If you don't use a W3C technology/spec then make sure it can support accessible design." This would mean, I'd imagine, providing Plugin support and suggesting the technology/spec developers make accessible content development and display possible in their technology thru a standard interface somehow.IJ PRoposed: Adopt suggestion.
Does default keyboard configuration mean look at style guide recommended key sequences for accelerators and things, Qwerty vs Dvorak vs ?, both, or more? It should be clearer.
What are some examples of accessibility settings? Some should be highlighted under this checkpoint in this doc, not just in techniques.IJ Proposed: Add examples.
Add "thru a standard (or centralized?) programmatic interface" after "...interface controls..."? I suggest this because putting this information in a central location, as an accessibility API does, makes it easy for the assistive technology vendor to find and support access to this in their product. It also generally means that the way the notification is exposed won't change between dot releases of the UA or platform it runs on (i.e. the accessibility API won't change)IJ Proposed: This is covered by checkpoint 5.5. Propose to add a note to guideline 5 that explains (as is done in 1.1) that these checkpoints apply to each other, and to any API described in the document.
Because an accessibility API is so powerful how about adding it to this example with a "where available" caveat?IJ Proposed: Instead, change "ensure that assistive technologies have access" to "provide access to". Don't add "where available since covered by applicability. (Or add cross-ref).
The "content" portion of the UA is part of the "user interface" (the 2 section names used to separate the guidelines into logical areas). It might be good to change "user interface" to "chrome" (with an accompanying definition defining what chrome means - it's everything that doesn't display page author generated content) unless "user interface" truly does also include "content" related checkpoints. If the later is the case, perhaps a third section name should be added called "mixed" or something which is meant to denote that the checkpoints apply to both the "content" portion and "chrome." The "content accessibility" title isn't quite right either. It reads like something more appropriate in the Web Content Accessibility Guidelines. Since this really, I believe, applies to the content parser how about changing "content accessibility" to "content parser accessibility" or "content view generator accessibility" or something?IJ Proposed: - This is part of review of definition of "content" (raised as part of issue 207) - Editorial clarification required, notably for G5.
Is the UA responsible for firing off an event that can be picked of by an assistive technology saying this has occurred? It should but I'm not sure if this is stipulated elsewhere in the guidelines.IJ Proposed: Yes, this is covered by by 9.3 (notification of events). Proposed to add cross-ref
Does this mean allow the user to configure it so it can open with or without focus, minimized, ...?IJ Proposed: WG should identify minimal requirement.
Does this include or mean how focus indication looks in keyboard navigation (e.g. the focus indicator or box on a link or active zone of an image map can be fat, skinny, dotted, ... and/or what the input cursor looks like in a form field)?IJ Proposed: No it doesn't. "How it looks" is covered by 4.13 (focus highlight). We could add a cross-ref.
The added twist is that the platform might provide it's own speech synthesizer (and controls for it) plus the user can also plug in and control their own hardware based speech synthesizer.IJ Proposed: If the UA is using the OS features, then it's the UA's responsibility that the OS features are accessible. If the user is using a different synthesizer (and assistive technology), it's not the UA's responsibility.
What if the UA is only meant to run on platforms which have there own facilities for volume control? For example, Solaris, Windows, and Mac provide platform level audio controls. Does the UA need to provide redundant controls that perform the same function or can the UA punt the need in situations where redundancy is known (i.e. the platform has audio controls already)? The answer should be made clear.IJ Proposed: No. The UA can use what the OS provides (we say this already). Therefore, just add clarifying note.
This may not be an issue given how multimedia such as video and perhaps animation inherently work but synchronization of multiple tracks is important. For this checkpoint it doesn't say that when one multimedia channel slows (e.g. the visual track of video) the other channel should slow at the same rate. Should it say all channels need to stay synchronized? Should the user be able to slow or speed one track while letting others stay at normal rates? It's not clear.IJ Proposed: Yes, they must. This is covered by a piece of 2.6 and also by 6.2 if it involves respecting sync cues.
This first sentence should be under Checkpoint 4.2 and/or maybe "font family and style" should be changed to "font size."IJ Proposed: make suggested editorial fix
Color is mentioned in the last sentence, first paragraph of the opening text but not in "Ensure that the user..." or in any other checkpoint under this guideline. Mention of it should be removed and covered in Guideline 4 maybe or a checkpoint or 2 should be added. What color is it referring to anyway, text, background, ...?IJ Proposed: Either make the suggested change, or argue that for background images, color contrast may be problematic, hence one reason turning off is a requirement.
beatnik.com provides technology that gives various audible tones when you mouse over content objects. For example, a button might be a bark, a form field be a sigh, etc. Is this an equivalent alternative? If so I think the equivalent alternatives description link needs to be enhanced so it covers how to deal with locational information presented in a narrow modality grouping (e.g. mouse and tonal). If no, what covers this? Checkpoint 1.5?IJ Proposed: Do not change dfn of equivalent alternative. Not sure what "locational information" means...
"...announce the event in text on the status bar as well..." Does it have to be on the status bar? What if the UA's "status bar" is a whirly hourglass or bar status indicator only that purposely doesn't provide text for screen space reasons? Perhaps the suggestion should be genericized to provide visual feedback when a sound based event occurs and the specific mention of the status bar be moved to Techniques.IJ Proposed: Ensure that wording states that info on status bar is one possible technique.
"...through a graphical button, ensure that the user interface also provides access to the same functionality through a control that includes a text equivalent..." The graphical button itself should include a text equivalent whenever possible, this doesn't say that. This is bad wording but how about something like "...through a graphical button, ensure that it includes a text equivalent (e.g. tooltip) or that the user interface provides the same functionality with a text equivalent elsewhere..."IJ Proposed: Adopt suggestion
Client-side is a specific solution, the rest of the example is a little more general. I suggest moving the specific mention of client-side to techniques and rewording to "...links in a image map, and form..." because a better solution than client-side could come along tomorrow.IJ Proposed: - Make suggested change
"Note. This document addresses accessible user agent support for some language features (e.g., tables for..." Add Markup in front of language? Not sure what language(s) you mean (e.g. HTML, XML, German, Java, ...). It would be good to see "Follow operating system standards and conventions and use open specifications" mention platform specific UI styleguides because that is where guidance on platform look and feel, "reserved" accelerators, mnemonics, etc. are mentioned and discussed. It would also be nice to see specific verbiage on how important it is to look at, and factor into the design of the UA, the guidance each platform's guidelines provides (i.e. you don't want Alt+E doing one thing inside the UA on platform A and it doing something else outside the UA on platform B).IJ Proposed: Adopt suggestions - In note, say "markup language" - To section 1.2 intro about OS standards, mention platform specific UI styleguides.
The Guidelines do not appear to address the full range of UAs that are coming on the market. It may be possible to infer how these new devices should work with web content but it would be better if this could be spelt out as a major part of the guidelines when they are first released.Proposed: - No change - Add to FAQ - Ensure that this is covered in new charter
Furthermore, we should consider adding a checkpoint abstracted from Todd's techniques to the effect that there should be one control in the UI which accomplishes a general increase or decrease of the font sizes throughout the document, while preserving size ordering of different text fragments to the maximum extent with user directives.
IJ: Ideas for next draft.
These are three options I am aware of for markup related to navigation bars or in general grouping of links. Please respond with your own ideas or comments. FOllowing the options is a list of some of the archived e-mail discussion on the issue.
Option 1:
Using the DIV element and some type of CLASS or NAME identifier:
PROs: Easy to implement and author
CONs: There is no mechanism to reserve class names in HTML, there could be
conflicts if specific class names are usedOption
2:MAP element
PROs: Currently used for image based navigational barsCONs:
1. More complex than DIV to author
2. What if authors did not want to use images in their navigation bars
Option 3: Schema
Schemas are a potential way to indicate the purpose of content or structure
PROs: Proclaimed as the right method for the job
CONs:
1. New technology and still under development
2. Not currently supported by UAs,
3. Not clear how easy to author
4. Not clear how easy for AT to decode and use information
Option 4: MENU element
CON: Depricated HTML element
Discussed 7 July
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0003.html
