Proposed 2.9.1 Background Image Toggle

2.9.1 (former 4.9.1) Background Image Toggle: The user can have all background images shown or hidden. (Level A)

Intent:

It can be difficult for some people to read text or identify images when the background is complex or doesn't contrast well with the foreground. Allowing users to disable the display of background images helps ensure that foreground content remains easy to read. This can also help remove purely decorative distractions, which is important for some users.

Users could have the option to have non-transparent backgrounds of a solid color of their choice drawn behind text, rather than turning off background images.

Because background images occasionally convey important information, when their display is turned off the user agent should give users access to any alternative content associated with them.

This checkpoint does not address issues of multi-layered renderings and does not require the user agent to change background rendering for multi-layer renderings (refer, for example, to the z-index property in Cascading Style Sheets, level 2 ([CSS2], section 9.9.1)

Examples:

James has a reading disability where he needs text to be clear from distractions that are not related to the text. He configures his user agent not to load background images and navigates to a web page. James then gets only the text from the web page without any images interfering with what he is reading.

Related Resources:

1. In CSS, background images may be turned on/off with the background and background-image properties ([CSS2], section 14.2.1).

2. The z-index property in Cascading Style Sheets, level 2 ([CSS2], section 9.9.1)

3. Because background images occasionally convey important information, when their display is turned off the user agent should give users access to any alternative content associated with them. (At the time of this writing, HTML does not support alternative content for background images, but this may be supported in other technologies or future versions.)

4. See Success Criteria 1.4.1 "Configure Text" for more information related to background colors.

Summary

Details

Proposed

2.9.2 Time-Based Media Load-Only: The user can load time-based media content such that the first frame is displayed (if video), but the content is not played until explicit user request. (Level A)

Intent

As an opt-in user setting, autoplay for media is off/paused, until the user activates 'play'. Prevent media from playing without explicit request from the user. For example, Uart, a screen reader user, opens a page with an audio element that starts playing immediately. The user cannot hear the screen reader because of the noise from the audio element, and must search through the page to find the 'noisy' element to turn it off (or pause). Once the screen reader is the sole source of audio the user can read the page and determine if the audio is important and choose to play it.

Examples

1. Using the same techniques as are used for pop-up blockers, the user agent checks to see if the play() request was from user interaction or a background script. If isn't from direct user interaction, the user agent could ask the user to explicitly allow the media to play, perhaps remembering the choice for the site.

2. Playback of a <video> or <audio> element can only be triggered in response to a user gesture on a touch screen device with no keyboard (like pop-up blockers). The user agent provides a visual and auditory indicator that the video is in paused state and needs user interaction to start.

3. The user agent provides a global control that calls "paused for user interaction" for all media when a page loads.

Resources

HTML5 4.8.10.8 Playing the media resource (http://dev.w3.org/html5/spec/Overview.html#playing-the-media-resource)

Summary

Details

Intent of Success Criterion 1.4.1

Users need to able to access a wide range of font sizes, styles, colors, and other attributes in order to find the combination that works best for their particular needs. For example, some users want to increase font size to make text more legible, while other users want to reduce the font size to decrease the need to scroll the content. <NEW>Other users may want to set a solid color behind all text in order to cover background images that might reduce readability.</NEW> In providing these preferences, it is important to avoid making assumptions. For example, some users want to reduce the font size to decrease the need to scroll the content.

Summary

Details

New SC

Jan's email

BTW: I'm *not* pushing hard for a new SC, we already have a lot. So if someone can see how this is covered elsewhere, that would be great!

New SC: Present Status Information in Proximity: The user can specify that status information for rendered elements be either incorporated into the rendering or displayed in proximity to the element.

Intent: Users need to be able to discover and make use of status information for elements, which is more difficult if the information is displayed at a distance from the element (e.g., the status bar).

Examples: (1) Link target: A browser that typically displays the target of a link in the status bar when the link receives focus, includes an option to display the target in an overlay adjacent to the link. (2) Required field: A browser renders a required form control with an adjacent icon indicating this status, rather than a note in the status bar when the control receives focus.

Summary

Details

Guideline 1.3

Greg's email with the context and rationale behind the changes he is proposing. "The changes to 1.3 include: 1. made it broader by changing "selection, content focus, enabled elements, visited links" to "selection, active keyboard focus, and interactive elements"

Existing Text of 1.3

1.3 Provide highlighting for selection, active keyboard focus, and interactive elements.

Summary

Details

SC 1.3.1

Greg's email with the context and rationale behind the changes he is proposing.

Existing Text of 1.3.1

1.3.1 (former 3.5.1) Highlighted Items: The user can have the following highlighted /when recognized,/ so that each class is uniquely distinguished (Level A):
* (a) the selection
* (b) /the active keyboard /focus
* (c) the active window
* (d) links that have been visited recently
* (e) links that have not been visited recently

Changes

The changes to 1.3.1 Highlighted Items include:
1. added "when recognized" to the SC, so we would not need to repeat it in each of the bullet items
2. changed "content focus" to "the active keyboard focus" because the former term is no longer used (except it also needs to be changed in 2.2.3)
3. added "the active window"
4. removed "recognized enabled elements", which were split off into 1.3.3 Highlighted Input Controls
5. deleted "presence of alternative content" because that's redundant to 1.1.3 Identify Alternative Content
6. changed "recently visited links" to "links that have been recently visited" and "links that have not been recently visited"

Open Questions

1. Is there a more concise way to say "links that have not been visited recently"?

2. Do we want to incorporate any material from the new 1.3.3 Intent and Related Resources sections into those for 1.3.1?

Summary

Details

SC 1.3.2

Greg's email with the context and rationale behind the changes he is proposing.

Existing Text of 1.3.2

*1.3.2 (former 3.5.2) Highlighting Options:* When highlighting classes specified by 1.3.1 Highlighted Items /and 1.3.3 Highlighted Input Controls/, the user can specify highlighting options that include at least (Level A):
* (a) foreground colors,
* (b) background colors, and
* (c) border (configurable color, style, and thickness)

Changes

The changes to 1.3.2 Highlighting Options include:
1. added "and 1.3.3 Highlighted Input Controls" so it covers both the existing 1.3.1 and the new 1.3.3

Summary

Details

SC 1.3.3

Greg's email with the context and rationale behind the changes he is proposing.

Existing Text of 1.3.3

1.3.3 Highlighted Input Controls:* The user can have the following highlighted when they are recognized. (Level AA):
(a) enabled controls that take input (e.g. push buttons, radio buttons, check boxes, and text input fields, but not groupings or static text and images) regardless of whether they are read-write or read-only, and
(b) elements with scripted input handlers (e.g. images or text ranges that have onClick or onKeyPress events) regardless of whether the current state allows them to operate.

Intent for Success Criterion 1.3.3

When a user looks at a page they often want to quickly find the control they need to accomplish their task, yet in some pages the controls may be "buried" amid a large amount of other content, or may be styled to make it very hard to distinguish from other content. This can be particularly difficult for people with visual impairments, who may not be able to easily distinguish visual differences that may be subtle or obvious to users with average vision. It can also be a problem for people with some cognitive impairments, who may have difficulty distinguishing between items with similar or non-standard appearance. The ability to have these items visually distinguished can greatly help reduce the amount of time or number of commands they need to use examining a page. This success criterion works in conjunction with 1.3.1 Highlighted Items, which ensures highlighting of several other classes of information, and with 1.3.2 Highlighting Options, which ensures that the user can customize the highlighting to meet their visual or cognitive needs.

Examples for Success Criterion 1.3.3

* Binh gets easily frustrated when he cannot locate the buttons and links on a page, usually because they don't have the standard appearance he's used to. By turning on the option to have all links appear in bright purple, and all push buttons and the like drawn with a bright purple border, he can easily scan the page and find the items he's looking for.

Related Resources for Success Criterion 1.3.3

* 1.1.3 Identify Presence of Alternative Content (Level A) requires items with alternative content to be highlighted.
* 1.3.1 Highlighted Items (Level A) requires highlighting of additional classes, including the selection, the active keyboard focus, and visited and unvisited links.
* 1.3.2 Highlighting Options (Level A) requires the user be able to customize the appearances of these highlights.

Summary

Details

SC 1.11.1

Simon's email

Existing Text of 1.11.1

1.11.1 (former 3.13.1) Basic Link Information:
The following information is provided for each link (Level A) :
* link element content,
* link title
* link status (visited/selected/hover)

Intent for Success Criterion 1.11.1

Users who use screen readers need to be able to easily discover information about a link, including the title of the link in the event that the link content has the same text as other links on the page. Otherwise the effect of selecting that link is not distinguishable.

Examples for Success Criterion 1.11.1

Robert, who uses a screen reader, hears a list of links read out saying 'more', 'more', 'more'. The browser also displays the link title so that Robert can distinguish which link he must select.

Related Resources for Success Criterion 1.11.1

Web Content Accessibility Guidelines version 2.0

Summary

Details

SC 1.11.2

Simon's email

Existing Text of 1.11.2

1.11.2 (former 3.13.2) Extended Link Information: The following information is provided for each link which does not point to an (x)html file (Level AAA) :
* what will be the consequences of selecting the link (will a file download to desktop occur? Will a text file be opened by the browser?)
* technology type (of the linked Web resource)
* technology file size (of the linked Web resource)
* predicted time to load (of the linked Web resource)
* intra-page/onsite/offsite (whether the link is internal to the resource e.g., the link is to a target in the same Web page)

Intent for Success Criterion 1.11.2

Here we wish to mitigate the possibility of unexpected consequences occurring on link selection; this is especially the case for users who cannot see the visual cues present on the web page. For instance, visual styling can be used to imbue groups of simple links with semantic differences such as downloads or offsite links. This may then become a problem because links which seem the same to a user of assistive technology may have unexpected consequences when selected.

Examples for Success Criterion 1.11.2

Robert, who uses a screen reader, selects a link which is surrounding an image, the user agent downloads the image and displays the raw image file, Robert's assistive technology cannot describe the image or even say what has downloaded because raw images do not have alt elements and image downloaded and displayed is not an html file. If the user agent tells Robert that an image file download will occur on link selection he would not have made that choice as he cannot see the image.

Related Resources for Success Criterion 1.11.1

Web Content Accessibility Guidelines version 2.0

Summary

Details