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

The blocks "appender" misses a label #4829

Closed
afercia opened this issue Feb 2, 2018 · 6 comments · Fixed by #5742
Closed

The blocks "appender" misses a label #4829

afercia opened this issue Feb 2, 2018 · 6 comments · Fixed by #5742
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Bug An existing feature does not function as intended

Comments

@afercia
Copy link
Contributor

afercia commented Feb 2, 2018

This was already mentioned in #4425 and #4539 then probably missed during the several iterations.

The blocks "appender" at the end of the blocks is an input field and misses a label. I'd like to remind, once again, all UI controls must be labeled. The preferred way would be a <label> element associated with for/id attributes. Alternatively, an aria-label attribute on the field can be acceptable.

Although this input field changes as soon as it's clicked or focused, assistive technologies have many other ways to get to input fields, and without a label an input field is announced just as "text":

appender unlabeled

@afercia afercia added [Type] Bug An existing feature does not function as intended [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). labels Feb 2, 2018
@youknowriad
Copy link
Contributor

What label do you propose?

@afercia
Copy link
Contributor Author

afercia commented Feb 2, 2018

It depends. I haven't followed closely, can you confirm this input field changes as soon as clicked or focused? If so, I'd argue it shouldn't be an input field in the first place.

@youknowriad
Copy link
Contributor

I think there's a reason why it's an input (maybe the writing flow, arrow navigation) but I don't remember exactly, I'll have to test again.

@afercia
Copy link
Contributor Author

afercia commented Mar 8, 2018

Any news on this? Ideally this shouldn't be a button. Once it gets clarified if this must stay an input for some reason or can be changed to a button, we can find a proper solution and add a proper label.

@youknowriad
Copy link
Contributor

After some investigation the block appender can't be a button because of the writing flow, if it's a button, using arrows to navigate to it from the post title or previous block won't work. We could create a special case in the writing flow by targetting this button but I'd rather not do this and keep the component generic.

Let's add a label instead.

@afercia
Copy link
Contributor Author

afercia commented Mar 19, 2018

OK then I'd propose to add a role="button". Although the second rule for ARIA usage states:

Do not change native semantics, unless you really have to.

https://www.w3.org/TR/using-aria/#second

The "unless you really have to" part is relevant here. The important thing is this input is announced as a button while exploring the content. After all, when it gets activated, it turns into a block.

Here's how it gets announced with a role="button" and a temporary label:

appender

This gives a proper feedback to users: they can understand activating that "button" (and they can do it from that list) adds a block. Suggestions for a proper label welcome. It would be nice the label could distinguish this control from the other "insert block controls", clarifying it adds a block at the end of the post.

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] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants