Add audible messages to confirm the "move block" actions #24894
Conversation
ZebulanStanphill
added
the
[Focus] Accessibility (a11y)
|
To fully test, worth reminding the keyboard shortcuts to move blocks are (on macOS):
Moving left or right can be tested on the "Buttons" or "Social icons" blocks:
Screenshot illustrating moving three social icons buttons when using Safari and VoiceOver:
|
|
|
||
| announceBlockMoved( state, direction ); | ||
| }, | ||
| MOVE_BLOCKS_UP: ( action, { getState } ) => { |
There was a problem hiding this comment.
It's odd to read an action type of "UP" while orientation changes it to right / left within. It'd be better to have a single "MOVE_BLOCKS" type and handle all cardinals within. (Alternatively, there could be four action types.)
There was a problem hiding this comment.
This just uses the existing actions. Actually, there are no specific actions for "left" and "right". Not opposed to improvements but the current actions implementation is out of the scope of this issue.
| let direction = 'down'; | ||
|
|
||
| if ( action.orientation === 'horizontal' ) { | ||
| direction = settings.isRTL ? 'left' : 'right'; |
There was a problem hiding this comment.
Is this correct? Wouldn't the actual move actions still be accurate given left moves to the left regardless of RTL?
There was a problem hiding this comment.
It is correct. "down" moves the block to the "following" position, whether it's vertical or horizontal. In LTR, the "following" horizontal position is right, while in RTL is left.
| const blockCount = getSelectedBlockCount( state ); | ||
| let message; | ||
|
|
||
| switch ( direction ) { |
There was a problem hiding this comment.
It seems all these could be inlined and don't need the extra abstraction of announceBlockMoved
There was a problem hiding this comment.
I'd disagree. Seems to me it's way more readable this way.
talldan
added
the
First-time Contributor
|
I tested again this PR, also on Windows Firefox + NVDA and in RTL. Everything works as expected. Code looks good as is, to me. Kindly asking to have a new review please, when there's a chance 🙂 /Cc @youknowriad @talldan In RTL: last action was "move to right":
|
| @@ -219,6 +271,30 @@ export default { | |||
| ) | |||
| ); | |||
| }, | |||
| MOVE_BLOCKS_DOWN: ( action, { getState } ) => { | |||
There was a problem hiding this comment.
Can we move away from effects and instead implement these action creator as "generators"? see moveBlocksToPosition as an example of action generator.
There was a problem hiding this comment.
Not sure I follow. Maybe I lack context or it's a terminology thing 🙂 In this PR we just reused actions that already exist. Are you suggesting a major refactoring in the way these actions are created?
There was a problem hiding this comment.
We're slowly moving away from using "effects" (see effects.js file and the https://github.com/aduth/refx middleware) and instead we're trying to replace them with "generator" actions (consistency with resolvers).
These are just two technologies that allow the same thing: writing complex actions with side effects.
So ideally, new code shouldn't add new effects and use generators instead.
There was a problem hiding this comment.
Good to know. Is this documented anywhere? How new contributors are supposed to be informed about this? 🙂 If it's not documented, I'd say it's a barrier to new contributors...
There was a problem hiding this comment.
You're right, it should be. We were hoping we could get rid of these files which remove the confusion but the refactor efforts staled.
Fixes #23995.
Description
Added audible messages to
aria-live="assertive"region to confirm the "move" action to the screen reader users.The messages check for orientation and RTL to make sure they are consistent with the label of the button used to perform the action.
This PR has been created during the Yoast Contributor Day.
The people who worked on it are @jcomack, @afercia, @enricobattocchi.
How has this been tested?
horizontalorientation)<div id="a11y-speak-assertive">to read the messages without a screen reader active.Types of changes
New feature (non-breaking change which adds functionality)
Checklist: