ResizableFrame: Make keyboard accessible #52443
Conversation
mirka
added
[Type] Bug
|
Size Change: +2.58 kB (0%) Total Size: 1.43 MB
ℹ️ View Unchanged
|
| .edit-site-resizable-frame__handle-label { | ||
| background: var(--wp-admin-theme-color); | ||
| border-radius: 2px; | ||
| color: #fff; | ||
| margin-right: $grid-unit-10; | ||
| padding: 4px 8px; |
| border: 0; | ||
| border-radius: $grid-unit-05; | ||
| cursor: col-resize; | ||
| display: flex; | ||
| height: $grid-unit-80; | ||
| justify-content: flex-end; | ||
| padding: 0; |
There was a problem hiding this comment.
Resets user agent button styles.
| // TODO: Confirm if this is the focus behavior we want | ||
| document.querySelector( 'iframe[name=editor-canvas]' ).focus(); |
There was a problem hiding this comment.
Needs accessibility feedback: Do we want some kind of focus manipulation after the frame is resized to full width? (cc @afercia @andrewhayward)
To test
- Focus on the resize handle.
- Hit the left arrow key until the editor canvas is in full width (edit mode).
- Hit the tab key to see where the focus is.
Comment out line 197 to see the default behavior.
There was a problem hiding this comment.
I think it would be good if focus behaved the same in this case as it does when moving to edit mode by pressing Enter after focusing the frame, where we land at the top of the editing canvas and Tab focuses the first block in Select mode.
One thing I'm noticing is that focusing on resize handle and pressing left arrow once sometimes takes me into edit mode straightaway. I'm not sure if that's desirable, as currently the drag handle, when dragged with a mouse, allows us to expand the canvas until the sidebar is about 100px wide, and only if we try expanding further than that does it switch to edit mode. Dragging with a mouse is also behaving a bit weirdly in this branch:
draghandle.mov
(I can't reproduce this 100% of the time, but it's happening consistently on Firefox and about half the time on Chrome)
There was a problem hiding this comment.
Hello @mirka @tellthemachines I'd agree focus management should work in the same way it works when switching to the Edit view when pressing Enter on the iframe. However, I'm not sure it should land on the first block... I created #51570 a few days ago to reconsider initial focus on the Site editor > Edit view.
| className="edit-site-resizable-frame__handle" | ||
| className={ classnames( | ||
| 'edit-site-resizable-frame__handle', | ||
| { 'is-resizing': isResizing } |
There was a problem hiding this comment.
Makes is-resizing a proper CSS modifier for this element, instead of relying on the modifier on the parent element.
tellthemachines
added
the
Backport to WP 6.7 Beta/RC
There was a problem hiding this comment.
Thanks for fixing this! It's generally working well, apart from what I mentioned below.
One thing (unrelated to this PR) I noticed when testing is that there's no way to skip directly into edit mode with the keyboard; we have to tab through the whole sidebar to get to the canvas frame. Would be nice to have a skip link or something at the start.
| // TODO: Confirm if this is the focus behavior we want | ||
| document.querySelector( 'iframe[name=editor-canvas]' ).focus(); |
There was a problem hiding this comment.
I think it would be good if focus behaved the same in this case as it does when moving to edit mode by pressing Enter after focusing the frame, where we land at the top of the editing canvas and Tab focuses the first block in Select mode.
One thing I'm noticing is that focusing on resize handle and pressing left arrow once sometimes takes me into edit mode straightaway. I'm not sure if that's desirable, as currently the drag handle, when dragged with a mouse, allows us to expand the canvas until the sidebar is about 100px wide, and only if we try expanding further than that does it switch to edit mode. Dragging with a mouse is also behaving a bit weirdly in this branch:
draghandle.mov
(I can't reproduce this 100% of the time, but it's happening consistently on Firefox and about half the time on Chrome)
|
Couple of thoughts... Edit modeFirst, it's really jarring and unexpected to jump into edit mode by hitting left one too many times, and I'd fail it under WCAG 3.2.2:
I'd suggest instead that we clamp the resizing to the maximum and minimum sizes available, and leave it as a simple resize control. Diffdiff --git a/packages/edit-site/src/components/resizable-frame/index.js b/packages/edit-site/src/components/resizable-frame/index.js
index 22567dbe96..cb5f5120ee 100644
--- a/packages/edit-site/src/components/resizable-frame/index.js
+++ b/packages/edit-site/src/components/resizable-frame/index.js
@@ -176,9 +176,12 @@ function ResizableFrame( {
const step = 20 * ( event.shiftKey ? 5 : 1 );
const delta = step * ( event.key === 'ArrowLeft' ? 1 : -1 );
- const newWidth = Math.max(
- FRAME_MIN_WIDTH,
- frameRef.current.resizable.offsetWidth + delta
+ const newWidth = Math.min(
+ Math.max(
+ FRAME_MIN_WIDTH,
+ frameRef.current.resizable.offsetWidth + delta
+ ),
+ initialComputedWidthRef.current
);
setFrameSize( {
@@ -188,14 +191,6 @@ function ResizableFrame( {
initialAspectRatioRef.current
),
} );
-
- // If oversized, immediately switch to edit mode
- if ( newWidth > initialComputedWidthRef.current ) {
- setFrameSize( INITIAL_FRAME_SIZE );
- setCanvasMode( 'edit' );
- // TODO: Confirm if this is the focus behavior we want
- document.querySelector( 'iframe[name=editor-canvas]' ).focus();
- }
};
const frameAnimationVariants = {Component roleSecondly, we should ideally mark the resize handle as a <el role="separator" aria-valuemin="..." aria-valuemax="..." aria-valuenow="..." />Diffdiff --git a/packages/edit-site/src/components/resizable-frame/index.js b/packages/edit-site/src/components/resizable-frame/index.js
index 22567dbe96..e500723c31 100644
--- a/packages/edit-site/src/components/resizable-frame/index.js
+++ b/packages/edit-site/src/components/resizable-frame/index.js
@@ -231,6 +231,10 @@ function ResizableFrame( {
return shouldShowHandle ? 'visible' : 'hidden';
} )();
+ const maxSize = initialComputedWidthRef.current;
+ const minSize = FRAME_MIN_WIDTH;
+ const currentSize = frameRef?.current?.resizable?.offsetWidth || maxSize;
+
return (
<ResizableBox
as={ motion.div }
@@ -281,8 +285,13 @@ function ResizableFrame( {
) }
variants={ resizeHandleVariants }
animate={ currentResizeHandleVariant }
+ role="separator"
+ aria-orientation="vertical"
aria-label={ __( 'Drag to resize' ) }
aria-describedby={ resizableHandleHelpId }
+ aria-valuenow={ currentSize }
+ aria-valuemin={ minSize }
+ aria-valuemax={ maxSize }
onKeyDown={ handleResizableHandleKeyDown }
initial="hidden"
exit="hidden" |
tellthemachines
added
[Priority] High
|
We should aim to have this wrapped up before the end of the week so it can make 6.3 RC1. Do you think that's possible @mirka? |
Yes, I'll try to land this ASAP 🙏 |
|
Quickly tested and seems to me it works pretty well, thank you! One thing I found a bit confusing is that the 'Drag to resize' handle is placed in the tab sequence after the iframe. I would expect to find it between the navigation and the iframe so that it also matches the visual order. A few more things:
|
|
I forgot the separator should also have an |
|
Flaky tests detected in 5acbbfd. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5536279309
|
|
@tellthemachines regarding the last two points you reported (good catch), I alraedy created two issues ~ one month ago. It would be great it they could be triaged.
See #51578
See #51540 |
| } | ||
| aria-valuemin={ FRAME_MIN_WIDTH } | ||
| aria-valuemax={ | ||
| initialComputedWidthRef.current |
There was a problem hiding this comment.
I'm thinking aria-valuemax should always be the main document offsetWidth. Otherwise this value will be different depending on the editor mode. For example: My screen is a 16-inch retina display. The default scaled resolution is 1792 x 1120 so the actual viewport width is 1792. WHen the editor is in vide mode, this will be aria-valuemax="1408". When the editor is in edit mode, this will be aria-valuemax="1792".
I think the value should always the actual maximum width the iframe can be set to, which is 1792.
Also, we should make sure this value updates when resizing the browser window (I thikn it does update when set to the main document offsetWidth).
There was a problem hiding this comment.
This is a difficult one actually. The values are associated with the separator, and the separator is only functional in View mode. Especially in a keyboard operation context, where I believe the semantics are most relevant, the max value is in fact the initial computed width. I think it would be confusing if you couldn't keyboard resize the frame up to the purported max value.
(In testing this, I noticed that the resize handle is still in the tab sequence when in Edit mode, so I fixed that. 5acbbfd)
Is there a follow-up issue for this already? I don't want to block this PR so yes it can be addressed separately. But I'd be a bit uncomfortable with releasing this feature in WP 6.3 with a confusing tab sequence. |
|
On a side note: Edit: |
I will post an issue after this PR is merged. However, this is a tricky one, because in the general case, resize handles can be on any edge or corner. It's only in this specific case where the handle is only on the left edge. So I do see an argument to optimize for consistency in the general case (for example the one in Style Book with two handles), and have all handles come after the frame.
That makes sense. I changed it to 320px (5fa0e8d), and I think we can change the Style Book one as well. |
|
@tellthemachines I just realized that the dragging glitch you were seeing is likely #52582. I'll try to get that patched ASAP as well. |
There was a problem hiding this comment.
Thanks for the follow-ups @mirka ! I think this is in a good place to be merged now, to fix the major regression from 6.2. Then we can address the rest of the issues.
One small thing that could be improved: screen readers announce the resizing in percentages but I'm not sure that makes much sense for the purpose. Wouldn't it be more useful to know the current canvas size in px? In any case, given the 6.2 resize handle doesn't announce anything, that's fine to iterate on for 6.4.
Yes, we can do that 👍 |
…dd/defer-script-loading-strategy * 'trunk' of https://github.com/WordPress/gutenberg: (24 commits) Add filter to turn off Interactivity API for a block (#52579) Search: Remove unnecessary useEffect (#52604) Navigation: Simplify the useSelect for useNavigationMenus (#51977) Item: Unify focus style and add default font styles (#52495) Update Changelog for 16.2.1 Bump plugin version to 16.2.1 Avoid passing undefined `selectedBlockClientId` in `BlockActionsMenu` (#52595) Cover Block: Fix block deprecation when fixed background is enabled (#51612) Nav block: link text color inheritance fixes and tests (#51710) Stabilize defaultBlock, directInsert API's and getDirectInsertBlock selector (#52083) Fix console warning by improving error handling in Nav block classic menu conversion (#52591) Fix: Remove link action of Link UI for draft pages created from Nav block does not correctly remove link. (#52415) Lodash: Remove remaining `_.get()` from block editor and deprecate (#52561) Fix importing classic menus (#52573) ResizableFrame: Make keyboard accessible (#52443) Site Editor: Fix navigation menu sidebar actions order and label (#52592) correct a typo: sapce -> space (#52578) Avoid errors in Dimension visualizers when switching between iframed and non-iframed editors (#52588) Patterns: Add client side pagination to patterns list (#52538) Site Editor: Make sidebar back button go *back* instead of *up* if possible (#52456) ...
* ResizableFrame: Make keyboard accessible * Fix outline in Safari * Use proper CSS modifier * Add aria-label to button * Keep handle enlarged when resizing (Safari) * Add back visually hidden help text * Don't switch to edit mode * Make the handle a role="separator" * Revert to `button` * Switch description text to `div hidden` * Prevent keydown event default when right/left arrow * Change minimum frame width to 320px * Mention shift key in description text * Only render resize handle when in View mode
|
I just cherry-picked this PR to the update/first-batch-pre-RC1 branch to get it included in the next release: 4df1030 |
tellthemachines
removed
the
Backport to WP 6.7 Beta/RC
* Site Editor: Restore quick inserter 'Browse all' button (#52529) * Site Editor: Restore quick inserter 'Browse all' button * Remove leftover comment * Patterns: update the title of Pattern block in the block inspector card (#52010) * Site Editor Pages: load the appropriate template if posts page set (#52266) * This commit: - links the posts page to the homepage template when a post page is set - abstracts logic to get page item props * The Posts Page resolves to display the Home or Index template only. Adding a check to skip the Front Page * Showing homepage settings for posts pages that are set as the post page in reading settings * Post pages that have been set to display posts will redirect to first the home template, then the index template. The fallback is the post id of the page. * Reverted refactor of packages/edit-site/src/components/sidebar-navigation-screen-page/index.js Will do it in a follow up * Allow editing existing footnote from formats toolbar (#52506) * Block Editor: Display variation icon in the 'BlockDraggable' component (#52502) * Patterns: add option to set sync status when adding from wp-admin patterns list (#52352) * Show a modal to set sync status if adding pattern from pattern list page * Make sure the modal loads if post settings panel not open * don't load modal component at all if not new post * Simplify the sync status so undefined always = synced * Update packages/editor/src/components/post-sync-status/index.js --------- Co-authored-by: Ramon <[email protected]> * Revise LinkControl suggestions UI to use MenuItem (#50978) * Use "link" instead of "URL" for URL_TYPE * Use MenuItem for search create button * Use sentence case for "Create page" * Use a MenuGroup for search results * Use MenuItem for search item * Refactoring styles (WIP) * Preserve whitespace in results text * Reinstate result item information including permalink * Remove debugging CSS code * Reinstate CSS to control size of rich previews favicon * Remove other commented out CSS code * Reinstate selected styles * Remove more redundant CSS * Add some basic results hover/focus styling. Needs improving * Improve icon alignment * Update tests to handle wording changes * Remove inconsistent hover/focus style MenuItem already has hover/focus styles * Reinstate is-selected visual state * Update test to make sense in context of #51011 See #51011 * Fix locator for result text --------- Co-authored-by: Dave Smith <[email protected]> * Fix LinkControl mark highlight to bold (#52517) * Add 'reusable' keyword to Pattern blocks (#52543) * Fix missing Add Template Part button in Template Parts page (#52542) * Tweak copy for the reusable block rename hint (#52581) * Trim footnote anchors from excerpts (#52518) * Trim footnote anchors from excerpts * Add comments, fix spacing, appease linter * Site Editor: Reset device preview type when exiting the editing mode (#52566) * Make "My patterns" permanently visible (#52531) * Hide site hub when resizing frame upwards to avoid overlap (#52180) * Fix "Manage all patterns" link appearance (#52532) * Fix "Manage all patterns" link * Update focus style * Update navigation menu title size & weight in detail panels (#52477) * Update menu title size * Adjust font weight * Site Editor Patterns: Ensure sidebar does not shrink when long pattern titles are used (#52547) * Edit Site: Select templateType from the store inside the useSiteEditorSettings hook (#52503) * Add width to ensure ellipsis is applied (#52575) * Cover Block: Fix block deprecation when fixed background is enabled (#51612) * ResizableFrame: Make keyboard accessible (#52443) * ResizableFrame: Make keyboard accessible * Fix outline in Safari * Use proper CSS modifier * Add aria-label to button * Keep handle enlarged when resizing (Safari) * Add back visually hidden help text * Don't switch to edit mode * Make the handle a role="separator" * Revert to `button` * Switch description text to `div hidden` * Prevent keydown event default when right/left arrow * Change minimum frame width to 320px * Mention shift key in description text * Only render resize handle when in View mode * Fix importing classic menus (#52573) * use the same create hook for classic import * Remove redundant arg to hook --------- Co-authored-by: Dave Smith <[email protected]> * Site Editor: Fix navigation menu sidebar actions order and label (#52592) * Avoid errors in Dimension visualizers when switching between iframed and non-iframed editors (#52588) * Patterns: Add client side pagination to patterns list (#52538) Co-authored-by: Saxon Fletcher <[email protected]> * Site Editor: Make sidebar back button go *back* instead of *up* if possible (#52456) * Navigator: Add replace option to goTo() and goToParent() * Site Editor: Make sidebar back button go back instead of up if possible * Adapt template part hint copy (#52527) * Try "panel" instead of "page" * Update template-part-hint.js --------- Co-authored-by: George Mamadashvili <[email protected]> Co-authored-by: Glen Davies <[email protected]> Co-authored-by: Ramon <[email protected]> Co-authored-by: Miguel Fonseca <[email protected]> Co-authored-by: Rich Tabor <[email protected]> Co-authored-by: Dave Smith <[email protected]> Co-authored-by: Robert Anderson <[email protected]> Co-authored-by: James Koster <[email protected]> Co-authored-by: Andrew Serong <[email protected]> Co-authored-by: arthur791004 <[email protected]> Co-authored-by: Aki Hamano <[email protected]> Co-authored-by: Lena Morita <[email protected]> Co-authored-by: Andrei Draganescu <[email protected]> Co-authored-by: Saxon Fletcher <[email protected]>
|
Thanks for working on this ❤️
I'm not sure that would be what screen readers expect. The value of aria-valuenow is expected to be a decimal number. No pixels please. Once screen readers are provided with correct values for aria-valuenow, aria-valuemin, and aria-valuemax, then they are able to do their own calculations and provide users with some meaningful announcement. I don't think the ARIA specification tells anything about the 'format' of the announcement, this is left to each vendo implementation. We should just provide the values and let screen readers do their job. Theoretically, aria-valuetext could be used to override the screen reader behavior and provide a human readable text alternative of aria-valuenow, Seems a bit overkill to me though. |
Fixes #51267
What?
Adds back keyboard operability to the Editor Canvas frame resizing handle.
In addition, the "Drag to resize"
titleattribute is now moved to a proper Tooltip and is translatable.Why?
The changes in #49910 introduced a major accessibility regression.
How?
Make the resize handle focusable, and add keydown handlers for resizing.
Testing Instructions
Screenshots or screencast
CleanShot.2023-07-08.at.10.48.14-converted.mp4