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

Improve the block multi-selection and keyboard interaction #1308

Closed
afercia opened this issue Jun 20, 2017 · 2 comments
Closed

Improve the block multi-selection and keyboard interaction #1308

afercia opened this issue Jun 20, 2017 · 2 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). General Interface Parts of the UI which don't fall neatly under other labels.

Comments

@afercia
Copy link
Contributor

afercia commented Jun 20, 2017

Currently, it is possible to select multiple blocks dragging the mouse across multiple blocks. When there's a selection, text with the number of selected blocks appears on the top left together with a "Delete" button:

screen shot 2017-06-20 at 16 30 17

The button text is expanded with an aria-label Delete selected blocks, that's a nice improvement. However, the button is focused by default. Any unwanted press of the Spacebar or Enter key will delete the selected blocks. Not sure this is actually a good thing, as it might produce data loss. Maybe worth considering a safer interaction.

The "X" button on the right has an aria-label with a value Clear selected blocks. To me, that sounds like "empty the selected blocks content" while what it actually does is clearing the selection. I'd propose to improve the text to clarify the action.

The text with the number of selected blocks is within a <div> element. Personally, in PHP or HTML I wouldn't ever put text inside a <div> and I'd use some more semantic element. React doesn't require to always use divs. However, the whole semantics of the toolbar could be improved, as currently everything is inside a <header> element and I'm not sure this is the best option. I'd like to propose to discuss this in the next accessibility meeting (everyone's welcome!).

Other a11y issues:
I'm wondering how the blocks multi-selection should work when using a keyboard. I understand it's tricky and not even sure it should be done. Maybe the best option would be considering this feature as an advanced selection feature available to pointing devices only? Any considerations/ideas very welcome.

The selected blocks are indicated with color only. Mouse users with vision impairments might have serious troubles to identify the actual selected blocks, as the color change is very subtle. Ideally, there should be an additional indicator to highlight the selected blocks.

Not sure if the text with the number of selected blocks should be automatically announced by screen readers while it gets updated, will try to discuss this point in the next a11y meeting.

@afercia afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Jun 20, 2017
@mtias mtias added the General Interface Parts of the UI which don't fall neatly under other labels. label Aug 18, 2017
@afercia
Copy link
Contributor Author

afercia commented Nov 6, 2017

Many things have changed for the blocks multi selection. At the moment, I can't select via drag and drop. I can select with the keyboard. The selection management doesn't appear on the top any longer, but there's a "coming soon" message in the sidebar, where one of the tabs indicates the number of blocks selected:

screen shot 2017-11-06 at 19 09 56

@mtias maybe this one can be closed and the a11y concerns addressed in the multi-selection issue (I assume there is one)?

@mtias
Copy link
Member

mtias commented Nov 20, 2017

@afercia yes, agreed.

@mtias mtias closed this as completed Nov 20, 2017
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). General Interface Parts of the UI which don't fall neatly under other labels.
Projects
None yet
Development

No branches or pull requests

2 participants