Feedback

[lseeman]

Current version of SC and Definitions

• SC for viewing | SC for editing

• SC in full draft guideline

Feedback

                    <a href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#sc-text"></a>The success or failure of every user initiated action is clearly indicated to the user by visual, programmatically-determinable, rapid feedback in the primary modalities of the content. Audio feedback is supported.
                  <h2><a href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#suggestion-for-priority-level-aaaaaa"></a>Suggestion for Priority Level: AA</h2>           <h2><a href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#related-glossary-additions-or-changes"></a>Related Glossary additions</h2>     
                  <dl>
                        <dt><b>Clearly indicated (success or failure</b>)</dt>
                        <dd> confirmation informing the user, after a user-action, that the action was successful or failed and, if the action is part of a process, where the user is in the process.<br>
                          (was: confirm that, after a user action, the user knows that the action was successful or not. Applications should also let the user know what just happened and where they are in a process.)</dd>
                        <dt><b>Rapid feedback</b></dt>
                        <dd>The next activity or event affecting the application.</dd>
                        <dt><b>Audio feedback (was: Spoken feedback)</b></dt>
                        <dd>Audible feedback is often more effective then written feedback. However, having both audible feedback and longer-lasting written and visual feedback helps the user know where they are, and restores the context if attention is lost. Audible feedback can annoy and distract some people, so audible feedback should be available as an option, and in response to a user-preference setting when available.<br>      (was: Spoken feedback is often more effective then written feedback. However, having both spoken feedback and longer-lasting written and visual feedback helps users know where they are, and restores the context if attention is lost. Spoken feedback can annoy and distract some people, so spoken feedback should be available as an option, and in response to a user-preference setting when available.)</dd>
                        <dt><strong>Primary modalities of the content</strong></dt>
                        <dd>Modes and technologies considered during design  phase of development.</dd>
                    </dl>
                    <h2><a href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#what-principle-and-guideline-the-sc-falls-within">Principle and Guideline</a></h2>           <p>Principle 3, Guideline 3.3</p>           <h2><a href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#description">Description</a></h2>     <p>Applications should <span id="docs-internal-guid-9beb1966-66a5-63f8-5bf5-6cee384f65e4">consistently</span> provide easily-recognizable success or failure feedback with every user action. </p>     <p>For example:     </p><ul>      <li>After a step in a multi-step task is completed, breadcrumbs display a tick or a checkmark next to that step's name; and, if applicable, the title or the name of the next step is readily apparent.</li>      <li>After a button is clicked, it should look depressed. (Note that if it is a toggle button, the state should also be programmatically determinable).</li>      <li>After a form is submitted or an email message is sent, feedback communicating what just happened, such as "Your application was submitted, thank you" or "Your email message was sent" is provided.</li>     </ul>           <h2><a href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#benefits"></a>Benefits</h2>     <p>Overt indication of the result stemming from a user action helps people with a variety of cognitive disabilities:</p>
                    <ul>
                        <li>understand that their action occurred (e.g., the click did something); </li>
                        <li>prevent uncertainty or doubt regarding the outcome; and </li>
                        <li>remember what they just did. </li>
                    </ul>
                    <p>User-action feedback during a multi-step task can also assist people, with attention or short-term cognitive disabilities, avoid inadvertently leaving a task by reminding them that they are in a process, and where in the process they currently are.</p>
                    <p>This information supports those who have Aphasia, Dementia, Dyslexia, or those who acquire cognitive disabilities as they age. It also helps anyone with impaired short-term memory remember what they just did.</p>
                    <h3>Related Resources</h3>                 <p>Resources are for information purposes only. No endorsement is intended or implied.</p>                 <ul>      <li><a rel="nofollow" href="https://w3c.github.io/wcag/coga/user-research.html">Cognitive Accessibility User Research</a> sections: 3.1, 3.2, 3.4, 3.5, 3.6, 3.7, and 4.2</li>      <li><a href="http://www.idt.mdh.se/utbildning/exjobb/files/TR1091.pdf">Is a big button interface enough for elderly users? (PDF)</a>, page 24. Tanid Phiriyapkanon, Mälardalen University Press, Sweden, 2011</li>     </ul>           <h2><a href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#testability">Testability</a></h2>     <h3>Procedure</h3>     <ol>      <li>Trigger every user-initiated action, and visually inspect the screen, to determine if the resulting content provides a rapid and clear indication of success or failure.</li>      <li>If the user-initiated action is part of a multi-step process, visually inspect the screen to confirm the resulting content informs users which steps have been completed, and which step they are on in the process.</li>      <li>Trigger every user-initiated action with a screen reader to determine if the resulting content announces a rapid and clear indication of success or failure.</li>      <li>If the user-initiated action is part of a multi-step process, confirm, with a screen reader, that the resulting content announces to users which steps have been completed, and which step they are on in the process.</li>     </ol>     <h3>Expected Results</h3>     <ul>      <li>All checks above are true</li>     </ul>                <h2><a href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#techniques">Techniques</a></h2>     <ul>      <li>All existing techniques for 3.3.1.</li>      <li>Use <span id="docs-internal-guid-9beb1966-66a6-ef24-3c33-5205cee1a780">WAI-ARIA states</span> to provide state feedback for a toggle button with <span id="docs-internal-guid-9beb1966-669f-1d81-17f7-6bb980b805ef"> an animation showing the state (such as a button was pushed </span>)</li>
                      <li><span>Use ARIA-pressed with a visual or a checkbox is checked/unchecked,</span></li>      
                      <li>Provide a confirmation message when an email message is successfully sent, or a form is successfully submitted.</li>      <li>Use a progress-indicator element (e.g., breadcrumbs) to communicate completed and current steps in a multi-step process.</li>      <li>Provide visible and programmatically-determinable information to indicate a new password satisfies security requirements.</li>     </ul>

