Issues Tracking Table for User Agent Accessibility Guidelines 1.0

updated: January 11, 2007

Issues List

Priority 1 checkpoints

Checkpoints Provisions In/Exclusions Issues/Gaps
1.3 Provide text messages (P1)

(Techniques for 1.3)
1. Ensure that every message (e.g., prompt, alert, or notification) that is a non-text element and is part of the user agent user interface has a text equivalent.

inclusions and exclusions

  1. Provision one of this checkpoint applies to handlers of any input device event type, including event types for keyboard, pointing device, and voice input.
  2. The user agent is not required to allow activation of event handlers associated with a given device (e.g., the pointing device) in any order other than what the device itself allows (e.g., a mouse down event followed by a mouse drag event followed by a mouse up event).
  3. The requirements for this checkpoint refer to any explicitly associated input device event handlers associated with an element, independent of the input modalities for which the user agent conforms. For example, suppose that an element has an explicitly associated handler for pointing device events. Even when the user agent only conforms for keyboard input (and does not conform for the pointing device, for example), this checkpoint requires the user agent to allow the user to activate that handler with the keyboard.
  4. This checkpoint is mutually exclusive of checkpoint 1.1 since the current checkpoint may be excluded from a conformance profile, unlike other keyboard operation requirements.
  5. Conformance profile labels: Events
http://www.w3.org/2006/06/15-ua-minutes.html
  1. allowing non-essential (IF IDENTIFIED) alerts and text messages to be optional (turned off by the user if desired).
  2. AJAX implications as things change on-screen without a refresh
2.1 Render content according to specification (P1)

(Techniques for 2.1)
1. Render content according to format specification (e.g., for a markup language or style sheet language).

inclusions and exclusions

  1. Rendering requirements include format-defined interactions between author preferences and user preferences/capabilities (e.g., when to render the alt attribute in HTML, the rendering order of nested OBJECT elements in HTML, test attributes in SMIL, and the cascade in CSS2).
  2. When a rendering requirement of another specification contradicts a requirement of UAAG 1.0, the user agent may disregard the rendering requirement of the other specification and still satisfy this checkpoint; see the section on the relation of this document to general software design guidelines and other specifications for more information.
  3. The user agent is not required to satisfy this checkpoint for all implemented specifications; see the section on conformance profiles for more information.
  4. This checkpoint excludes the requirements of checkpoint 2.6.
  1. Accessible notification of user about changes in content when specific content is refreshed without a total page refresh (Referece WAI-ARIA)
2.4 Allow time-independent interaction (P1)

(Techniques for 2.4)
1. For rendered content where user input is only possible within a finite time interval controlled by the user agent, allow configuration to provide a view where user interaction is time-independent.

