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

Content blocks need to be labeled #562

Closed
afercia opened this issue Apr 28, 2017 · 4 comments
Closed

Content blocks need to be labeled #562

afercia opened this issue Apr 28, 2017 · 4 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Task Issues or PRs that have been broken down into an individual action to take

Comments

@afercia
Copy link
Contributor

afercia commented Apr 28, 2017

When navigating through content blocks, assistive technologies need to report and inform users about what kind of block they just landed on. Content blocks need to be labeled someway, an din a way that screen readers can announce properly.

Currently, there's nothing that can be announced in the markup. Blocks are just always the same:

screen shot 2017-04-25 at 00 48 35

Maybe, and aria-label attribute on the focusable blocks (with an appropriate text to report the type of blocks) could help. This should be carefully tested though.

This relates also to #557 where the block mover should announce which kind of block it relates to.

Maybe, each block should carry a set of meta information available to be reused in other context. I see the state contains information about the blocks UID so maybe it should also contain a human-understandable name for each kind of blocks, to start with.

@afercia afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Apr 28, 2017
@aduth
Copy link
Member

aduth commented May 1, 2017

Any of the information registered by a block could be made available in the DOM for the block listing. There might be some localization considerations here too, perhaps a label like: "Editor block: Image", etc ?

@afercia
Copy link
Contributor Author

afercia commented May 1, 2017

Yep, or that or dedicated labels as the ones that must be provided for CPT registration, for example.

@afercia
Copy link
Contributor Author

afercia commented May 6, 2017

Thinking also at #666 (backspace to remove a block)

Blocks with editable text can be deleted by carefully clicking twice on the outer border of the block.

Maybe an option could be allowing both the outer container and the inner editable to be focused when tabbing through blocks. This is already possible when tabbing backwards.

Quick video to highlight focusable elements while tabbing forwards and backwards through blocks:
https://cloudup.com/cE8NzPqvHAY

To reproduce the current behavior:

  • focus a block and press tab
  • focus goes to the next block
  • Shift+Tab
  • focus goes to the outer container (that's interesting)
  • now Tab (forward) and you have access to the block mover and the toolbar

It would be interesting to evaluate to make the outer container focusable also when tabbing forward. In this scenario, the toolbar should be excluded from the tab sequence and a possible flow would be:

  • when tabbing, focus goes to the outer container first
  • the outer container has an aria-label attribute to identify the block type, e.g. Content block: Image
  • at this point the block can also be deleted with backspace
  • tab: focus goes to the block mover (one or two focusable buttons depending on the block position)
  • tab: focus goes to the editable content if any

Same when tabbing backwards.

Seems to me it would make sense to make the outer container easily reachable with a keyboard, since some actions are available only on the outer container, e.g.

  • delete
  • move up, move down,
  • maybe also change block type?

It would be sort of splitting controls in two different "layers", the outer one for actions specific to the block, the inner one for actions specific to the content.

@aduth aduth added the [Type] Task Issues or PRs that have been broken down into an individual action to take label May 26, 2017
@afercia
Copy link
Contributor Author

afercia commented Jun 7, 2017

Worth noting also other editable regions need to be labeled. For example the image caption is a contenteditable figcaption, but has no label at all. When entering there, there's no feedback about what it is.

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). [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

No branches or pull requests

2 participants