working groups notes (optional)

[rachaelbradley]

I will sign up as SC manager for this issue.

[joshueoconnor]

Thanks @rachaelbradley I've added this to https://www.w3.org/WAI/GL/wiki/SC_Managers_Phase1#Current_SC_Managers

[WayneEDick]

This really needs coordination with Issue 2 (before Issue 3). This is stated more clearly, but it may not be as easy to implement. I like it.

[rachaelbradley]

I agree it needs coordination but I'm not sure it needs to be merged. I've added comments on issue #2.

[mapluke]

The SC says that the rapid feedback should be "visual" and "in the primary modalities of the content". When the primary modality of the content is visual this is tautological. However, when the primary modality is audible then this is a contradiction. I think that the "visual" is superfluous.

[mapluke]

The final wording "Audio feedback is supported." seems to be very problematic. Firstly what exactly does it mean and secondly is it realistic to ask for it.

The glossary entry for "audio feedback" is a lengthy discussion of the merits and demerits of audio and visual feedback - a glossary entry should really define the term, so the current text is not suitable.

In comparing issue #2 and issue #54 David MacDonald states that the SC "asks for audio feedback without Assistive Technology, and it calls for the user to have a choice in this... but ONLY for actions that result in success or failure." and in proposing a merger of the two SCs he left out "the requirement for Non AT audio feedback, which is really hard."

Perhaps we should reassess how wise it is to include this. If it is included it needs to be made much clearer what is being asked for and also what needs to be tested - currently audio feedback is not mentioned in the testability section (and neither is testing to see if the feedback modality matches the primary content modality).

[rachaelbradley]

@mapluke and @lseeman What are your thoughts on moving the audio feedback into a separate AAA SC vs dropping it? My understanding is that the audio version of feedback can be important to support some cognitive disabilities but that the technology may not be standard enough for us to make this an A or AA standard at this time.

[lseeman]

Dont drop it. we can make sure the technology is ready by the time it goes to CRat worst laible that section at risk. Can we label one part of one Sc at risk?

