Software UI vs. Software aspects of products



***************NOTICE************************************************ 
                                                                                                       
  This work space is being phased out and is no longer kept        
  updated with the latest task force agreements. Please refer to  
  the most recent WCAG2ICT public draft at                                 
  http://www.w3.org/TR/wcag2ict/                                                  
                                                                                                       
************************************************************************* 


Here there is a table containing SC in which we are proposing to use "software", "software aspects of products" or "software user interface". The left column contains text as agreed (or the latest proposal if no agreement has been reached), the middle always uses "software user interfaces" instead of "software aspects of products" and the last column contains my comments.

One related issue is the use of "software product", "software program", "software" or "software user interface" to replace "set of web pages". In the "proposed change" column I have favoured "software product" as I believe that it is better than software user interfaces as a replacement for "set of web pages".

In addition I think that we could define "software user interface", if needed:
  • software user interface: user interface provided by a software product
  • (or alternatively) software user interface: user interface provided by the software aspects of a product
The changes proposed in the middle column are always marked with square brackets and bold style.

Where substitutions are made in the guidance, I've done the exercise of making the substitution in the corresponding SC and/or INTENT to see how it looks. These substitutions are also marked with square brackets and bold style.

Agreed text (or existing text)
Proposed change
Comments
1.1.1 Non-text Content:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This SC applies directly as written, and as described above in WCAG intent. 

CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is accurate.   If they do not appear then, (as with any situation where an SC talks about something that is not present) the SC would be met automatically.

(see introduction for the way to interpret the terms  "Content")
1.1.1 Non-text content

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This SC applies directly as written, and as described above in WCAG intent. 

CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is accurate.   If they do not appear then, (as with any situation where an SC talks about something that is not present) the SC would be met automatically.

(see introduction for the way to interpret the terms  "Content")
LM: The only change here is the heading of the guidance.

GV: The problem I see with "Software User Interface" (here and throughout) is that it sounds like the UI of Software (i.e. software products) and loses the important "Software aspects of products. " I tried "User interface of Software Aspects of products" but that is obviously hard to read. "Software User Interface of Software and Hardware" is only marginally better (ie almost just as bad).
       Perhaps we can put "Software user interfaces (in software and hardware products)" in the repeating header (which no one reads - but which frames the text) and then use "software user interfaces' alone in the text below.
1.2.1 Audio-only and Video-only (Prerecorded):

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

The alternative can be provided directly in the electronic document or software – or provided in a conforming alternate version.

(see Introduction for how to interpret "content")
1.2.1 Audio-only and Video-only (Prerecorded):

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

The alternative can be provided directly in the electronic document or [software product] – or provided in a conforming alternate version.

(see Introduction for how to interpret "content")
LM: In this case there are two changes:
  • The heading
  • In the sentence about "alternatives" I have used "software product" instead of "software" as I think it is better.

GV: Here we definitely don't want to say "software product" because that specifically leaves out the software aspects of hardware products like kiosks, computers, and much more.

1.2.2 Captions (Prerecorded):


Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

Note: The WCAG 2.0 definition of Captions notes that "In some countries, captions are called subtitles".   They are also sometimes referred to as "subtitles for the hearing impaired."   Per the definition in WCAG 2.0, to meet this SC, whether called captions or subtitles, they would have to provide "synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content"  where non-speech information includes "sound effects, music, laughter, speaker identification and location."

(see Introduction for how to interpret "content")
1.2.2 Captions (Prerecorded):


Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

Note: The WCAG 2.0 definition of Captions notes that "In some countries, captions are called subtitles".   They are also sometimes referred to as "subtitles for the hearing impaired."   Per the definition in WCAG 2.0, to meet this SC, whether called captions or subtitles, they would have to provide "synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content"  where non-speech information includes "sound effects, music, laughter, speaker identification and location."

(see Introduction for how to interpret "content")
LM: The only change here is the heading of the guidance.
1.2.3 Audio Description or Media Alternative (Prerecorded):

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above).

Note 1: WCAG 2.0 definition of Audio Description says that Audio Description is "Also called 'video description' and 'descriptive narration.'".

Note 2: Secondary or alternate audio tracks are commonly used for this purpose.
1.2.3 Audio Description or Media Alternative (Prerecorded):

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above).

Note 1: WCAG 2.0 definition of Audio Description says that Audio Description is "Also called 'video description' and 'descriptive narration.'".

Note 2: Secondary or alternate audio tracks are commonly used for this purpose.
LM: The only change here is the heading of the guidance.
1.2.4 Captions (Live):

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

Note: The WCAG 2.0 definition of Captions notes that "In some countries, captions are called subtitles".   They are also sometimes referred to as "subtitles for the hearing impaired."   Per the definition in WCAG 2.0, to meet this SC, whether called captions or subtitles, they would have to provide "synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content"  where non-speech information includes "sound effects, music, laughter, speaker identification and location."

(see Introduction for how to interpret "content")
1.2.4 Captions (Live):

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

Note: The WCAG 2.0 definition of Captions notes that "In some countries, captions are called subtitles".   They are also sometimes referred to as "subtitles for the hearing impaired."   Per the definition in WCAG 2.0, to meet this SC, whether called captions or subtitles, they would have to provide "synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content"  where non-speech information includes "sound effects, music, laughter, speaker identification and location."

(see Introduction for how to interpret "content")
LM: The only change here is the heading of the guidance.
1.2.5 Audio Description (Prerecorded):

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

Note1:  WCAG 2.0 definition of Audio Description says that Audio Description is "Also called 'video description' and 'descriptive narration.'".

Note2:  Secondary or alternate audio tracks are commonly used for this purpose.
1.2.5 Audio Description (Prerecorded):

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0 (above).

Note1:  WCAG 2.0 definition of Audio Description says that Audio Description is "Also called 'video description' and 'descriptive narration.'".

Note2:  Secondary or alternate audio tracks are commonly used for this purpose.
LM: The only change here is the heading of the guidance.
1.2.6 *Sign Language (Prerecorded) [L3]
 - LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
1.2.7 *Extended Audio Description (Prerecorded) [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
1.2.8 * Media Alternative (Prerecorded) [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
1.2.9 *Audio-only (Live) [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
1.3.1 Info and Relationships:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

Note: In software, programmatic determinability is best achieved through the use of accessibility services provided by platform software to enable interoperability between software and assistive technologies.
1.3.1 Info and Relationships:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

Note: In [software user interfaces], programmatic determinability is best achieved through the use of accessibility services provided by platform software to enable interoperability between [software user interfaces] and assistive technologies.
LM: First, there is a change in the heading of the guidance.

Second, I have replaced "software" by "software user interfaces" in the note. I think it works properly because only software that provides a user interface has to deal with interoperability with AT.

GV:   Looks ok
1.3.2 Meaningful Sequence:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above)  where content is interpreted to mean "information and sensory experience to be communicated to the user by means of ICT".

Note that the INTENT for Success Criterion 1.3.2  in Understanding WCAG 2.0 makes it clear that:
  1. providing a particular linear order is only required where it affects meaning.
  2. there may be more than one order that is "correct"
  3. only one correct order needs to be provided.
1.3.2 Meaningful Sequence

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above)  where content is interpreted to mean "information and sensory experience to be communicated to the user by means of ICT".

Note that the INTENT for Success Criterion 1.3.2  in Understanding WCAG 2.0 makes it clear that:
  1. providing a particular linear order is only required where it affects meaning.
  2. there may be more than one order that is "correct"
  3. only one correct order needs to be provided.
LM: The only change here is the heading of the guidance. 
1.3.3 Sensory Characteristics:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

(see Introduction for how to interpret "content")
1.3.3 Sensory Characteristics:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

(see Introduction for how to interpret "content")
LM: The only change here is the heading of the guidance.
1.4.1 Use of Color:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above) substituting "Electronic documents" and "Software" for the phrase "Web Content" in the INTENT.

(see Introduction for how to interpret "content")

Substitution in SC (none)

Substitution in INTENT:

The intent of this Success Criterion is to ensure that all users can access information that is conveyed by color differences, that is, by the use of color where each color has a meaning assigned to it. If the information is conveyed through color differences in an image (or other non-text format), the color may not be seen by users with color deficiencies. In this case, providing the information conveyed with color through another visual means ensures users who cannot see color can still perceive the information.

Color is an important asset in design of [Electronic Documents and Software], enhancing its aesthetic appeal, its usability, and its accessibility. However, some users have difficulty perceiving color. People with partial sight often experience limited color vision, and many older users do not see color well. In addition, people using text-only, limited-color or monochrome displays and browsers will be unable to access information that is presented only in color.

Examples of information conveyed by color differences: “required fields are red", “error is shown in red", and “Mary's sales are in red, Tom's are in blue". Examples of indications of an action include: using color to indicate that a link will open in a new window or that a database entry has been updated successfully. An example of prompting a response would be: using highlighting on form fields to indicate that a required field had been left blank.

Note: This should not in any way discourage the use of color on a page, or even color coding if it is redundant with other visual indication.
1.4.1 Use of Color:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above) [with the word] ["an Electronic Documents or Software User Interface"] [substituted] for "Web Content" [and the word "an Electronic Document or Software User Interface" substituted for "a page"] in the INTENT.

(see Introduction for how to interpret "content")

Substitution in SC (none)

Substitution in INTENT:

The intent of this Success Criterion is to ensure that all users can access information that is conveyed by color differences, that is, by the use of color where each color has a meaning assigned to it. If the information is conveyed through color differences in an image (or other non-text format), the color may not be seen by users with color deficiencies. In this case, providing the information conveyed with color through another visual means ensures users who cannot see color can still perceive the information.

Color is an important asset in design of [an Electronic Document or Software User Interface], enhancing its aesthetic appeal, its usability, and its accessibility. However, some users have difficulty perceiving color. People with partial sight often experience limited color vision, and many older users do not see color well. In addition, people using text-only, limited-color or monochrome displays and browsers will be unable to access information that is presented only in color.

Examples of information conveyed by color differences: “required fields are red", “error is shown in red", and “Mary's sales are in red, Tom's are in blue". Examples of indications of an action include: using color to indicate that a link will open in a new window or that a database entry has been updated successfully. An example of prompting a response would be: using highlighting on form fields to indicate that a required field had been left blank.

Note: This should not in any way discourage the use of color on [an Electronic Document or Software User Interface], or even color coding if it is redundant with other visual indication.
LM: Several notes here:
  • First, we should use our "standard" wording for substitutions: "with the word <> substituted for <>".
  • Second, I think that in the INTENT we should substitute both "web content" (paragraph 2) and "page" (note at the end).
  • In the proposed version I've applied those changes.
  • I've made sure that the substitution works, maintaining the case of already existing words in intent. This is why I propose "an electronic document or software user interface" to replace "web content".




GV: "with the word" should be "with the words"

"an Electronic Documents" should be "an Electronic Document"

     in the INTENT I think we should just use "User Interface" instead of "Software user interface"     It is true for all interfaces and we do not need to restrict this.It is just general background information.
1.4.2 Audio Control:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing "a web page" with "an electronic document or a software user interface" and " any content" with " any part of an electronic document or software user interface".

Substitution in SC:

If any audio on [an electronic document or a software user interface] plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)

Note: Since [any part of an electronic document or software user interface] that does not meet this success criterion can interfere with a user's ability to use the [whole electronic document or software user interface], all content on the [the electronic document or software user interface] (whether or not it is used to meet other success criteria) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

Substitution in INTENT:

Individuals who use screen reading software can find it hard to hear the speech output if there is other audio playing at the same time. This difficulty is exacerbated when the screen reader's speech output is software based (as most are today) and is controlled via the same volume control as the sound. Therefore, it is important that the user be able to turn off the background sound. Note: Having control of the volume includes being able to reduce its volume to zero.

Note: Playing audio automatically when landing on [an electronic document or a software user interface] may affect a screen reader user's ability to find the mechanism to stop it because they navigate by listening and automatically started sounds might interfere with that navigation. Therefore, we discourage the practice of automatically starting sounds (especially if they last more than 3 seconds), and encourage that the sound be started by an action initiated by the user after they reach the page, rather than requiring that the sound be stopped by an action of the user after they land on the page.
1.4.2 Audio Control:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) [with the word]  "an electronic document or a software user interface" [substituted for] "a Web page" [or "a page"], [the word "whole electronic document or software user interface" substituted for "whole page"], the word "the electronic document or software user interface" substituted for "the Web page", [and the word] "any part of an electronic document or software user interface" [substituted for] "any content".

Substitution in SC:

If any audio on [an electronic document or a software user interface] plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)

Note: Since [any part of an electronic document or software user interface] that does not meet this success criterion can interfere with a user's ability to use the [whole electronic document or software user interface], all content on [the electronic document or software user interface]  (whether or not it is used to meet other success criteria) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

Substitution in INTENT:

Individuals who use screen reading software can find it hard to hear the speech output if there is other audio playing at the same time. This difficulty is exacerbated when the screen reader's speech output is software based (as most are today) and is controlled via the same volume control as the sound. Therefore, it is important that the user be able to turn off the background sound. Note: Having control of the volume includes being able to reduce its volume to zero.