Sufficient Techniques

  1. The user agent may satisfy this checkpoint by pausing processing automatically to allow for user input, and resuming processing on explicit user request. When using this technique, pause at the end of each time interval where user input is possible. In the paused state:
    • Alert the user that the rendered content has been paused (e.g., highlight the pause button in a multimedia player's control panel).
    • Highlight which enabled elements are time-sensitive.
    • Allow the user to interact with the enabled elements.
    • Allow the user to resume on explicit user request (e.g., by pressing the play button in a multimedia player's control panel; see also checkpoint 4.5).
  2. The user agent may satisfy this checkpoint by generating a time-independent (or, "static") view, based on the original content, that offers the user the same opportunities for interaction. The static view should reflect the structure and flow of the original time-sensitive presentation; orientation cues will help users understand the context for various interaction opportunities.

Normative inclusions and exclusions

  1. When satisfying this checkpoint for a real-time presentation, the user agent may discard packets that continue to arrive after the construction of the time-independent view (e.g., when paused or after the construction of a static view).
  2. This checkpoint does not apply when the user agent cannot recognize the time interval in the presentation format, or when the user agent cannot control the timing (e.g., because it is controlled by the server).
  1.  how to handle interactions that are out of ua control - security timeout from server, ajax refresh
3.1 Toggle background images (P1)

(Techniques for 3.1)
1. Allow configuration not to render background image content.
Sufficient Techniques
  1. The user agent may satisfy this checkpoint with a configuration to not render any images, including background images. However, user agents should satisfy this checkpoint by allowing users to turn off background images alone, independent of other types of images in content.

Normative inclusions and exclusions

  1. This checkpoint must be satisfied for all implemented image specifications; see the section on conformance profiles.
  2. When configured not to render background images, the user agent is not required to retrieve them until the user requests them explicitly. When background images are not rendered, user agents should render a solid background color instead; see checkpoint 4.3 for information about text colors.
  3. This checkpoint only requires control of background images for "two-layered" renderings, where the background is considered the first layer and everything rendered above it is considered the second layer.
  4. Conformance profile labels: Image
  1.   need clarification in 3.1 - are we talking about page level background images.or all element background images. The toggle control could affect all backgrounds identifiable as such in the page, though. Or it could be scoped to a current object.
  2. what happens if backround images are used in ajax widgets and images are turned off? <new from JA>
3.2 Toggle audio, video, animated images (P1)

(Techniques for 3.2)
1. Allow configuration not to render audio, video, or animated image content, except on explicit user request.
Sufficient Techniques
  1. The user agent may satisfy this checkpoint by making video and animated images invisible and audio silent, but this technique is not recommended.

Normative inclusions and exclusions

  1. This configuration is required for content rendered without any user interaction (including content rendered on load or as the result of a script), as well as content rendered as the result of user interaction that is not an explicit user request (e.g., when the user activates a link).
  2. This checkpoint must be satisfied for all implemented audio, video, and animated image specifications; see the section on conformance profiles.
  3. When configured not to render audio, video, or animated images except on explicit user request, the user agent is not required to retrieve them until the user requests them explicitly.
  4. Conformance profile labels: Animation, Video, Audio
  1. annimations can be created in many way (gif, javascript, flash, svg, etc), UA can only control some (e.g. gif, svg[?]) - is is reasonable to require the UA to control items it may know noting about. This is related to Compound Documents.
  2. animated icons in title bar- (http://lists.w3.org/Archives/Public/w3c-wai-ua/2006JulSep/0016.html)
    may need to redefine the content area (viewport) to include the parts of the user interface/chrome (title bar, address bar, and tabs, etc) that render author created content
3.3 Toggle animated or blinking text (P1)

(Techniques for 3.3)
1. Allow configuration to render animated or blinking text content as motionless, unblinking text. Blinking text is text whose visual rendering alternates between visible and invisible, at any rate of change.

Sufficient techniques

  1. In this configuration, the user must still have access to the same text content, but the user agent may render it in a separate viewport (e.g., for large amounts of streaming text).
  2. The user agent may satisfy this checkpoint by always rendering animated or blinking text as motionless, unblinking text.

Normative inclusions and exclusions

  1. This checkpoint must be satisfied for all implemented specifications that support blinking; see the section on conformance profiles.
  2. This checkpoint does not apply for blinking and animation effects caused by mechanisms that the user agent cannot recognize.
  3. Checkpoint 4.3 addresses user control of blinking effects caused by rapid color changes.
  4. Conformance profile labels: VisualText
  1.  annimation can be created in many way (gif, javascript, flash, svg, etc), UA can only control some (e.g. gif, svg[?]) (see issue in 3.2)
  2. animated icons in title bar- (http://lists.w3.org/Archives/Public/w3c-wai-ua/2006JulSep/0016.html)
    may need to redefine the content area (viewport) to include the title bar, address bar, and tabs, etc.(see issue in 3.2)
3.4 Toggle scripts (P1)

(Techniques for 3.4)
1. Allow configuration not to execute any executable content (e.g., scripts and applets). Normative inclusions and exclusions
  1. This checkpoint does not apply to plug-ins and other programs that are not part of content.
  1. Definition concerns. UA executes (has control over) javascript. UA does not execute (has no control over) applets, objects, etc. (plugins) - these require separate applications
  2. UA/user needs control over positioning and chrome attributes of generated content (javascript pop-ups with no address bar or scroll bar)
  3. need abillity to control or over-ride the content rendered by html or script or other method
3.5 Toggle automatic content retrieval (P1)

(Techniques for 3.5)
1. Allow configuration so that the user agent only retrieves content on explicit user request. Normative inclusions and exclusions
  1. When the user chooses not to retrieve (fresh) content, the user agent may ignore that content; buffering is not required.
  2. This checkpoint only applies when the user agent (not the server) automatically initiates the request for fresh content. However, the user agent is not required to satisfy this checkpoint for "client-side redirects," i.e., author-specified instructions that a piece of content is temporary and intermediate, and is replaced by content that results from a second request.
  1.  AJAX - content retieval and update without page refresh (http://www.w3.org/2006/07/20-ua-minutes.html)
  2. the information written by the author in a manner, such that the UA can provide configuration parameters
  3. how is the updated info displayed and the user alerted. not a sole UA responsibility, author should provide
4.3 Configure text colors (P1)

(Techniques for 4.3)
1. Allow global configuration of the foreground and background color of all visually rendered text content.

  1.  may need to expand to include all foreground and background color. Author can change chrome scroll colors with CSS, including mouse arrows, and other chrome. . the scroll bar functionality is chrome, the change of color etc. (overriding user settings) is a viewport control
2. As part of satisfying provision one of this checkpoint, provide a configuration option to override foreground and background colors specified by the author or user agent defaults.    
3. As part of satisfying provision one of this checkpoint, offer a range of colors to the user that includes at least:
  • the range offered by the conventional utility available in the operating environment that allows users to choose colors, or
  • if no such utility is available, the range of colors supported by the conventional APIs of the operating environment for specifying colors.
   
4.4 Slow multimedia (P1)

(Techniques for 4.4)
1. Allow the user to slow the presentation rate of rendered audio and animation content (including video and animated images).

Normative inclusions and exclusions

  1. The user agent is not required to satisfy this checkpoint for audio and animations whose recognized role is to create a purely stylistic effect. Purely stylistic effects include background sounds, decorative animated images, and effects caused by style sheets.
  2. Conformance profile labels: Animation, Audio

normative exclusion:
1. The user agent is not required to satisfy this checkpoint for audio and animations whose recognized role is to create a purely stylistic effect. Purely stylistic effects include background sounds, decorative animated images, and effects caused by style sheets.

  1. the purpose of the audio, animation, etc. should not matter. The user should be able to stop it (CP3.2) or slow it down (CP4.4). How is the UA to know what is stylistic and what is real content? it doesn't matter what the role is, the user still needs control.
    remove exclusion 1.
2. As part of satisfying provision one of this checkpoint, for a visual track, provide at least one setting between 40% and 60% of the original speed.    
3. As part of satisfying provision one of this checkpoint, for a prerecorded audio track including audio-only presentations, provide at least one setting between 75% and 80% of the original speed.    
4. When the user agent allows the user to slow the visual track of a synchronized multimedia presentation to between 100% and 80% of its original speed, synchronize the visual and audio tracks (per checkpoint 2.6). Below 80%, the user agent is not required to render the audio track.    
4.7 Global volume control (P1)

(Techniques for 4.7)
1. Allow global configuration of the volume of all rendered audio, with an option to override audio volumes specified by the author or user agent defaults. Normative inclusions and exclusions
  1. This checkpoint must be satisfied for all implemented specifications that produce sound; see the section on conformance profiles.
  2. Conformance profile labels: Audio
  3. Conformance detail: For both content and user agent
  1. UA's do not currently render sound natively, they require an external process. only that process can control the volume of the audio rendered by that process. Process may or may not be native to OS. The UA may not know about audio control seperate from the OS.
2. As part of satisfying provision one of this checkpoint, allow the user to choose zero volume (i.e., silent).    
4.8 Independent volume control (P1)

(Techniques for 4.8)
1. Allow independent control of the volumes of rendered audio content synchronized to play simultaneously.

Normative inclusions and exclusions

  1. The user control required by this checkpoint includes the ability to override author-specified volumes for the relevant sources of audio.
  2. The user agent is not required to satisfy this checkpoint for audio whose recognized role is to create a purely stylistic effect; see checkpoint 4.4 for more information about what constitutes a stylistic effect.
  3. Conformance profile labels: Audio
  1. UA that have roles to control audio are usually "plug-ins" or screen readers. not 'standard' user agents
  2. definition of "recongnized" in normative inclusions #2 is not the same as UAAG definition of "recongnize", definition of "recognize" is too focused on HTML
    change normative inclusion #2 UA should be required to adjust volume for all audio content - stylistic or semantic
  3. in the note: need to clarify by adding "including foreground and background audio" (semantic vs. sytlistic - regardless of the stated 'role' of the content)
4.9 Configure synthesized speech rate (P1)

(Techniques for 4.9)
1. Allow configuration of the synthesized speech rate, according to the full range offered by the speech synthesizer.

Normative inclusions and exclusions

  1. Conformance profile labels: Speech
  1.   this is very screen reader specific.most UA that are self-voiceing are using extensions or plug-ins
    (where do plug-in and extensions fit in UAAG?)
    [editor note: this may be irrelevant, as the checkpoint only pertains to UA attempting compliance in the Speech area]

 

4.14 Choose style sheets (P1)

(Techniques for 4.14)
1. Allow the user to choose from and apply alternative author style sheets (such as linked style sheets).

Normative inclusions and exclusions

  1. This checkpoint only applies to user agents that support style sheets.
 
2. Allow the user to choose from and apply at least one user style sheet.    
3. Allow the user to turn off (i.e., ignore) author and user style sheets.  
  1. user selectable javascript changing DOM on page load (where does this fit in guidelines)  http://www.opera.com/support/tutorials/userjs/
6.1 Programmatic access to HTML/XML infoset (P1)

(Techniques for 6.1)
1. Provide programmatic read access to XML content by making available all of the information items defined by the W3C XML Infoset [INFOSET].    
2. Provide programmatic read access to HTML content by making available all of the following information items defined by the W3C XML Infoset [INFOSET]:  
  1.  A major concern with these 2 guidelines (6.1 & 6.2) is that out-of-process DOM APIs (such as accessibility APIs and ISimpleDOMNode) are often readonly and not read/write, which can be a problem for users of these APIs, such as ATs.
    But in-process APIs, such as JavaScript and XUL, which are used by plugins, extensions, and DHTML/AJAX Web applications, are read-write so there isn't a problem for them.
3. If the user can modify the state or value of a piece of HTML or XML content through the user interface (e.g., by checking a box or editing a text area), allow programmatic read access to the current state or value, and allow the same degree of write access programmatically as is available through the user interface.    
6.2 DOM access to HTML/XML content (P1)

(Techniques for 6.2)
1. Provide access to the content required in checkpoint 6.1 by conforming to the following modules of the W3C Document Object Model (DOM) Level 2 Core Specification [DOM2CORE] and exporting bindings for the interfaces they define:
  • for HTML: the Core module
  • for XML: the Core and XML modules

Normative inclusions and exclusions

  1. Refer to the "Document Object Model (DOM) Level 2 Core Specification" [DOM2CORE] for information about which versions of HTML, XML, Java, and ECMAScript are covered. Appendix D contains the Java bindings and Appendix E contains the ECMAScript bindings.
  2. The user agent is not required to export the bindings outside of the user agent process (though doing so may be useful to assistive technology developers).

 

 

 

2. As part of satisfying provision one of this checkpoint:
  • In the Java and ECMAScript operating environments, export the normative bindings specified in the DOM Level 2 Core Specification [DOM2CORE], or
  • In other operating environments, the exported bindings (e.g., C++) must be publicly documented.
 
  1. A major concern with these 2 guidelines (6.1 & 6.2) is that out-of-process DOM APIs (such as accessibility APIs and ISimpleDOMNode) are often readonly and not read/write, which can be a problem for users of these APIs, such as ATs.
    But in-process APIs, such as JavaScript and XUL, which are used by plugins, extensions, and DHTML/AJAX Web applications, are read-write so there isn't a problem for them.
6.6 Programmatic notification of changes (P1)

(Techniques for 6.6)
1. Provide programmatic notification of changes to content, states and values of content, user agent user interface controls, selection, content focus, and user interface focus.

Normative inclusions and exclusions

  1. The user agent is not required to provide notification of changes in the rendering of content (e.g., due to an animation effect or an effect caused by a style sheet) unless the document object is modified as part of those changes.
  2. Conformance profile labels: Selection
  3. Conformance detail: For both content and user agent
  1. not all events are referenced in the DOM
    not just limit notifications to AT through the DOM should include notification through the accessibility API
  2. no caret indicator in the DOM, AT must rely on accessibility api for caret informaton/location
  3. AJAX = html + css+ javascript, accessibility tools can access dom for js events and html, but css changes are difficult
2. As part of satisfying provision one of this checkpoint, implement at least one API according to the API cascade of provision two of checkpoint 6.3.  
  1. issue: this may be out of date. in past calls we have talked about UAs increasingly relying on API rather than the DOM. How do we update this exclusion?
6.7 Conventional keyboard APIs (P1)

(Techniques for 6.7)
1. Implement APIs for the keyboard as follows:
  • Follow operating environment conventions.
  • If no conventions exist, implement publicly documented APIs.
 
  1. plug-in keybindings, more conflicts with UA, AT
    if plug-in does not need a key, it should pass it on to the UA, not swallow it.
  2. Plug-ins should have some pass through to the UA function
  3. chaining, if something higher up the api chain gets a key lower level api may not see the event
7.1 Respect focus and selection conventions (P1)

(Techniques for 7.1)
1. Follow operating environment conventions that benefit accessibility when implementing the selection, content focus, and user interface focus.

Normative inclusions and exclusions

  1. This checkpoint is mutually exclusive of checkpoint 7.3 since it has a higher priority.
  2. Conformance profile labels: Selection
 
  1. Selection in browser content is problematic - some browsers don't allow content selection from the keyboard

 

8.1 Implement accessibility features (P1)

(Techniques for 8.1)
1. Implement the accessibility features of specifications (e.g., markup languages, style sheet languages, metadata languages, and graphics formats).

Normative inclusions and exclusions

  1. This checkpoint applies to both W3C-developed and non-W3C specifications.
  2. For the purposes of this checkpoint, an accessibility feature of a specification is either:
    • one identified as such in the specification, or
    • one that allows the author to satisfy any requirement of the "Web Content Accessibility Guidelines 1.0" [WCAG10].
  3. The user agent is not required to satisfy this checkpoint for all implemented specifications; see the section on conformance profiles for more information.
  4. Conformance detail: For all content
  1.   what kind of information are we trying to convey to the user about the relationsship of columnes in a colgroup. What is the UA supposed to communicate to the user.
  2. TABINDEX and ACCESSKEY as curently implementd are confusing to end users. Although TABINDEX=-1 and ACCESSKEY are used extensively in AJAX and new web applications. How to resolve?
9.1 Provide content focus (P1)

(Techniques for 9.1)
1. Provide at least one content focus for each viewport (including frames) where enabled elements are part of the rendered content.

Normative inclusions and exclusions

  1. When a viewport includes no enabled elements (either because the format does not provide for this, or a given piece of content has no enabled elements), the content focus requirements of the following checkpoints do not apply: 1.2, 5.1, 5.4, 6.6, 7.1, 9.3, 9.4, 9.5, 9.6, 9.7, 10.2, and 11.5.
  1. need to update the definitons of "enable elements" and "interactive elements" to provide for components used in DHTML/AJAX. Definition change may impact the scope of other checkpoints.
  2. Where is the line drawn between what the UA vs Author coding should do to provide for accessibility.
2. Allow the user to make the content focus of each viewport the current focus.    
9.2 Provide user interface focus (P1)

(Techniques for 9.2)
1. Provide a user interface focus.  
  1. are extensions to the user interface (chrome) considered part of the 'base' UA? Should extensions conform to UAAG? We think, yes. Does UAAG need addtional checkpoints to cover this? Will adding techniqes to cover this, change the scope of the checkpoint?
  2. Definition of Content. Related to Compound Documents and DHTML/AJAX. Focus management between base UA and nested/child UA (Object, flash, mathml, svg). Also, applications within web content that create a new user interface. Is this new application with it's own user interface considered a new embedded UA that must conform to UAAG or just more content?
9.3 Move content focus (P1)

(Techniques for 9.3)
1. Allow the user to move the content focus to any enabled element in the viewport.

Sufficient techniques

  1. To satisfy provision two of this checkpoint, configuration is preferred, but is not required if the content focus only ever changes on explicit user request.

Normative inclusions and exclusions

  1. The user agent may also include disabled elements in the navigation order.
  1. consider combining 9.3 (move content focus forward) with 9.7 (move content focus reverse). Add 'moving backward' to requirement 1 of 9.3. Moving content focus forward and backward is standard functionality in UAs.
2. Allow configuration so that the content focus of a viewport only changes on explicit user request.    
3. If the author has not specified a navigation order, allow at least forward sequential navigation, in document order, to each element in the set established by provision one of this checkpoint.    

 

9.4 Restore viewport state history (P1)

(Techniques for 9.4)
1. For user agents that implement a viewport history mechanism, for each state in a viewport's browsing history, maintain information about the point of regard, content focus, and selection.

Normative inclusions and exclusions

  1. The viewport history associates values for these three state variables (point of regard, content focus, and selection) with a particular document object. If the user returns to a state in the history and the user agent retrieves new content, the user agent is not required to restore the saved values of the three state variables.
  2. Conformance profile labels: Selection
  1.   browser has base functionality to save the 3 states- but content and user configuration can change this. Need to add to Note:. This may change scope of the check point.

 

2. When the user returns to any state in the viewport history (e.g., via the "back button"), restore the saved values for the point of regard, content focus, and selection.    
11.1 Current user input configuration (P1)

(Techniques for 11.1)
1. Provide information to the user about current user preferences for input configurations.

Sufficient techniques

  1. To satisfy this checkpoint, the user agent may make available binding information in a centralized fashion (e.g., a list of bindings) or a distributed fashion (e.g., by listing keyboard shortcuts in user interface menus). See related documentation checkpoints 12.2, 12.3, and 12.5.

Inclusions and Exclusions

  1. Conformance detail: For user agent features
 
12.2 Provide documentation of accessibility features (P1)

(Techniques for 12.2)
1. Provide documentation of all user agent features that benefit accessibility.

Sufficient techniques

  1. The user agent may satisfy this checkpoint either by
    • providing a centralized view of the accessibility features, or
    • integrating accessibility features into the rest of the documentation.
    A centralized view is sufficient to satisfy this checkpoint and is required to satisfy checkpoint 12.5.

Normative inclusions and exclusions

  1. For the purposes of this checkpoint, a user agent feature that benefits accessibility is one implemented to satisfy the requirements of this document (including the requirements of checkpoints 8.1 and 7.3, and the API requirements of guideline 6).
  2. Conformance detail: For user agent features
see http://lists.w3.org/Archives/Public/w3c-wai-ua/2006OctDec/0049.html
  1. Update normative inclusion 1. to include "only if a feature is implemented" (the inclusion specifies the requirements of 8.1, 7.3, and guideline 6. some of the requirements may not be implemented, and the UA should not have to document them) (conformance for 12.2 is determined by dcoumentation, not implementation.)
12.3 Provide documentation of default bindings (P1)

(Techniques for 12.3)
1. Provide documentation of the default user agent input configuration (e.g., the default keyboard bindings).

Sufficient techniques

  1. If the user agent does not allow the user to override the default user agent input configuration (see checkpoint 11.3), the documentation used to satisfy this checkpoint also satisfies checkpoint 11.1.

Normative Inclusions and exclusions

  1. Conformance detail: For user agent features
  1.  Remove sufficient technique from 12.3 (poorly worded and a statement of fact)

Priority 2 checkpoints

Checkpoints Provisions In/Exclusions Issues/Gaps
4.12 Specific synthesized speech characteristics (P2)

(Techniques for 4.12)
1. Allow configuration of synthesized speech pitch. Pitch refers to the average frequency of the speaking voice.

Normative inclusions and exclusions

  1. Conformance profile labels: Speech
  1. All (1-4) This is very dependent on the speech synthesizer and beyond the control of the UA [editor note: delete this. CP is only for Speech conformance]
2. Allow configuration of synthesized speech pitch range. Pitch range specifies a variation in average frequency.    
3. Allow configuration of synthesized speech stress. Stress refers to the height of "local peaks" in the intonation contour of the voice.    
4. Allow configuration of synthesized speech richness. Richness refers to the richness or brightness of the voice.    
4.13 Configure synthesized speech features (P2)

(Techniques for 4.13)
1. Provide support for user-defined extensions to the synthesized speech dictionary.

 

  1. may not be completely controllable by the UA. there is negotiation between html, UA rendering, and text to speech engine.
  2. allow user to control components (speech characteristics) seperately, but there may be a synergistic effect with in the TTS, and additional synergies with other markup (Voice XML, etc.)
  3. settings feed off of each other with unexpected consequences. User is unsure which componnent is at fault...UA, or TTS, or markup
  4. symbols and dictionary definitions, are unique to each TTS, it is a speech setting of sorts
  5. TTS is trying to determine context of string of information to determine inflection, etc
  6. difficult to control, sythesizer has specific settings different from html settings. e.g. HP (Hewelt Packard), configure UA to not expand abbr, then send HP to synthsizer, and sythesizer says 'horsepower' as its own generated expansion.
2. Provide support for spell-out: where text is spelled one character at a time, or according to language-dependent pronunciation rules.    
3. Allow at least two configurations for speaking numerals: one where numerals are spoken as individual digits, and one where full numbers are spoken.  
  1. numerals, more discussion how to handle dates, numbers and measurements
4. Allow at least two configurations for speaking punctuation: one where punctuation is spoken literally, and one where punctuation is rendered as natural pauses.    
6.10 Timely exchanges through APIs (P2)

(Techniques for 6.10)
1. For APIs implemented to satisfy the requirements of this document, ensure that programmatic exchanges proceed in a timely manner.

Normative inclusions and exclusions

  1. Conformance detail: For both content and user agent
  1. define 'timely'
  2. chaining, if something higher up the api chain gets a key lower level api may not see the event
  3. UA extensions keybinding conflicts
    big conflicts. keybinding negotiation (extension, content access key, plugins)
    perhaps assign keys to roles, or similar to fonts have a list of proposed keys with fallback options
  4. Situations in which an API exchange is too slow include, but are not limited to, the following:
    1. The user agent updates the content in the active view but does not indicate the change through the API in a timely manner such that an AT can update its cached content before the next user query or command. As a result, the user ends up working with stale content.
    2. The user agent processes user input but does not indicate confirmation through the API in a timely manner such that the user knows the input was received. As a result, the user is apt to think the input was lost and repeat the action.
7.3 Respect operating environment conventions (P2)

(Techniques for 7.3)
1. Follow operating environment conventions that benefit accessibility. In particular, follow conventions that benefit accessibility for user interface design, keyboard configuration, product installation, and documentation.

Normative inclusions and exclusions

  1. For the purposes of this checkpoint, an operating environment convention that benefits accessibility is either
    • one identified as such in operating environment design or accessibility guidelines, or
    • one that allows the author to satisfy any requirement of the "Web Content Accessibility Guidelines 1.0" [WCAG10] or of the current document.
  2. This checkpoint excludes the requirements of checkpoints 7.1 and 7.4.
  3. Conformance detail: For user agent features
  1. There are some issues between AJAX widgets/controls and High contrast mode and alternate keyboard interfaces (sticky keys)

 

8.2 Conform to specifications (P2)

(Techniques for 8.2)
1. Use and conform to either
  • W3C Recommendations when they are available and appropriate for a task, or
  • non-W3C specifications that enable the creation of content that conforms at level A or better to the Web Content Accessibility Guidelines 1.0 [WCAG10].

Sufficient techniques

  1. When a requirement of another specification contradicts a requirement of the current document, the user agent may disregard the requirement of the other specification and still satisfy this checkpoint.

Normative inclusions and exclusions

  1. A specification is considered "available" if it is published (e.g., as a W3C Recommendation) in time for integration into a user agent's development cycle.
  2. The user agent is not required to satisfy this checkpoint for all implemented specifications; see the section on conformance profiles for more information.
  3. Conformance detail: For all content
  1.  Should this be removed due to vagueness. Can you pick an choose conformance to specifications. Or, must a UA conform to all specifications for all item in the UAAG conformance claim.
9.5 No events on focus change (P2)

(Techniques for 9.5)
1. Allow configuration so that moving the content focus to or from an enabled element does not automatically activate any explicitly associated event handlers of any event type.

Normative inclusions and exclusions

  1. Conformance profile labels: Events
  1. the UA does not know know the state of event handlers.
  2. events on DHTML controls, related to WAI_ARIA
9.8 Provide text search (P2)

(Techniques for 9.8)
1. Allow the user to search within rendered text content for a sequence of characters from the document character set.

Normative inclusions and exclusions

  1. Conformance detail: For all rendered content
  1. allow searching within conditional content. Also, what happens when condtional content - "alt" (images on) become rendered content - "alt" (images off)
2. Allow the user to start a forward search (in document order) from any selected or focused location in content.  
  1. Remove requirement 2 of 9.8.. removing requirement for "forward" search implies that requiement 1 includes the current functionality of UAs providing forward/backward search functionality [3]
3. When there is a match, do both of the following:
  • move the viewport so that the matched text content is at least partially within it, and
  • allow the user to search for the next instance of the text from the location of the match.
   
4. Alert the user when there is no match or after the last match in content (i.e., prior to starting the search over from the beginning of content).    
5. Provide a case-insensitive search option for text in scripts (i.e., writing systems) where case is significant.    
9.9 Allow structured navigation (P2)

(Techniques for 9.9)
1. Allow the user to navigate efficiently to and among important structural elements in rendered content.  
  1. Change "allow" to "provide", structured navigation should be provided natively, not added on by AT.
  2. Issue/Technique: add technique or requirement stating that UA must provide object attributes (element name and roles, etc.) to the accessibiltiy API to enable structured navigation function by AT
    this is an issue if we change wording to "provide"
    this is a technique if wording remais as "allow"
2. As part of satisfying provision one of this checkpoint, allow forward and backward sequential navigation.    
11.2 Current author input configuration (P2)

(Techniques for 11.2)
1. Provide a centralized view of the current author-specified input configuration.

Sufficient techniques

  1. The user agent may satisfy this checkpoint by providing different views for different input modalities (keyboard, pointing device, and voice).

Normative inclusions and exclusions

  1. Conformance detail: For all content
  1. Should the user be able to override (change) these input configurations in the UA
  2. How should UA expose author specified keybindings that occur in javascript or other scripting which are not exposed in the DOM or to accessibility APIs. [should the be a WCAG requirement?]
11.3 Allow override of bindings (P2)

(Techniques for 11.3)
1. Allow the user to override any binding that is part of the user agent default input configuration.

Normative inclusions and exclusions

  1. The user agent is not required to allow the user to override conventional bindings for the operating environment (e.g., for access to help).
  2. The override requirement only applies to bindings for the same input modality (e.g., the user must be able to override a keyboard binding with another keyboard binding).
  3. This checkpoint excludes the requirements of checkpoint 11.4.
  4. Conformance detail: For user agent features
  1. move 'doing more'
    2. Allow users to easily restore the default input configuration.
    to be a Normative Inclusion
  2. add Normative Inclusion: When user overrides a binding the UA must update the current iinput configuration (in order to meet 11.1 requiarements)
12.5 Provide dedicated accessibility section (P2)

(Techniques for 12.5)
1. Provide a centralized view of all features of the user agent that benefit accessibility, in a dedicated section of the documentation.

Sufficient techniques

  1. A centralized view is required to satisfy this checkpoint and is sufficient to satisfy checkpoint 12.2.

Normative inclusions and exclusions

  1. The features that benefit accessibility are those defined in checkpoint 12.2.
  2. Conformance detail: For user agent features
  1.  needs clarification in wording in normative inclusion 1, specifing user agent features rather than content.
  2. expand Normative inclustion to include content info from 8.1 and techniques of 12.2

Priority 3 checkpoints

Checkpoints Provisions In/Exclusions Issues/Gaps
9.10 Configure important elements (P3)

(Techniques for 9.10)
1. Allow configuration of the set of important elements and attributes identified for checkpoints 9.9 and 10.4.  
  1. consider removing and adding as a "doing more "technique for 9.9 and 10.4, or adding configuration as a requirement for 9.9 and 10.4.
2. As part of satisfying provision one of this checkpoint, allow the user to include and exclude element types in the set.    

Updated: January 11, 2007

Author: Jim Allan