• ConfigToNotRender

Guideline 3. Allow configuration not to render some content that may reduce accessibility

3.1 Toggle base background images

(Original)

1. Allow configuration not to render images that are rendered on the base background (defn: The base background is the background of the content as a whole, such that no content may be layered behind it. In graphics applications, the base background is often referred to as the canvas.).

Sufficient techniques

1. Allowing users to turn off images that the user agent would render on the base background.

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

Notes

• When background images are not rendered, they are considered conditional content. See checkpoint 2.3 for information about providing access to conditional content.

UAAG2 EDIT HISTORY

• "Base background" formulation approved in July 26 meeting (http://www.w3.org/2007/07/26-ua-minutes.html)

• "Base bakground reformulation" (http://lists.w3.org/Archives/Public/w3c-wai-ua/2007JulSep/0014.html)

• Discussion on July 19 meeting - sent for edits (http://www.w3.org/2007/07/19-ua-minutes.html)

• "Viewport" formulation proposal (http://lists.w3.org/Archives/Public/w3c-wai-ua/2007JulSep/0006.html)

• Initial comments:
  • 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.

  • PP: We need to have a discussion about 1) what browser developers consider possible to implement for this checkpoint and 2) at what level control over background images becomes so fine grained that it is unusable. Is it possible for browser developers to disable background images on every element? Does this amount to ignoring the CSS background and background-image styles plus the background attribute on body? As for users, is it really necessary to have control over all elements on the page? Could a user even practically select the proper element to disable its background image, especially since they might be having a hard time seeing it in the first place (hence the need for this checkpoint).

  • JA: This is an historical issue, see http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0118.html. Can't find a working group response to the issues raised.

  • what happens if background images are used in ajax widgets and images are turned off?

  • PP: I have no good solution for this problem. The browser cannot determine whether background images are being used simply for style or to carry semantic meaning. I think encoding information into CSS background images should really be considered a violation of WCAG that the browser can do little to remedy. If the user turns off CSS, and lots of images with semantic meaning disappear, the content author needs to fix his/her content.

  • CL: The Dojo widget set detects when background images are turned off (as well as when in high contrast)and provides text equivalents for widgets which are rendered using background images. However, widget sets not considering accessibility will not be doing this.

  • 12 July 2007 redefine background image or deprecate guideline because of breaking AJAX widgets??

3.2 Toggle audio, video, animated images, and animated/blinking text

• Allow configuration not to render audio, video, or animated image content, except on explicit user request.

• Allow configuration to render animated or blinking text content as motionless, unblinking text.

Sufficient techniques

• The user agent may satisfy the first success criteria by making video and animated images invisible and audio silent, but this technique is not recommended.

• The user agent may satisfy the second success criteria by showing still images in place of video and image animations. @@Still issues with this@@

• The user must still have access to all animated/blinking text content, but the user agent may render it in a separate viewport (e.g., for large amounts of streaming text).
• The user agent may satisfy the second success criteria by always rendering animated or blinking text as motionless, unblinking text.

Normative inclusions and exclusions

• This checkpoint does not apply for content the user agent cannot deterministically recognize as audio, video, animated images, or animated/blinking text.

• 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).
• This checkpoint must be satisfied for all implemented audio, video, and animated image specifications; see the section on conformance profiles.
• 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.

• Checkpoint 4.3 addresses user control of blinking effects caused by rapid color changes.

• Conformance profile labels: VisualText, Animation, Video, Audio === Note ===

See guideline 4 for additional requirements related to the control of rendered audio, video, and animated images. When these content types are not rendered, they are considered conditional content. See checkpoint 2.3 for information about providing access to conditional content. Animation (a rendering effect) differs from streaming (a delivery mechanism). Streaming content might be rendered as an animation (e.g., an animated stock ticker or vertically scrolling text) or as static text (e.g., movie subtitles, which are rendered for a limited time, but do not give the impression of movement).

UAAG2 EDIT HISTORY

• 3.2 and 3.3 combined

UAAG2 ISSUES from 3.2

• PP: Proposal to combine 3.2 and 3.3 (http://lists.w3.org/Archives/Public/w3c-wai-ua/2007JulSep/0048.html)

• Initial Comments
  • animations 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.

  • PP

    • GIFs: Browser does the rendering. Can show a static frame.
    • Flash: Browser knows about the embedded plug-in. Might allow the user to disable Flash content altogether. This might kill more than heavily animated Flash on a page. But, in general, isn't most Flash animated anyways? Isn't that a point of using it?
    • Video/audio: Browser should know from MIME type that directly linked content is video or audio. Problem is harder when there's a level of indirection For instance, the browser might know to load a plug-in, but could be unaware that the plug-in decided to load some multimedia content.
    • SVG+JS: Hard to know what the JS is doing to the SVG. Animating it? Responding to a mouse click by updating some text? Going off and fetching some data asynchronously?

    • General JS: Even harder to determine. For instance, JS can draw into the <canvas> tag supported by Safari, Webkit, Firefox, IE (via plug-in) etc. The drawing is a bitmap.

  • What if we say if the browser can deterministically ascertain that content is animating, video, or audio, then it must provide an option to conditionally render or not render that content.

  • 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

  • PP: Where is it stated that this checkpoint applies to the viewport, but not to the chrome? I don't see anything immediately in the checkpoint. If it is in some general definition, then, yes, that definition needs to be revised so that this checkpoint (and probably others) apply to rendered documents, chrome of the browser, and any extensions that plug-into the chrome by way of a public API which the browser can control.

UAAG2 ISSUES from 3.3

• Initial comments:
  • animation 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)

  • 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)