Also it is , of course, completely doable today via short MP3's with a small javascript to make it optional. most programmers can do that in a day and it will be in stack overflow soon enough and then everyone can just copy the script. It is just not idea now and a more work and , as I said , we can make it ready via a browser plug in by CR. The semantics are already freely available at https://w3c.github.io/personalization-semantics/

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Tue, 17 Jan 2017 02:43:12 +0200 rachaelbradley<notifications@github.com> wrote ----

@mapluke and @lseeman What are your thoughts on moving the audio feedback into a separate AAA SC vs dropping it? My understanding is that the audio version of feedback can be important to support some cognitive disabilities but that the technology may not be standard enough for us to make this an A or AA standard at this time. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[lseeman]

It is addressed via the new personlization semantics . I think it is in the blurb

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Mon, 16 Jan 2017 20:43:35 +0200 mapluke<notifications@github.com> wrote ----

The final wording "Audio feedback is supported." seems to be very problematic. Firstly what exactly does it mean and secondly is it realistic to ask for it. The glossary entry for "audio feedback" is a lengthy discussion of the merits and demerits of audio and visual feedback - a glossary entry should really define the term, so the current text is not suitable. In comparing issue #2 and issue #54 David MacDonald states that the SC "asks for audio feedback without Assistive Technology, and it calls for the user to have a choice in this... but ONLY for actions that result in success or failure." and in proposing a merger of the two SCs he left out "the requirement for Non AT audio feedback, which is really hard." Perhaps we should reassess how wise it is to include this. If it is included it needs to be made much clearer what is being asked for and also what needs to be tested - currently audio feedback is not mentioned in the testability section (and neither is testing to see if the feedback modality matches the primary content modality). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mapluke]

I'm not directly advocating that we drop the "Audio feedback is supported", but:

