Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All notices should use a spokenMessage #9425

Closed
afercia opened this issue Aug 29, 2018 · 6 comments
Closed

All notices should use a spokenMessage #9425

afercia opened this issue Aug 29, 2018 · 6 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Bug An existing feature does not function as intended

Comments

@afercia
Copy link
Contributor

afercia commented Aug 29, 2018

The failure notices in packages/editor/src/store/effects/posts.js should also use a spokenMessage to produce an audible message in the ARIA live region. This should be pretty standard for all the notices and it's already implemented in some of them, for example the success notices.

Also, the string used for the spoken message should not include links. See for example

if ( noticeMessage ) {
dispatch( createSuccessNotice(
<p>
{ noticeMessage }
{ ' ' }
{ shouldShowLink && <a href={ post.link }>{ __( 'View post' ) }</a> }
</p>,
{ id: SAVE_POST_NOTICE_ID, spokenMessage: noticeMessage }
) );

@afercia afercia added [Type] Bug An existing feature does not function as intended [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). labels Aug 29, 2018
@afercia afercia changed the title Failure notices should use a spokenMessage All notices should use a spokenMessage Aug 29, 2018
@afercia
Copy link
Contributor Author

afercia commented Aug 29, 2018

Seems there are a few more notices that need a spoken message:

  • trashPostFailure
  • a few ones in packages/editor/src/store/effects/reusable-blocks.js

@afercia
Copy link
Contributor Author

afercia commented Aug 29, 2018

Ah OK I understand better now. So, by default the audible message will be the string used for the visible message. Only if a different audible message is desired, then it's possible to use spokenMessage to differentiate it:

CREATE_NOTICE( { notice: { content, spokenMessage } } ) {
const message = spokenMessage || content;
speak( message, 'assertive' );
},

@aduth
Copy link
Member

aduth commented Nov 19, 2018

The behavior was changed in the introduction of the notices module in #9617 to make the displayed content align to the spoken text, by limiting the acceptable content of a notice to plaintext.

@gziolo
Copy link
Member

gziolo commented Feb 17, 2019

@afercia is it still an issue?

@nerrad I noticed that you refactor the same codebase in #13716 that is referenced in this issue. It would be great to double check if this issue is resolved or plan how to resolve it.

@nerrad
Copy link
Contributor

nerrad commented Feb 17, 2019

The refactor in #13716 is mostly preserving the existing behaviour in the code existing in master now. As @aduth mentioned, #9617 seems to be what would have had the most impact on this issue. So awaiting confirmation from @afercia, it looks to me like this issue shouldn't exist now?

@afercia
Copy link
Contributor Author

afercia commented Feb 18, 2019

To my understanding, all notices have now built-in ability to speak() their message (as long as the default option speak: true is not changed) so I guess this issue can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

4 participants