Note: Playing audio automatically when landing on [an electronic document or a software user interface] may affect a screen reader user's ability to find the mechanism to stop it because they navigate by listening and automatically started sounds might interfere with that navigation. Therefore, we discourage the practice of automatically starting sounds (especially if they last more than 3 seconds), and encourage that the sound be started by an action initiated by the user after they reach the page, rather than requiring that the sound be stopped by an action of the user after they land on the page.

LM: Some notes:
  • The agreed text already uses "software user interface" so there are initially no major changes in proposed text. BUT...
  • First, I have changed the heading of our guidance, as in all the other SC
  • Then I have tried to clearly state all the substitutions that are needed, because there is "a web page", "whole page", "a page" and "any content".
  • I have also used our "standard" words for substitutions.
  • I've also implemented all the substitutions in the column "agreed text" even if our current proposal doesn't say so explicitely.
  • Finally, there is a sentence about "landing on a page" that we may think needs substitution, but I haven't done it as I think that it requires discussion in our group... Maybe "rendering an electronic document or software user interface"...
1.4.3 Contrast (Minimum):

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

(see Introduction for how to interpret "content")
1.4.3 Contrast (Minimum):

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

(see Introduction for how to interpret "content")
LM: The only change here is the heading of the guidance. 
1.4.4 Resize text:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This success criterion applies directly as written and as described in intent from Understanding WCAG 2.0.

Electronic content and electronic documents that have software players, viewers or editors with a 200 percent zoom feature would automatically meet this SC unless the content or document will not work with zoom.

The INTENT refers to the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality or that the application works with the platform features that meets this requirement.
1.4.4 Resize text:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This success criterion applies directly as written and as described in intent from Understanding WCAG 2.0.

Electronic content and electronic documents that have software players, viewers or editors with a 200 percent zoom feature would automatically meet this SC unless the content or document will not work with zoom.

The INTENT refers to the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use assistive technologies. This means that the [software user interface] provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality or that the [software user interface] works with the platform features that [meet] this requirement.
LM: I've changed the heading of the guidance and I've replaced "application" by "software user interface" in the last paragraph, as I think that the paragraph applies to both applications and the user interface of platform software.

Maybe we could use "software that provides a user interface" to replace "application" here. But the TF has not discussed these alternative words.

I've also made an editorial change in the last sentence by writing "meet" instead of "meets".
1.4.5 Images of Text:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

(see Introduction for how to interpret "content")
1.4.5 Images of Text:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