1. What it means needs to be clarified (the glossary entry doesn't help).
2. We need to show how it might be supported (I'm not clear in what way "it is addressed via the new personalization semantic" - we need a clearer pointer to where.
3. If its in the SC, it also needs to be in the testability section.

If we can't meet these minimum requirements then something needs to be done about it or it will risk the whole SC (e.g. marked as a sub-element that is at risk (if this is permissable); moved to a separate AAA requirement, or dropped).

[lseeman]

Mike, the testability secsion is not full tests, just to give additional information on how to test it if needed. this is easy to human test. All you needed to do is add the word "auditory" to the test and you have it. -Confirm there is a setting auditory feedback, set it for auditory feedback

• Trigger every user-initiated action -confirm the correct auditory feedback was received

I think "auditory feedback "ids very clear. It means the notification is available though sound. If you do not think that is clear, maybe take a stab at a better definition.

We also only need the technique heading at this point. we do not need the full technique

[rachaelbradley]

Lisa, for the auditory feedback, based on the changes, I believe a sound defined to indicate success (the beeping when an outlook message sends for example) is acceptable and it does not need to be words. Do you agree or have I missed the point?

[joshueoconnor]

@rachaelbradley I see this is still in active discussion. Do you think you will be soon in a position to submit a PR or do you need more time? @lseeman

[mapluke]

I still do not see an answer to my concern that it is not possible for the feedback to be both "visual" and "in the primary modalities of the content" if the primary modality of the content (however that is determined) is auditory.

I also still think that the "Audio feedback is supported." is not clear. Does this mean that audio feedback should be available to supplement any visual feedback or does it mean that it should replace that feedback. I'm also not too sure how wise it is to propose a solution that is based upon the prospect that suitable technology will be (easily and widely?) available by the time WCAG 2.1 is published.

Until we have solid and convincing answers to these questions I fear that doing a PR and surveying the proposal is likely to lead to another negative reaction.

[WayneEDick]

Maybe we could talk. I manage #2 and I think they are different. Both say there must be notification. #54 seems to be more specific about how.

I don't see how #54 could work without #2 but they are both necessary.

Wayne

On Sat, Feb 4, 2017 at 4:05 PM, mapluke notifications@github.com wrote:

I still do not see an answer to my concern that it is not possible for the feedback to be both "visual" and "in the primary modalities of the content" if the primary modality of the content (however that is determined) is auditory.

I also still think that the "Audio feedback is supported." is not clear. Does this mean that audio feedback should be available to supplement any visual feedback or does it mean that it should replace that feedback. I'm also not too sure how wise it is to propose a solution that is based upon the prospect that suitable technology will be (easily and widely?) available by the time WCAG 2.1 is published.

Until we have solid and convincing answers to these questions I fear that doing a PR and surveying the proposal is likely to lead to another negative reaction.

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

[lseeman]

sure. wayne and mike, can you ping me some available times tomorrow or tuesdayto lisa.seeman@zoho.com

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Sun, 05 Feb 2017 03:38:11 +0200 WayneEDick<notifications@github.com> wrote ----

Maybe we could talk. I manage #2 and I think they are different. Both say there must be notification. #54 seems to be more specific about how.

I don't see how #54 could work without #2 but they are both necessary.

Wayne

On Sat, Feb 4, 2017 at 4:05 PM, mapluke <notifications@github.com> wrote:

> I still do not see an answer to my concern that it is not possible for the > feedback to be both "visual" and "in the primary modalities of the > content" if the primary modality of the content (however that is > determined) is auditory. > > I also still think that the "Audio feedback is supported." is not clear. > Does this mean that audio feedback should be available to supplement any > visual feedback or does it mean that it should replace that feedback. I'm > also not too sure how wise it is to propose a solution that is based upon > the prospect that suitable technology will be (easily and widely?) > available by the time WCAG 2.1 is published. > > Until we have solid and convincing answers to these questions I fear that > doing a PR and surveying the proposal is likely to lead to another negative > reaction. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/w3c/wcag21/issues/54#issuecomment-277487400&gt;, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AH0OF96-CO7bYQ4gLSP_fSw9q8zJ2JEJks5rZRJMgaJpZM4K9Jlt&gt; > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[rachaelbradley]

Is it possible for all four of us to talk tomorrow? I think the questions on the table are:

1. Are both #2 and #54 needed? I personally side with Wayne that both are needed but I know others disagree.
2. If both are needed, what else is needed to differentiate between them?
3. Define audio feedback (Draft definition: Sound-based information provided independent of assistive technology. Feedback may use speech or consistently applied sounds to convey information. )
4. What conditions require audio feedback (or which do not)?

[lseeman]

Sure.What time are you free ? Contact me on skype or lisa.seeman@zoho. com

---- On Sun, 05 Feb 2017 22:07:28 +0200 rachaelbradley<notifications@github.com> wrote ----

Is it possible for all four of us to talk tomorrow? I think the questions on the table are: Are both #2 and #54 needed? I personally side with Wayne that both are needed but I know others disagree. If both are needed, what else is needed to differentiate between them? Define audio feedback (Draft definition: Sound-based information provided independent of assistive technology. Feedback may use speech or consistently applied sounds to convey information. ) What conditions require audio feedback (or which do not)? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mapluke]

I could talk immediately after the COGA call. Alternatively, with a bit of notice I might be able to take part no more than an hour before the COGA call. I too am available on Skype (mapluke).

[rachaelbradley]

Revision based on conversation. We will break this into two SC: (AA) Feedback The success or failure of every user initiated action is clearly indicated to the user by through consistent, programmatically-determinable, rapid feedback in the primary modalities of the content.

Note: If the content is primarily visual, than feedback should be visual. If the content is primarily auditory, feedback should be auditory.

(AAA) Auditory Feedback When visual feedback is provided, auditory feedback is also supported.

Definition Auditory Feedback: Sound-based information provided without requiring a screenreader. Feedback may use speech or consistently applied sounds to convey information.