task completion

[lseeman]

Current versions of SC and Definitions

• SC for viewing | SC for editing
• SC in full draft guideline

SC Shortname

Task completion

SC Text

Task completion: Successfully completing tasks does not rely on users memorizing information presented in the current, or previous, user-interaction dialog steps. Note that the following requirements must apply: understandable language; clear structure and relationships; and clear and unambiguous separation of menu items, which must be level A in this scope. (This may be addressed by reiterating these requirements here to increase conformance.) Exception: This success criterion does not apply if memorizing, or otherwise mentally processing information, is the primary purpose of the dialog step (e.g., a step in a game which deliberately tests the player's memory skills).

Suggestion for Priority Level (A/AA/AAA)

A

Related Glossary additions or changes

NA

What Principle and Guideline the SC falls within.

Principle 2 : Operable Guidleline 2.4 Provide ways to help users navigate, find content, and determine where they are. (It can also be under

• 3.3 Help users avoid and correct mistakes.

Description

In multi-step user-interaction dialogs, such as voice-menu systems, there is a risk that users will encounter a barrier, which prevents them from completing a step, and as a result, which prevents them from achieving whatever they wished to achieve. Unlike visually-presented menus, which can be examined at the user’s leisure, the options in a voice menu are presented serially. They often have to be held in working memory until a user is able to decide which of the options best meets their goals. The intent of this success criterion is to make these systems useable for people with low working memory.

Benefits

Without this SC, many people cannot use an application at all. See Voice Menu Systems issue paper for a full description of this issue; and how it stops many people from using services that are often critical. Many people cannot make doctors' appointments, etc. by themselves, get their water turned back on, etc.. This may be partly responsible for the lower life expectancy of people with learning and cognitive disabilities.

The benefit of this SC is to ensure that users are not prevented from completing a user-interaction dialog because they have limited abilities to process information stored in working memory. Systems that do rely on user memorization will cause people significant stress, time spent repeatedly listening to the same voice menu, and a need to resort to techniques such as writing down the options (if they have the ability to write things down). Such problems could cause unacceptable delays, and possibly failure to access what could be vitally-important services (e.g., emergency health services). Real-life examples, where failing this success criterion impacts people, include an inability to get a telephone line re-connected, getting urgent access to a doctor, etc..

User-interaction dialogs, in which completion actions have a one-to-one mapping to simple discrete options, may meet this SC. Examples of user-interaction dialogs that do not depend on user memorization are ones where a voice-menu system has an alternative visual-menu system, or ones where there is easy access to a human operator who can help users achieve their goals.

Related Resources (optional)

Issue papers Voice Menu Systems See also:

• Gap analysis;
• User needs table; and
• Background research document
• Failing health services and delays impacting on life expectancy
• Health Inequality
• Death by Indifference

Testability

Test option 1: Check if one of the methods offered in task completion techniques conforms to the sufficient techniques, Test option 2:

• Step 1. Identify all the actions that complete a user-interaction dialog step.
• Step 2. Identify if the choice of the appropriate completion action might be dependent on information acquired from more than one serially-presented chunk of information (including short term memory, such as remembering a number). Also identify if the menu items use simple terms and have a one-to-one mapping to simple, discrete options.
• Step 3. Identify if there is an alternative way, which does not rely on memorized information, to complete a dialog step.

Acceptable outcomes for test option 2: No to step 2
OR

Yes to steps 2 and 3

Techniques

Included Techniques

• Using user interaction dialogs in which
  1. completion actions have a one-to-one mapping to simple, discrete options; and
  2. ach option is described before a number is associated with it and
  3. clear language is used and conforms to the SC X.X (understandable language)
• Using a user-interaction dialog, such as the standard "0" from any point, where there is easy access to a human operator who can help users achieve their goals.
• Human help is offered at any step that does not conform to Method 1 and
  • the option for human help is described before a number is associated with it; and
  • clear language, which conforms to the SC X.X (understandable language), is used for the human help option.
• Advisory technique: Cue users to write something that may be useful at a later point, and give them time to do so.

A voice-menu system offers an alternative visual-menu system. More details on this issue and on alternatives are available at https://rawgit.com/w3c/coga/master/issue-papers/voice-menus.html

[mbgower]

Task completion: Successfully completing tasks does not rely on users memorizing information presented in the current, or previous, user-interaction dialog steps.

I think if the word 'dialog" was removed here, it would reduce the prescriptive 'voice dialog' bias in this SC and allow it to have a broader application.

Description

In multi-step user-interaction dialogs, such as voice-menu systems...

I’m not sure why the focus has been reduced to voice-menu systems. That is obviously an example, but it’s not a typical web example. This is the first time I can recall non-web examples used for WCAG. I also don’t think it’s just voice systems that are presented serially; for example a questionnaire may ask a question per page, with a prior response determining current content.

---

See Voice Menu Systems issue paper...

Okay, I’m going to stop reviewing this SC at this point because I’m very confused about how a SC that is entirely non-web-related can be considered a WCAG SC. If WCAG has authorized COGA extending beyond the web, that’s interesting, and has ramifications on altering some of the highly web-centric language in parts of WCAG. But I would be surprised if this is actually the case. On the topic of Voice menus, I also think this SC falls short, in that it does not introduce level A basic requirements for accessibility/usability (outlined in a number of documents such as Top Ten Voice Response Usability Violations). I would suggest this SC on memory resolution would then possibly build on that as a level AA SC.

[awkawk]

I am concerned that this is potentially very broad. I'd like to see some cases where this would fail currently, and then to understand what it would take for them to pass this SC.

[lseeman]

an example of a failure is a voice ML system (like a phone menu system) that sease "press 3 for internal services" making the user remember a digit 3 whilst figuring out if what thye want is an internal service having it the other way around("for internal servces (pause) press 3" takes aways the memory requirement. the user can figuer it out and then hears the digit they need

Alternitivly reserving the 0 digit to get to a person, Or having the first option "to wieght for an operator press 0" also removes the memory rquirment

[johnfoliot]

Hi all,

While this is a good example, isn't it a tad out-of-scope for a "Web Accessibility" standard? Can we find a web-based equivalent that is equally as illustrative, but web-based instead? Do we have any examples of a web-based system that exhibits the 'bad' behavior we are attempting to address here?

Cheers!

JF

On Thu, Mar 23, 2017 at 1:18 PM, Lisa Seeman notifications@github.com wrote:

an example of a failure is a voice ML system (like a phone menu system) that sease "press 3 for internal services" making the user remember a digit 3 whilst figuring out if what thye want is an internal service having it the other way around("for internal servces (pause) press 3" takes aways the memory requirement. the user can figuer it out and then hears the digit they need

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/21#issuecomment-288814912, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-cylg1h9Tg0QL5UAByacWmBZa64pcks5roreJgaJpZM4K6uUv .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[awkawk]

@lseeman I am interested in web pages-based failure examples. Can you provide? (now seeing that is JF's question also)

[alastc]

(Replicating my survey comment)

The SC text refers to "completing tasks" but the testing talks about "user-interaction dialog step".

These are not the same thing, and a task is a very wide concept.

I think it should be narrowed to the actual focus of the description, how about: "Using interactive controls does not rely on...".

I think that actually has the same breadth, but puts the focus on the web-content rather than the more vague concept of "task".

[lseeman]

Can we merge part of accessible authetification. IE:

Users are not required to memorize information, character strings, and correct spellings; or perform calculations, such as including correctly identifying and entering numbers and letters from a character string; or speak, unless it is essential for the main function of a web site.

New wording could be

Task completion: Successfully completing tasks does not rely on users memorizing information character strings, and correct spellings; speak; or perform calculations, such as correctly identifying and entering numbers and letters from a character string or memorizing information presented in the current, or previous, user-interaction dialog steps; unless it is essential for the main function of a web site.

Is this new wording ok? Then we can get rid of capture from accessible authetification

[awkawk]

I had a conversation with Lisa about this and it seems that at the core is the idea that there is a need to provide instructions that are delivered linearly (largely meaning by audio) in a manner that the user receives the differentiating information first and then the action after that.

For example, "press 3 for sales, press 4 for support" is a problem where "for sales, press 3; for support, press 4" is better for people with short term memory issues.

I think that if we are going to do something about this we need to provide that guidance. There would still be a the existing requirements for textual versions of audio, but if there was a web-based service that doesn't have a screen or is delivered via a phone, then this might be the only way to support the user need, and it may be useful if the user prefers audio over the text.

Here's a suggestion: When presenting users information about multiple selectable options via audio, provide the details about each option before indicating the action that the user needs to take to select the option, or provide a way to get to assistance.

Then we would provide information in the understanding document that would provide examples.

What do people think? By making this about audio instructions, which certainly can be provided via the web. Thoughts?

[awkawk]

I would also suggest renaming this "Audio Instructions" or something else similar.

[DavidMacDonald]

In SC speak it would be something like:

When information about multiple selectable options is provided by audio recording, details about each option are spoken before the action that the user needs to take to select the option unless there are instructions or a way to get to assistance.

The big question is internationalization. In some languages that might be the opposite way for the best understanding, I don't know.

[awkawk]

That's a good point, I'm not sure. @lseeman?

I suspect that there is actually something to the idea that people need to know whether the option is the right one before being told what to do about it.

[johnfoliot]

There is also the recurring concern about how much editorial influence we can assert before it collides with laws and legal protections (for example, in the U.S. the First Amendment - which has been previously cited when discussing editorial impacts).

I support the thrust of this, but can we actually get it to a testable SC, or will it remain an editorial Best Practice - that is the question I'm thinking about right now.

JF

On Fri, Jul 21, 2017 at 1:27 PM, Andrew Kirkpatrick < notifications@github.com> wrote:

That's a good point, I'm not sure. @lseeman https://github.com/lseeman?

I suspect that there is actually something to the idea that people need to know whether the option is the right one before being told what to do about it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/21#issuecomment-317077512, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c9DEVt4Y38pwOScFRXUmmHtzQXK8ks5sQO2QgaJpZM4K6uUv .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[mbgower]

There seem to be a couple of considerations here. I'm not worrying too much about wording here, just getting the ideas down:

1. Each step in a sequential process must contain the information necessary to allow a user to proceed (and so must not rely on memory from prior steps, and would benefit from a summary of info, or a mechanism for traversing the process.
2. In information provided by audio output, labels should proceed the activation mechanism

Are there others?

[lseeman]

@mbgower the best practice I think is to allow people to reach a human by pressing 0. however we need to allow other alternatives as well @awkawk I am not sure why internationalization should be a problem. people have trouble remember in a digit while processing speech in any language. do you know a language where requiring rembering the digit is necessary? (Hebrew is a very different construct to english and i do know it works there) @johnfoliot this might interest you (from the issue paper) "For example, the U.S. Telecommunications Act Section 255 Accessibility Guidelines [Section255] paragraph 1193.41 Input, control, and mechanical functions, clauses (g), (h) and (i) apply to cognitive disabilities and require that equipment should be operable without time-dependent controls, the ability to speak, and should be operable by persons with limited cognitive skills. Technology" - in other words this is already a requirement by law, just people do not know it.

[mbgower]

allow people to reach a human by pressing 0

@lseeman, As per my original comments back in February, why are these examples phone based instead of web-based?

U.S. Telecommunications Act Section 255 Accessibility Guidelines [Section255] paragraph 1193.41

255 got updated at the start of the year, so the numbering and text has all changed.

[lseeman]

We can have just add a scope narrowing term

Task completion: In voice systems, successfully completing tasks does not rely on users memorizing information presented in the current, or previous, user-interaction dialog steps. Note that the following requirements must apply: understandable language; clear structure and relationships; and clear and unambiguous separation of menu items, which must be level A in this scope. (This may be addressed by reiterating these requirements here to increase conformance.) Exception: This success criterion does not apply if memorizing, or otherwise mentally processing information, is the primary purpose of the dialog step (e.g., a step in a game which deliberately tests the player's memory skills).

[mbgower]

@lseeman

the best practice I think is to allow people to reach a human by pressing 0. however we need to allow other alternatives as well

So is this a third consideration?

or a mechanism is available to request direct assistance

[andyheath]

As it stands the front text of the SC expresses a very general user need that applies in systems. The text "Successfully completing tasks does not rely on users memorizing information presented in the current, or previous, user-interaction dialog steps." has many different ways to satisfy it - and its very valid but if the way to satisfy it is as given in the techniques then in my opinion the SC needs scoping down to that context. Such as "When using voice audio systems successfully completing a task ...". I am new to writing SC text so I think maybe this narrow context is described in some structure into which the SC drops (I'm guessing), but as it stands we have a very general and broad "need" satisfied by a very narrow set of techniques. -andy