(see Introduction for how to interpret "content")
LM: The only change here is the heading of the guidance.
1.4.6 *Contrast (Enhanced) [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
1.4.7 *Low or No Background Audio [L3]

LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
1.4.8 *Visual Presentation [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
1.4.9 *Images of Text (No Exception) [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
2.1.1 Keyboard:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

This does not imply that software must directly support a keyboard or "keyboard interface". NOR DOES IT IMPLY THAT SOFTWARE MUST PROVIDE A SOFT KEYBOARD. Underlying platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard and would comply.

(see Introduction for how to interpret "content")
2.1.1 Keyboard:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

This does not imply that [software products] must directly support a keyboard or "keyboard interface". NOR DOES IT IMPLY THAT [SOFTWARE PRODUCTS] MUST PROVIDE A SOFT KEYBOARD. Underlying platform software may provide device independent input services to applications that enable operation via a keyboard. [A software product] that supports operation via such platform device independent services would be operable by a keyboard and would comply.

(see Introduction for how to interpret "content")
LM: In this case there are two changes:
  • The heading
  • In the last paragraph I have used "software product" instead of "software" as I think it is better. We could also use "software user interface" here, but I think that "software product" fits better the text.
 
2.1.2 No Keyboard Trap:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above).

Note: Standard exit methods may vary by platform. For example, on many desktop platforms, the Escape key is a standard method for exiting.
2.1.2 No Keyboard Trap:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above).

Note: Standard exit methods may vary by platform. For example, on many desktop platforms, the Escape key is a standard method for exiting.
LM: The only change here is the heading of the guidance.
2.1.3 *Keyboard (No Exception) [L3]

LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
2.2.1 Timing Adjustable:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 above, replacing "content" with "interactive documents and software".

Substitution (SC):

Success Criteria 2.2.1:  For each time limit that is set by the [interactive documents and software], at least one of the following is true: (Level A)
  • Turn off: The user is allowed to turn off the time limit before encountering it; or
  • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
  • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
  • Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
  • Essential Exception: The time limit is essential and extending it would invalidate the activity; or
  • 20 Hour Exception: The time limit is longer than 20 hours.
Note: This success criterion helps ensure that users can complete tasks without unexpected changes in [interactive documents and software] or context that are a result of a time limit. This success criterion should be considered in conjunction with Success Criterion 3.2.1, which puts limits on changes of [interactive documents and software] or context as a result of user action.

Substitution (intent):

LM: Below I have highlighted terms that require substitutions (Web, Web funtions, and page).

The intent of this Success Criterion is to ensure that users with disabilities are given adequate time to interact with Web [interactive documents and software] whenever possible. People with disabilities such as blindness, low vision, dexterity impairments, and cognitive limitations may require more time to read [interactive documents and software] or to perform functions such as filling out on-line forms. If Web functions are time-dependent, it will be difficult for some users to perform the required action before a time limit occurs. This may render the service inaccessible to them. Designing functions that are not time-dependent will help people with disabilities succeed at completing these functions. Providing options to disable time limits, customize the length of time limits, or request more time before a time limit occurs helps those users who require more time than expected to successfully complete tasks. These options are listed in the order that will be most helpful for the user. Disabling time limits is better than customizing the length of time limits, which is better than requesting more time before a time limit occurs.

Any process that happens without user initiation after a set time or on a periodic basis is a time limit. This includes partial or full updates of [interactive documents and software] (for example, page refresh), changes to [interactive documents and software], or the expiration of a window of opportunity for a user to react to a request for input.

It also includes [interactive documents and software] that is advancing or updating at a rate beyond the user's ability to read and/or understand it. In other words, animated, moving or scrolling [interactive documents and software] introduces a time limit on a users ability to read [interactive documents and software].

In some cases, however, it is not possible to change the time limit (for example, for an auction or other real-time event) and exceptions are therefore provided for those cases.

Notes regarding server time limits
  • Timed server redirects can be found below under Common Failures.
  • Non-timed server redirects (e.g., 3xx response codes) are not applicable because there is no time limit: they work instantly.
  • This Success Criterion applies only to time limits that are set by the [interactive documents and software] itself. For example, if a time limit is included in order to address security concerns, it would be considered to have been set by the content because it is designed to be part of the presentation and interaction experience for that [interactive documents and software]. Time limits set externally to [interactive documents and software], such as by the user agent or by factors intrinsic to the Internet are not under the author's control and not subject to WCAG conformance requirements. Time limits set by Web servers should be under the author's/organization's control and are covered. (Success Criteria 2.2.3, 2.2.4 and 2.2.5 may also apply.)
  • Ten times the default was chosen based on clinical experience and other guidelines. For example, if 15 seconds is allowed for a user to respond and hit a switch, 150 seconds would be sufficient to allow almost all users to hit a switch even if they had trouble.
  • 20 seconds was also based on clinical experience and other guidelines. 20 seconds to hit 'any switch' is sufficient for almost all users including those with spasticity. Some would fail, but some would fail all lengths of time. A reasonable period for requesting more time is required since an arbitrarily long time can provide security risks to all users, including those with disabilities, for some applications. For example, with kiosks or terminals that are used for financial transactions, it is quite common for people to walk away without signing off. This leaves them vulnerable to those walking up behind them. Providing a long period of inactivity before asking, and then providing a long period for the person to indicate that they are present can leave terminals open for abuse. If there is no activity the system should ask if the user is there. It should then ask for an indication that a person is there ('hit any key') and then wait long enough for almost anyone to respond. For "hit any key," 20 seconds would meet this. If the person indicates that they are still present, the device should return the user to the exact condition that existed before it asked the question.
  • 20 hours was chosen as an upper limit because it is longer than a full waking day.

In cases where timing is not an intrinsic requirement but giving users control over timed events would invalidate the outcome, a third party can control the time limits for the user (for example, granting double time on a test).

See also Understanding Success Criterion 2.2.3 No Timing.
 2.2.1 Timing Adjustable:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 above, [with the word] ["an electronic document or software user interface"] [substituted for] "the content"[, the word "changes in context" substituted for "changes in content or context", the word "electronic documents or software user interfaces" substituted for "Web content", the word "functions" substituted for "Web functions", the word "presentation refresh" substituted for "page refresh"]

Substitution (SC):

Success Criteria 2.2.1:  For each time limit that is set by [an electronic document or software user interface], at least one of the following is true: (Level A)
  • Turn off: The user is allowed to turn off the time limit before encountering it; or
  • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
  • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
  • Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
  • Essential Exception: The time limit is essential and extending it would invalidate the activity; or
  • 20 Hour Exception: The time limit is longer than 20 hours.
Note: This success criterion helps ensure that users can complete tasks without unexpected [changes in context] that are a result of a time limit. This success criterion should be considered in conjunction with Success Criterion 3.2.1, which puts limits on [changes in context] as a result of user action.

Substitution (intent):

LM: below I have highlighted uses of "content".

The intent of this Success Criterion is to ensure that users with disabilities are given adequate time to interact with [electronic documents or software user interfaces] whenever possible. People with disabilities such as blindness, low vision, dexterity impairments, and cognitive limitations may require more time to read content or to perform functions such as filling out on-line forms. If [functions] are time-dependent, it will be difficult for some users to perform the required action before a time limit occurs. This may render the service inaccessible to them. Designing functions that are not time-dependent will help people with disabilities succeed at completing these functions. Providing options to disable time limits, customize the length of time limits, or request more time before a time limit occurs helps those users who require more time than expected to successfully complete tasks. These options are listed in the order that will be most helpful for the user. Disabling time limits is better than customizing the length of time limits, which is better than requesting more time before a time limit occurs.

Any process that happens without user initiation after a set time or on a periodic basis is a time limit. This includes partial or full updates of content (for example, [presentation refresh]), changes to content, or the expiration of a window of opportunity for a user to react to a request for input.

It also includes content that is advancing or updating at a rate beyond the user's ability to read and/or understand it. In other words, animated, moving or scrolling content introduces a time limit on a users ability to read content.

In some cases, however, it is not possible to change the time limit (for example, for an auction or other real-time event) and exceptions are therefore provided for those cases.

Notes regarding server time limits
  • Timed server redirects can be found below under Common Failures.
  • Non-timed server redirects (e.g., 3xx response codes) are not applicable because there is no time limit: they work instantly.
  • This Success Criterion applies only to time limits that are set by [an electronic document or software user interface] itself. For example, if a time limit is included in order to address security concerns, it would be considered to have been set by the content because it is designed to be part of the presentation and interaction experience for that content. Time limits set externally to content, such as by the user agent or by factors intrinsic to the Internet are not under the author's control and not subject to WCAG conformance requirements. Time limits set by Web servers should be under the author's/organization's control and are covered. (Success Criteria 2.2.3, 2.2.4 and 2.2.5 may also apply.)
  • Ten times the default was chosen based on clinical experience and other guidelines. For example, if 15 seconds is allowed for a user to respond and hit a switch, 150 seconds would be sufficient to allow almost all users to hit a switch even if they had trouble.
  • 20 seconds was also based on clinical experience and other guidelines. 20 seconds to hit 'any switch' is sufficient for almost all users including those with spasticity. Some would fail, but some would fail all lengths of time. A reasonable period for requesting more time is required since an arbitrarily long time can provide security risks to all users, including those with disabilities, for some applications. For example, with kiosks or terminals that are used for financial transactions, it is quite common for people to walk away without signing off. This leaves them vulnerable to those walking up behind them. Providing a long period of inactivity before asking, and then providing a long period for the person to indicate that they are present can leave terminals open for abuse. If there is no activity the system should ask if the user is there. It should then ask for an indication that a person is there ('hit any key') and then wait long enough for almost anyone to respond. For "hit any key," 20 seconds would meet this. If the person indicates that they are still present, the device should return the user to the exact condition that existed before it asked the question.
  • 20 hours was chosen as an upper limit because it is longer than a full waking day.

In cases where timing is not an intrinsic requirement but giving users control over timed events would invalidate the outcome, a third party can control the time limits for the user (for example, granting double time on a test).

See also Understanding Success Criterion 2.2.3 No Timing.
LM: This is a complex SC to deal because of the length of the SC and its INTENT.
  • There is a trouble with the suggested change, as "content" is also used in the last note of the SC. In addition, "Web content" is used in the INTENT.
  • So I've tried to make sure that the substitutions work.
  • I've also used "software user interface" instead of just "software."
  • In addition "content" is also used many times in the INTENT with no clear 1:1 substitution, except for replacing it with the agreed definition of "information and sensory experience to be communicated to the user by means of ICT" but I haven't included this in my proposals as it was out of scope of my action.

For the "content" issue we may reuse words from 1.3.2:

"In the INTENT, content is interpreted to mean "information and sensory experience to be communicated to the user by means of ICT"."

2.2.2 Pause, Stop, Hide:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above).








Note: While the success criteria uses the term "information", the WCAG 2.0 INTENT section makes it clear that this is to be applied to all content. Any content, whether informative or decorative, that IS UPDATED AUTOMATICALLY, BLINKS OR MOVES MAY CREATE AN ACCESSIBILITY BARRIER.
2.2.2 Pause, Stop, Hide:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above)[, with the word "an Electronic Document or Software User Interface" substituted for "a Web page" in the INTENT, with the word "the Electronic Document or Software User Interface" substituted for "the Web page", with the word "the Electronic Document or Software User Interface" substituted for "the page" ]

Note: While the success criteria uses the term "information", the WCAG 2.0 INTENT section makes it clear that this is to be applied to all content. Any content, whether informative or decorative, that IS UPDATED AUTOMATICALLY, BLINKS OR MOVES MAY CREATE AN ACCESSIBILITY BARRIER.

Substitution in SC (none)

Substitutions in INTENT

The intent of this Success Criterion is to avoid distracting users during their interaction with [an Electronic Document or Software User Interface].

"Moving, blinking and scrolling" refers to content in which the visible content conveys a sense of motion. Common examples include motion pictures, synchronized media presentations, animations, real-time games, and scrolling stock tickers. "Auto-updating" refers to content that updates or disappears based on a preset time interval. Common time-based content includes audio, automatically updated weather information, news, stock price updates, and auto-advancing presentations and messages. The requirements for moving, blinking and scrolling content and for auto-updating content are the same except that:
  • authors have the option of providing the user with a means to control the frequency of updates when content is auto-updating and
  • there is no three second exception for auto-updating since it makes little sense to auto-update for just three seconds and then stop
Content that moves or auto-updates can be a barrier to anyone who has trouble reading stationary text quickly as well as anyone who has trouble tracking moving objects. It can also cause problems for screen readers.

Moving content can also be a severe distraction for some people. Certain groups, particularly those with attention deficit disorders, find blinking content distracting, making it difficult for them to concentrate on other parts of [the Electronic Document or Software User Interface]. Five seconds was chosen because it is long enough to get a user's attention, but not so long that a user cannot wait out the distraction if necessary to use [the Electronic Document or Software User Interface].

Content that is paused can either resume in real-time or continue playing from the point in the presentation where the user left off.

1. Pausing and resuming where the user left off is best for users who want to pause to read content and works best when the content is not associated with a real-time event or status.

    Note: See Understanding Success Criterion 2.2.1 Timing Adjustable for additional requirements related to time-limits for reading.

2. Pausing and jumping to current display (when pause is released) is better for information that is real-time or "status" in nature. For example, weather radar, a stock ticker, a traffic camera, or an auction timer, would present misleading information if a pause caused it to display old information when the content was restarted.

    Note: Hiding content would have the same result as pausing and jumping to current display (when pause is released).

For a mechanism to be considered "a mechanism for the user to pause," it must provide the user with a means to pause that does not tie up the user or the focus so that [the Electronic Document or Software User Interface] cannot be used. The word "pause" here is meant in the sense of a "pause button" although other mechanisms than a button can be used. Having an animation stop only so long as a user has focus on it (where it restarts as soon as the user moves the focus away) would not be considered a "mechanism for the user to pause" because it makes [the Electronic Document or Software User Interface] unusable in the process and would not meet this SC.

It is important to note that the terms "blinking" and "flashing" can sometimes refer to the same content.
  • "Blinking" refers to content that causes a distraction problem. Blinking can be allowed for a short time as long as it stops (or can be stopped)
  • "Flashing" refers to content that can trigger a seizure (if it is more than 3 per second and large and bright enough). This cannot be allowed even for a second or it could cause a seizure. And turning the flash off is also not an option since the seizure could occur faster than most users could turn it off.
  • Blinking usually does not occur at speeds of 3 per second or more, but it can. If blinking occurs faster than 3 per second, it would also be considered a flash.
LM: First, there is the change in the heading of the guidance. Then we need proper substitution for "web page" in the intent (not in the SC).

In the INTENT there is "a Web page", "the Web page" and "page". We need replacements for those.

NOTE: there are many instances of "content" in the INTENT. We will probably need a note explaining how "content" is understood outside of the web domain. For instance (taken from 1.3.2):

"In the INTENT, content is interpreted to mean "information and sensory experience to be communicated to the user by means of ICT"."

2.2.3 *No Timing [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
2.2.4 *Interruptions [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
2.2.5 *Re-authenticating [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
2.3.1 Three Flashes or Below Threshold:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 above, replacing "web page" with "electronic documents and software".







Substitutions in SC:

Success Criteria 2.3.1: [Electronic documents and software] do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. (Level A)

Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole [Electronic documents and software], all content on the [Electronic document and software] (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

2.3.1 Three Flashes or Below Threshold:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 above, [with "Electronic documents and software user interfaces" substituted for "Web pages", with "the whole electronic document or software user interface" substituted for "the whole page" and "the electronic document or software user interface" substituted for "the Web page"].

Substitutions in SC:

Success Criteria 2.3.1: [Electronic documents and software user interfaces] do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. (Level A)

Note: Since any content that does not meet this success criterion can interfere with a user's ability to use [the whole electronic document or software user interface], all content on [the electronic document or software user interface] (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
LM: This time there is no "page" in the INTENT, so changes are easier. However there are different uses of page in the SC that need substitution: "Web pages", "the Web page", "the whole page"
2.3.2 *Three Flashes [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
2.4.1 Bypass Blocks:

(There is no agreed text. For the exercise I put below the latest proposal #6)

Additional guidance when applying to Electronic Documents  and Software Aspects of Products

For documents, this applies directly as written and as described in  INTENT  from Understanding WCAG 2.0  (above) with the word “document” substituted for Web Page  and "set of documents published as a single entity" substituted for "set of web pages".

For software this applies directly as written and as described in  INTENT  from Understanding WCAG 2.0  (above) with the word “user interface context” substituted for Web Page  and "software program" substituted for "set of web pages".

Notes: 

  1. For some non-windowing products, there is only ever one "window" or "screen" visible at a time and it would be the 'user interface context'.
  2. As with WCAG, changing a major portion of the user interface elements or information presented would constitute a "change of context".  So an application window that has very different content at different times would constitute a new 'context' for each instance and blocks of material that appear on each instance (each context) would be considered repeated.
  3. In the case of software user interfaces, it is common in that structure of the program allows the user to easily skip skip over these repeated blocks of user interface elements (e.g.  menu bars and ribbons) and meet this success criterion without any special considerations by the author being made other than good, structured, interface design.
  4. When these blocks are at the top of a page, focus is often placed below them in the main content area.   Specific keystroke or other commands are then commonly employed to bring the user interaction back to the items in the block above when they are needed. 
2.4.1 Bypass Blocks:

(There is no agreed text. For the exercise I put below the latest proposal #6)

Additional guidance when applying to Electronic Documents  and [Software User Interfaces]

For documents, this applies directly as written and as described in  INTENT  from Understanding WCAG 2.0  (above) with the word “document” substituted for Web Page  and "set of documents published as a single entity" substituted for "set of web pages".

For [software user interfaces] this applies directly as written and as described in  INTENT  from Understanding WCAG 2.0  (above) with the word “user interface context” substituted for Web Page  and "[software product]" substituted for "set of web pages".

Notes: 

  1. For some non-windowing products, there is only ever one "window" or "screen" visible at a time and it would be the 'user interface context'.
  2. As with WCAG, changing a major portion of the user interface elements or information presented would constitute a "change of context".  So an application window that has very different content at different times would constitute a new 'context' for each instance and blocks of material that appear on each instance (each context) would be considered repeated.
  3. In the case of software user interfaces, it is common in that structure of the program allows the user to easily skip skip over these repeated blocks of user interface elements (e.g.  menu bars and ribbons) and meet this success criterion without any special considerations by the author being made other than good, structured, interface design.
  4. When these blocks are at the top of a page, focus is often placed below them in the main content area.  Specific keystroke or other commands are then commonly employed to bring the user interaction back to the items in the block above when they are needed. 
 LM: Issues:
  • I've changed the heading
  • I've replaced "software" by "software user interfaces"
  • I've replaced "software program" by "software product"
  • I've marked an editorial change "it is common in that...." to become "it is common that..."
  • I haven't done the substitutions because this SC is not yet agreed.
2.4.2 Page Titled:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

For electronic documents this applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing "Web pages" with “electronic documents”.

Note: An electronic document's filename, as well as its title attribute, are both considered types of titles. While the filename is more universally presented by assistive technologies, the title attribute is more formally correct. Using both provides the best chance of being accessible to different users.

For software user interfaces, the precise analog to "Web page" in the context of this success criterion is difficult to define. However, since there is almost always a single user interface component associated with top-most explicit groupings of user interface component (things like "windows", "dialog boxes", "frames", and "screens"), and since 4.1.2 requires that every user interface component has a programmatically determined name, conforming to 4.1.2 would thereby mean that this success criterion was met if the name for the user interface component associated with top-most explicit groupings of user interface component described its topic or purpose. If the names of all explicit groupings of user interface component are descriptive of the title or purpose, it will certainly be the case that all of the top-most ones are.

Note: Where the accessibility services of the platform include a description attribute in addition to a name attribute, the description attribute and the name attribute are often used together to provide both a short cue and longer description of the topic or purpose.

2.4.2 Page Titled:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

For electronic documents this applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing "Web pages" with “electronic documents”.

Note: An electronic document's filename, as well as its title attribute, are both considered types of titles. While the filename is more universally presented by assistive technologies, the title attribute is more formally correct. Using both provides the best chance of being accessible to different users.

For software user interfaces, the precise analog to "Web page" in the context of this success criterion is difficult to define. However, since there is almost always a single user interface [element] associated with top-most explicit groupings of user interface [elements] (things like "windows", "dialog boxes", "frames", and "screens"), and since 4.1.2 requires that every user interface [element] has a programmatically determined name, conforming to 4.1.2 would thereby mean that this success criterion was met if the name for the user interface [element] associated with top-most explicit groupings of user interface [elements] described its topic or purpose. If the names of all explicit groupings of user interface [elements] are descriptive of the title or purpose, it will certainly be the case that all of the top-most ones are.

Note: Where the accessibility services of the platform include a description attribute in addition to a name attribute, the description attribute and the name attribute are often used together to provide both a short cue and longer description of the topic or purpose.
 LM:
  • I've changed the heading
  • I've used "user interface element" instead of "user interface component". I think that we agreed on that change buy I can be wrong on that.
2.4.3 Focus Order:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above)  replacing "a Web page" with "an electronic document or a software user interface".

Note that the INTENT for Success Criterion 2.4.3  in Understanding WCAG 2.0 makes it clear that:
  1. focusable components need to receive focus in an order that preserves meaning and operability only when navigation sequences affect meaning and operability.
  2. in those cases where it is required, there may be more than one order that will preserve meaning and operability
  3. if there is more than one order that preserves meaning and operability, only one of them needs to be provided.
2.4.3 Focus Order:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above)  replacing "a Web page" with "an electronic document or a software user interface".

Note that the INTENT for Success Criterion 2.4.3 in Understanding WCAG 2.0 makes it clear that:
  1. focusable components need to receive focus in an order that preserves meaning and operability only when navigation sequences affect meaning and operability.
  2. in those cases where it is required, there may be more than one order that will preserve meaning and operability
  3. if there is more than one order that preserves meaning and operability, only one of them needs to be provided.
LM: I have only changed the heading of the guidance as this is one of the first SC where we agreed to use "software user interfaces"
2.4.4 Link Purpose (In Context):

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written and as described in INTENT from Understanding WCAG 2.0 (above), replacing "Web page" with "electronic documents and software" in the INTENT. In software, a "link" is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)


Substitutions in SC (none)

Substitutions in INTENT:

The substitutions don't seem to work. And there are parts with "page" instead of "Web page".

The intent of this Success Criterion is to help users understand the purpose of each link so they can decide whether they want to follow the link. Whenever possible, provide link text that identifies the purpose of the link without needing additional context. Assistive technology has the ability to provide users with a list of links that are on the [electronic documents and software]. Link text that is as meaningful as possible will aid users who want to choose from this list of links. Meaningful link text also helps those who wish to tab from link to link. Meaningful links help users choose which links to follow without requiring complicated strategies to understand the page.

In some situations, authors may want to provide part of the description of the link in logically related text that provides the context for the link. In this case the user should be able to identify the purpose of the link without moving focus from the link. In other words, they can arrive on a link and find out more about it without losing their place. This can be achieved by putting the description of the link in the same sentence, paragraph, list item, the heading immediately preceding the link, or table cell as the link, or in the table header cell for a link in a data table, because these are directly associated with the link itself.

This context will be most usable if it precedes the link. (For instance, if you must use ambiguous link text, it is better to put it at the end of the sentence that describes its destination, rather than putting the ambiguous phrase at the beginning of the sentence.) If the description follows the link, there can be confusion and difficulty for screen reader users who are reading through the page in order (top to bottom).

Links with the same destination should have the same descriptions (per Success Criterion 3.2.4), but links with different purposes and destinations should have different descriptions.

The Success Criterion includes an exception for links for which the purpose of the link cannot be determined from the information on the [electronic documents and software]. In this situation, the person with the disability is not at a disadvantage; there is no additional context available to understand the link purpose. However, whatever amount of context is available on the [electronic documents and software] that can be used to interpret the purpose of the link must be made available in the link text or programmatically associated with the link to satisfy the Success Criterion.

Note: There may be situations where the purpose of the link is is supposed to be unknown or obscured. For instance, a game may have links identified only as door #1, door #2, and door #3. This link text would be sufficient because the purpose of the links is to create suspense for all users.

See also Understanding Success Criterion 2.4.9 Link Purpose (Link Only).
2.4.4 Link Purpose (In Context):

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written and as described in INTENT from Understanding WCAG 2.0 (above), [with the word "an electronic document or a software user interface" substituted for "the Web page" or "the page"]. In [a software user interface], a "link" is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)

Substitutions in SC (none)

Substitutions in INTENT:

The intent of this Success Criterion is to help users understand the purpose of each link so they can decide whether they want to follow the link. Whenever possible, provide link text that identifies the purpose of the link without needing additional context. Assistive technology has the ability to provide users with a list of links that are on [an electronic document or a software user interface]. Link text that is as meaningful as possible will aid users who want to choose from this list of links. Meaningful link text also helps those who wish to tab from link to link. Meaningful links help users choose which links to follow without requiring complicated strategies to understand [an electronic document or a software user interface].

In some situations, authors may want to provide part of the description of the link in logically related text that provides the context for the link. In this case the user should be able to identify the purpose of the link without moving focus from the link. In other words, they can arrive on a link and find out more about it without losing their place. This can be achieved by putting the description of the link in the same sentence, paragraph, list item, the heading immediately preceding the link, or table cell as the link, or in the table header cell for a link in a data table, because these are directly associated with the link itself.

This context will be most usable if it precedes the link. (For instance, if you must use ambiguous link text, it is better to put it at the end of the sentence that describes its destination, rather than putting the ambiguous phrase at the beginning of the sentence.) If the description follows the link, there can be confusion and difficulty for screen reader users who are reading through [an electronic document or a software user interface] in order (top to bottom).

Links with the same destination should have the same descriptions (per Success Criterion 3.2.4), but links with different purposes and destinations should have different descriptions.

The Success Criterion includes an exception for links for which the purpose of the link cannot be determined from the information on [an electronic document or a software user interface]. In this situation, the person with the disability is not at a disadvantage; there is no additional context available to understand the link purpose. However, whatever amount of context is available on [an electronic document or a software user interface] that can be used to interpret the purpose of the link must be made available in the link text or programmatically associated with the link to satisfy the Success Criterion.

Note: There may be situations where the purpose of the link is is supposed to be unknown or obscured. For instance, a game may have links identified only as door #1, door #2, and door #3. This link text would be sufficient because the purpose of the links is to create suspense for all users.

See also Understanding Success Criterion 2.4.9 Link Purpose (Link Only).
LM:
  • I've changed the heading and I have modified the substitutions to try to make them work properly.
  • I have also used our standard "substituted for" words.
  • Finally, I have replaced "software" by "software user interface" in the second paragraph.
2.4.5 Multiple Ways:

(There is no agreed text. For the exercise I put below the latest proposal #4)

Additional guidance when applying to Electronic Documents and Software Aspects of Products

For documents, this applies directly as written and as described in  INTENT  from Understanding WCAG 2.0  (above) with the word “document” substituted for Web Page  and "set of documents published as a single entity" substituted for "set of web pages".

For software this applies directly as written and as described in  INTENT  from Understanding WCAG 2.0  (above) with the word “user interface context” substituted for Web Page  and "software program" substituted for "set of web pages".

NOTE:  In the Understanding WCAG 2.0 writeup for this success criterion the WCAG Working Group gives examples of browsing and search as two possible methods for locating a Web page within a set of Web pages.  Both of these approaches would appear to be supported by most Electronic Documents,  and browsing and searching of help functions would appear to allow locating major sections in software as well.

Note: Modal dialog boxes by their nature are considered part of a process that you can not navigate away from and must completed or cancelled before continuing.
2.4.5 Multiple Ways:

(There is no agreed text. For the exercise I put below the latest proposal #4)

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

For documents, this applies directly as written and as described in  INTENT  from Understanding WCAG 2.0  (above) with the word “document” substituted for Web Page  and "set of documents published as a single entity" substituted for "set of web pages".

For software this applies directly as written and as described in  INTENT from Understanding WCAG 2.0  (above) with the word “user interface context” substituted for Web Page  and "[software product]" substituted for "set of web pages".

NOTE:  In the Understanding WCAG 2.0 writeup for this success criterion the WCAG Working Group gives examples of browsing and search as two possible methods for locating a Web page within a set of Web pages.  Both of these approaches would appear to be supported by most Electronic Documents,  and browsing and searching of help functions would appear to allow locating major sections in [software user interfaces] as well.

Note: Modal dialog boxes by their nature are considered part of a process that you can not navigate away from and must completed or cancelled before continuing.
LM:
  • I've changed the heading
  • I've replaced "software program" by "software product" as in 2.4.1
  • I haven't done the substitutions because this SC is not yet agreed.
2.4.6 Headings and Labels:

Note that this text may change based on WCAG-WG comments

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

Note that in software user interfaces, labels include those static text components that label associated editable text fields (e.g. the static text component "Name:" to the left of an empty edit text field waiting for user input), and headings include those static text components connected to a group of related radio buttons or other groups of related user interface components (e.g. the static text component "Choose a color:" above the radio buttons "Red", "Green", and "Blue).  Platform accessibility services commonly provide a way to link labels to the user interface component(s) they are labeling, and to link headings to the group(s) of user interface components they are headings for.

(see Introduction for how to interpret "content")
2.4.6 Headings and Labels:

Note that this text may change based on WCAG-WG comments

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0 (above).

Note that in software user interfaces, labels include those static text components that label associated editable text fields (e.g. the static text component "Name:" to the left of an empty edit text field waiting for user input), and headings include those static text components connected to a group of related radio buttons or other groups of related user interface components (e.g. the static text component "Choose a color:" above the radio buttons "Red", "Green", and "Blue).  Platform accessibility services commonly provide a way to link labels to the user interface component(s) they are labeling, and to link headings to the group(s) of user interface components they are headings for.

(see Introduction for how to interpret "content")
LM: I've just changed the heading. This SC is to be revisited if we change the example of headings to take into account comments by WCAG-WG.
2.4.7 Focus Visible:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

(see Introduction for how to interpret "content")
2.4.7 Focus Visible:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

(see Introduction for how to interpret "content")
LM: I've only changed the heading.
2.4.8 * Location [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
2.4.9 *Link Purpose (Link Only) [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
3.1.1 Language of Page:

(There is no agreed text. For the exercise I put below the latest proposal #4)

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0  (above) with "document or user interface context" substituted for "Web Page".

Note that some document formats can use separate human languages for output and input purposes. In such cases both languages should be programmatically determinable.

For 
software, there are some platforms and software types where there is no assistive technology supported method for marking the language for the different "user interface contexts" or for marking that the application doesn’t match the “local” language, as marked in the platform, and it would not be possible to meet this success criterion with those platforms or software types.

NOTE: Inheritance is one common method.  For example a document or application provides the language that it is using and it can be assumed that all user interface contexts within that document or application will be using the same language unless it is indicated.

3.1.1 Language of Page:

(There is no agreed text. For the exercise I put below the latest proposal #4)

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0  (above) with "document or user interface context" substituted for "Web Page".

Note that some document formats can use separate human languages for output and input purposes. In such cases both languages should be programmatically determinable.

For [software user interfaces], there are some platforms and software types where there is no assistive technology supported method for marking the language for the different "user interface contexts" or for marking that the application doesn’t match the “local” language, as marked in the platform, and it would not be possible to meet this success criterion with those platforms or software types.

NOTE: Inheritance is one common method.  For example a document or application provides the language that it is using and it can be assumed that all user interface contexts within that document
or application will be using the same language unless it is indicated.
LM:
  • I've changed the heading
  • I've replaced "software" by "software user interface" in the third paragraph
  • I haven't done the substitutions because this SC is not yet agreed.
     
3.1.2 Language of Parts:

(There is no agreed text. For the exercise I put below the latest proposal #1REVISED)

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above) with the word “document” substituted for "content".

Documents created with document formats that do not support tagging language for parts of the document (where the language changes) – would not be able to meet this SC.

With software, this is unlikely to occur. It is much more common in text.   But if software did include foreign language words or phrases there are few programming environments today that allow tagging of those phrases to mark their language.  If the words were not covered in the exceptions, and the programming language/environment did not allow a programmatic way to indicate the language, then it would not be possible for that software to meet this success criterion given the language recognizing abilities of todays Assistive technologies.   This may change in the future however."
3.1.2 Language of Parts:

(There is no agreed text. For the exercise I put below the latest proposal #1REVISED)

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above) with the word [“an electronic document or a software user interface”] substituted for "the content".

Documents created with document formats that do not support tagging language for parts of the document (where the language changes) – would not be able to meet this SC.

With [software user interfaces], this is unlikely to occur. It is much more common in text.   But if [a software user interface] did include foreign language words or phrases there are few programming environments today that allow tagging of those phrases to mark their language.  If the words were not covered in the exceptions, and the programming language/environment did not allow a programmatic way to indicate the language, then it would not be possible for that software to meet this success criterion given the language recognizing abilities of today's assistive technologies.   This may change in the future however." 
LM:
  • I've changed the heading
  • I think that the substitution is incomplete as only "document" is proposed here. I have replaced it by "an electronic document or a software user interface".
  • I've replaced "software" by "software user interface" in that last paragraph.
  • I haven't done the substitutions because this SC is not yet agreed.
3.1.3 *Unusual Words [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
3.1.4 *Abbreviations [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
3.1.5 *Reading Level [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
3.1.6 *Pronunciation [L3]   LM: This is a AAA SC and we haven't dealt with it yet. I have included it in the table for completeness to create a "placeholder".
3.2.1 On Focus:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

(see Introduction for how to interpret "content")
3.2.1 On Focus:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

(see Introduction for how to interpret "content")
LM: I have changed the heading.
3.2.2 On Input:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

(see Introduction for how to interpret "content")
3.2.2 On Input:

Additional guidance when applying to Electronic Documents and [Software User Interfaces]

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above).

(see Introduction for how to interpret "content")
LM: I have changed the heading.
3.2.3 Consistent Navigation:

Additional guidance when applying to Electronic Documents and Software Aspects of Products

The WCAG2ICT Task Force has not yet produced additional guidance for Success Criterion 3.2.3.

 
 DM: First line of 3.2.3 understanding
 
 
I think the Trace proposal works and is not affected by the slight change in title.
3.2.4 Consistent Identification
Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing "a set of Web pages" with "an electronic document or a software user interface".

 
Additional guidance when applying to Electronic Documents and [Software User Interfaces]

3.2.4 Consistent Identification: Components that have the same functionality within a set of are identified consistently. (Level AA)    
 
 3.2.5 Change on Request (Level AAA):




 
 

 3.3.1 Error Identification (Level A):
Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above).

 Additional guidance when applying to Electronic Documents and [Software User Interfaces]  
 3.3.2 Labels or Instructions (Level A):
Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above)

 Additional guidance when applying to Electronic Documents and [Software User Interfaces]  
 3.3.3 Error Suggestion (Level AA):
Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above)

 Additional guidance when applying to Electronic Documents and [Software User Interfaces]  
 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA):
Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) 

 Additional guidance when applying to Electronic Documents and [Software User Interfaces]  
3.3.5 Help (Level AAA):



 The WCAG2ICT Task Force has not yet reviewed Level AAA Success Criteria 
3.3.6 Error Prevention (All) (Level AAA):



  The WCAG2ICT Task Force has not yet reviewed Level AAA Success Criteria 



4.1.1 Parsing (Level A):
Additional guidance when applying to Electronic Documents and Software Aspects of Products

The WCAG2ICT Task Force has not yet produced additional guidance for Success Criterion 4.1.1.
 Additional guidance when applying to Electronic Documents and [Software User Interfaces]  
4.1.2 Name, Role, Value (Level A):
Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above).

For conforming to this success criterion, it is usually best practice for software user interfaces to use the accessibility services provided by platform software. These accessibility services enable interoperability between software user interfaces and assistive technologies in standardised ways. Most platform accessibility services go beyond programmatic exposure of name and role, and programmatic setting of states, properties and values (and notification of same), and specify additional information that could or should be exposed and/or set (for instance, a list of the available actions for a given user interface component, and a means to programmatically execute one of the listed actions).



 Additional guidance when applying to Electronic Documents and [Software User Interfaces]  

   

   

   

   

   
<empty row for facilitating editing>
 

Comments