• PP: See comments in 3.2. I think whatever decide there, applies here. On that note, is there a reason for having these as two separate checkpoints? To me, animated text falls into the same category as any other animated content.

• 12 July 2007 combine Guidelines 3.3 and 3.2. these are very closely related.

3.4 Toggle executable content (P1)

(Original)

1. Allow configuration not to execute any executable content (e.g., scripts, object, and applets).

Sufficient techniques

1. Provide the user with the ability to toggle whether the base user agent executes content that it is able to . - if cond. content exists reveal it (2.3)
2. Provide the user with the ability to toggle the loading of plugins that execute content the base browser is unable to execute - if cond. content exists reveal it (2.3)

Notes

• Executable content may provide very useful functionality, not all of which causes accessibility problems. If content is not executed it is important to instead render any conditional content that the author may provide.@@take another look at this@@.

UAAG2 ISSUES

• JA proposal: http://lists.w3.org/Archives/Public/w3c-wai-ua/2007JulSep/0071.html

  • remove the normative exclusion
  • New wording: 3.4 Toggle executable content (P1)
    1. Allow configuration not to execute any executable content (e.g., scripts, plugs-ins and applets).

• JR proposal re: new checkpoint for no stripped down user agent windows (http://lists.w3.org/Archives/Public/w3c-wai-ua/2007JulSep/0007.html)

• Initial Comments:
  • Definition concerns. UA executes (has control over) javascript. UA does not execute (has no control over) applets, objects, etc. (plugins) - these require separate applications

  • PP: But the browser does have control over whether those separate applications can load or not. Maybe this checkpoint should be titled with something to the effect of "Toggle executable content," and the definition, inclusions/exclusions, and notes can be fleshed out to include applets, embeds, objects, etc.?

  • UA/user needs control over positioning and chrome attributes of generated content (javascript pop-ups with no address bar or scroll bar)
  • need abillity to control or over-ride the content rendered by html or script or other method

  • PP: These issues seem to call for a whole new checkpoint for me. They are not simply talking about an on/off switch like 3.4. They are saying the user should have some control over how executable content runs.

3.5 Toggle automatic content retrieval (P1)

(Original)

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.

Notes

• For example, if the user agent supports automatic content retrieval, to ensure that the user does not become disoriented by sudden automatic changes, allow configurations such as "Never retrieve content automatically" and "Require confirmation before content retrieval."

UAAG2 ISSUES

• PP: Ideas and discussion of issue: http://lists.w3.org/Archives/Public/w3c-wai-ua/2007JulSep/0016.html

• Initial Comments

  • AJAX - content retieval and update without page refresh (http://www.w3.org/2006/07/20-ua-minutes.html)

  • PP: Disabling automatic content fetches using XMLHttpRequest is difficult unless the browser tracks what event initiated the fetch. For instance, did the user recently give some input that cause the fetch or not? I think determining the original event source for all fetches is untenable though, so I'm not sure what the user agent can do to meet this checkpoint considering AJAX.

  • Perhaps tying into live region markup would help here? The markup is intended to assist a browser plus AT in determining what automatic changes are relevant. But perhaps the browser could also provide a setting that, when enabled, prevents any regions marked live from automatically updating without an explicit user request. I know the live region markup was not designed directly for this purpose, but it seems a valid use.
  • the information written by the author in a manner, such that the UA can provide configuration parameters
  • how is the updated info displayed and the user alerted. not a sole UA responsibility, author should provide

• PP: Is there anything in WCAG 2.0 about providing configuration parameters or disabling auto-refresh to meet this need? I'm not sure what we can / should do in UAAG to address it.

3.6 Toggle images (P2)

(Original)

1. Allow configuration not to render image content.

Sufficient techniques

1. The user agent may satisfy this checkpoint by making images invisible, but this technique is not recommended.

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 images, the user agent is not required to retrieve them until the user requests them explicitly.
3. Conformance profile labels: Image

Notes

• When images are not rendered, they are considered conditional content. See checkpoint 2.3 for information about providing access to conditional content.

UAAG2 ISSUES

• Initial COmments:

  • PP: I want to raise a clarification issue here. I assume this checkpoint was originally talking specifically about <img> tags alone. If so, that criterion should be made explicit now that there is at least one (i.e. CSS background images) to get image content onto a page covered by another checkpoint.

  • 12 July 2007 should toggle all images <img>, <object>, css, etc. there may be additional accessibility issues with element borders adding visual clutter for folks with some types of cognitive disabilities.