Changes and updates are not announced to assistive technologies

[karlgroves]

Changes and updates are not announced to assistive technologies

• Severity: Medium
• Affected Populations:
  • Blind
  • Low-Vision
  • Cognitively Impaired
• Platform(s):
  • Windows - Screen Reader
  • Windows - ZoomText
  • Mac - VoiceOver
  • Android - TalkBack
  • iOS - VoiceOver
• Components affected:
  • Block Editing
  • Block Options

Issue description

Many of the Block functions are not announced to assistive technologies.
Although some functions are announced (such as creating a new block),
many other functions are not (such as hiding or showing the Block panel,
removing/deleting blocks, duplicating blocks, and actions such as Undo
and Redo).

Some actions are quite easy to perform by mistake. For example, when
users hit the Enter key while their cursor is at the end of any text or
content in a block, this will trigger the creation of a new block.
Although this is announced, it's so easy to trigger unintentionally
that users may come to rely on the Undo and Redo states to maintain the
output they want, and these states are not announced.

Users who are blind or who have low-vision must determine what's
changed by navigating around the various blocks, and this may be
particularly difficult for users with a cognitive disability. Users
attempting to removing several duplicates or blocks which happen to have
a lot of similar text must inspect most of the block text to ascertain
their current state, and requires users with print disabilities to rely
on short-term memory more than sighted users.

Remediation Guidance

Use a short aria-live region announcement for actions which makes a
visible change to the document or interface and which aren't already
announced, such as block duplication or removal, opening and closing the
Block panel, and Redo and Undo actions.

An example of the success state being announced is when a link is
removed: assistive technologies announce "Link removed".

Also consider whether an "earcon" (a short noise signalling success or
failure) might be appropriate for some actions.

Additionally, it would be helpful to provide the ability to silence
these announcements, via a user profile setting, for those who find the
announcements unnecessary (such as a sighted or partially-sighted screen
reader user).

Recommended Code

    <!-- example current existing success status message -->


    <div id="wp-a11y-speak-assertive" aria-live="assertive" aria-relevant="additions text" aria-atomic="true" class="screen-reader-text wp-a11y-speak-region">Link removed.</div>





    <!-- example additional status message -->


    <div id="wp-a11y-speak-assertive" aria-live="assertive" aria-relevant="additions text" aria-atomic="true" class="screen-reader-text wp-a11y-speak-region">Block duplicated.</div>

Relevant standards

• 3.2.5 Change on Request (Level
  AAA)

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-94 in Tenon's report

[afercia]

Ideally, all actions that don't produce native feedback should then use an audible message via speak(). Maybe worth considering a programmatic way to declare which actions need to trigger a speak() message.

Lack of proper feedback can be considered a bug, labelling this issue as such.