search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.4k stars 4.16k forks source link

Changes and updates are not announced to assistive technologies #15292

Open karlgroves opened 5 years ago

karlgroves commented 5 years ago

Changes and updates are not announced to assistive technologies

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

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 commented 5 years ago

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.