-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Comments
What label do you propose? |
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. |
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. |
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. |
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. |
OK then I'd propose to add a
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 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. |
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":
The text was updated successfully, but these errors were encountered: