Change on request

[lseeman]

##Current versions of SC and Definitions

• SC for viewing | SC for editing
• Easily Available definition for viewing | Easily Available definition for editing
• User Action definition for viewing | User Action definition for editing
  SC in full draft guideline

Change on Request

Current:

3.2.5 Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes. (Level AAA)

Proposed:

@@3.2.5 Change on Request: Changes of context, functionality, settings, route and orientation are initiated only by user request or an easily available mechanism is available to turn off such changes. An easily available mechanism is also available to go to previous context, functionality, settings, route and orientation. Exception: The changes are part of an activity where it is essential (e.g. a game)@@

Suggestion for Priority Level:

AA

Related Glossary

route: Directions and flow such as a GPS route

orientation: perspective or view such as map direction

easily available (or easily available mode or setting): one or more of the follwing is true:

• can be set one time with as a wide a scope as possible (such as using the standards of the OS, From ISO 9241-112 or GPII when available);
• with the option to save or to change the setting, were available interoperably, but also for the scope of the set of web pages;
• is reachable from each screen where it may be needed, and the path and the control conforms to all of this document.

• can be set one time with as wide a scope as possible (such as using the standards of the OS, ETSI or GPII when available); and
• with the option to save or to change the setting, were available interoperably, but also for the scope of the set of Web pages; and
• is reachable from each screen where it may be needed, and the path and the control conforms to all of the document.

What Principle and Guideline the SC falls within.

Principle 3, Guideline 3.2 - Predictable
Update to 3.2.5

Description

Any content, settings or functionality which changes unexpectedly, without user initiation can result in significant barriers for users with cognitive disabilities. Unexpected changes in any of these areas can result in loss of focus, anxiety, or confusion in understanding or using a user interface. Examples include but are not limited to:

• Automatic launching of new windows or pop-ups
• Submission of forms through mechanisms other than a button that is clearly labeled using simple language to submit the form
• Rerouting automatically by a GPS
• Changing the direction of a map in a GPS

For example, a user may not have a sense of direction or know their left and right. Before using a GPS they may study the route so that they know approximately what they are doing and can augment the directions of the GPS with their own context, using the GPS for cues. The GPS automatically reroutes them because of a small traffic delay. They become completely lost and disorientated and can no longer use the application.

Benefits

This Success Criterion give users with cognitive disabilities more control over how Websites and applications behave and display information giving them the opportunity to make choices that enable them to use the content and complete the task.

Initiating changes only when requested by a user is particularly helpful for:

• Focus and attention related disabilities
• Users with weak orientation
• Users with low executive function
• Memory related disabilities
• Users with anxiety disorders

See:

• Distractions issue paper
• Gap analysis
• User needs Tables 2 and 9 as well as tables 4 and 5
• Background research document
• Semantics for adaptive interfaces
• Script for personalization and Example for personalization
• Techniques
• Personalization and Preferences

Related Resources

Resources are for information purposes only, no endorsement implied.

• User research article
• Cognitive Disabilities and the Web: Where Accessibility and Usability Meet? - NCDAE
• Cognitive Disabilities - Design Considerations - WebAIM

Testability

For all content

Step 1: Identify any automatic changes in context, functionality, settings, route and orientation (using a similar way to how we identify changes in context now)

Step 2: Confirm there is an easy way for the user to suppress any changes from step 1

Step 3: Confirm an easy to use mechanism is available to go to the previous context, functionality, settings, route and orientation from Step 1.

 

Content specific examples

For slide shows, audio or video, confirm that:

• Content does not autoplay or
• A mechanism for stopping or pausing is present

For intermittent content updates such as news feeds or embedded social media updates, confirm that:

• A mechanism for pausing an update is present
• A roll back is present

Techniques

• Providing warning for any of the changes in context and allowing the user to prevent the change if required. The warning allows sufficient time for the user to process the warning and react.
• Providing a "pause" button for sideshows, video and audio
• Providing a "request update" and "pause update" button for news feeds or embedded social media updates
• Setting the autoplay attribute on an embedded YouTube video to "0"
• Using semantics and personalization to control changes
• Allowing a user to turn off reroutes
• Allowing a user to turn off changes in orientation

Working groups notes

[mapluke]

I think that there are three major issues to resolve here:

• the aim should be to keep the core of 3.2.5 as it is in WCAG 2.0 and look to create a new SC to require the mechanism to turn off changes to be "easily available";
• the addition of an exception like that shown must be the primary justification to elevate 3.2.5 from AAA to AA;
• can "functionality, settings, route and orientation" all be considered to be part of "context". In my view they probably can, in which case they do not need to be added to the SC - but might be candidates to be added in a note. Certainly "route and orientation" are concepts that are far too navigation specific to be included in an SC that is supposed to be generally applicable.

I think that the exception could be expanded to read:

• Exception: The changes are part of an activity where it is essential (e.g. a game) or where it can be shown to actively benefit some users (e.g. single-switch users rely on context changes that are animated by the system, and the preferences of low-vision users may vary depending on how much of the content they can see at once and how much of the session structure they can retain in working memory).

The addition about where it actively benefits some users directly copies what is said in the "Intent" part of Understanding WCAG 2.0 and may have been part of the rationale for why 3.2.5 was AAA and not AA.

[lseeman]

Hi Mike,
There is no problem including specifics in the SC. It makes it more clear.
We can say "context including functionality, settings, route and orientation" if you prefer, but if we take out orientation and rout people will have to read the blurb to understand that it is included. The more people can know what needs to be done by just reading the SC the better

[mapluke]

@lseeman
SCs are supposed to be widely applicable and meaningful in all contexts. In a context where personalization is supported, mentioning "settings" will make things "more clear". In navigation-related contexts, mentioning "route and orientation" will also make things "more clear". However in contexts where personalization is not supported or where the context is not navigation-related, people trying to understand the scope of the SC will struggle to understand how they are supposed to interpret these terms. WCAG frequently uses notes to provide context-specific clarifications of broad and abstract terms such as, in this case, "context".

[lseeman]

I think it is meaningful in many situations, we can add glossary definitions of route and orientation if that helps. I think these use cases are so important that it is worth the extra word.
lets have a call to discuss if you still have an issue with it

[joshueoconnor]

@mapluke is there a PR ready for this, or do you need more time?

[mapluke]

@joshueoconnor This could be a new SC "Change on request (reversible)". The elevation to a AA can be justified by the inclusion of an Exception:

Exception: The changes are part of an activity where it is essential (e.g. a game) or where the changes can be shown to actively benefit some users (e.g. single-switch users rely on context changes that are animated by the system, and the preferences of low-vision users may vary depending on how much of the content they can see at once and how much of the session structure they can retain in working memory).

So has so far there have only been two contributing members (Lisa and myself) and we disagree on an important part of the text:

• I believe that it is a (potentially approval destroying) mistake to change "Changes of context" (from 3.2.5) to "Changes of context, functionality, settings, route and orientation" as these four additions are all very specific to different types of application domain and do not belong in an SC that must be universally applicable. I believe that Lisa's desire to emphasize these four aspects should be highlighted in a note that explains that these are all part of context.

Would it be best to ask the list whether they think that these additions should be in the SC or in a note, as a way to resolve this fundamental disagreement?

[mapluke]

Proposed new SC:

• Change on Request: Changes of context are initiated only by user request or an easily available mechanism is available to turn off such changes. An easily available mechanism is also available to go to the previous context.
• Exception: The changes of context are part of an activity where it is essential (e.g. a game) or where the changes can be shown to actively benefit some users (e.g. single-switch users rely on context changes that are animated by the system, and the preferences of low-vision users may vary depending on how much of the content they can see at once and how much of the session structure they can retain in working memory).
• Example: Changes of functionality, settings, route and orientation are all important examples of changes of context.

Glossary entry:
easily available (or easily available mode or setting): one or more of the following is true:

• can be set one time with as a wide a scope as possible (such as using the standards of the OS, From ISO 9241-112 or GPII when available);
• with the option to save or to change the setting, where available interoperably, but also for the scope of the set of web pages;
• is reachable from each screen where it may be needed, and the path and the control conforms to all of this document;
• can be set one time with as wide a scope as possible (such as using the standards of the OS, ETSI or GPII when available); and;
• with the option to save or to change the setting, were available interoperably, but also for the scope of the set of Web pages; and;
• is reachable from each screen where it may be needed, and the path and the control conforms to all of the document.

[mapluke]

Slight amendment to the above, I think that the entry labelled as "Example" should probably be labelled "Note" as none of the WCAG 2.0 SC's contain "examples" (these only appear in the glossary).

[mapluke]

An alternative, much simpler, probably more robust (but slightly more limited) version of the easily available glossary entry is:
easily available (or easily available mode or setting): can be accessed in all contexts by one user action
user action: the intentional interaction taken by the user to manipulate the content of the page.

[mapluke]

Proposed new SC:

Final proposal:
Change on Request: Changes of context are initiated only by user request or an easily available mechanism is available to turn off such changes. An easily available mechanism is also available to go to the previous context.
Exception: The changes of context are part of an activity where it is essential (e.g. a game) or where the changes can be shown to actively benefit some users (e.g. single-switch users rely on context changes that are animated by the system, and the preferences of low-vision users may vary depending on how much of the content they can see at once and how much of the session structure they can retain in working memory).
Note: Changes of functionality, settings, route and orientation are all important examples of changes of context.

Glossary entries:
easily available (or easily available mode or setting): can be accessed in all contexts by one user action
user action: the intentional interaction taken by the user to manipulate the content of the page.