Comments form: Accessibility fixes for back-end #54393
Conversation
alexstine
added
[Focus] Accessibility (a11y)
|
Size Change: +133 B (0%) Total Size: 1.52 MB
ℹ️ View Unchanged
|
| @@ -33,6 +37,7 @@ const CommentsFormPlaceholder = () => { | |||
| name="comment" | |||
| cols="45" | |||
| rows="8" | |||
| aria-disabled="true" | |||
There was a problem hiding this comment.
Can we use disabled instead? Using aria-disabled makes the textarea still available to be focused and used, while disabled prevents anyone from using the textarea.
There was a problem hiding this comment.
This would cause an accessibility problem. Does read-only work?
|
Personally from a usability perspective, I find it very confusing that you're able to focus these elements but not be able to do anything with it. I think a label for the inert area saying "Preview of the comments form" would be way more clear IMO. |
|
Flaky tests detected in 085d07d. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6164108481
|
@youknowriad - the issue with using I agree that being able to focus items that are not available is also an odd experience. Marking the textarea and submit button as |
|
@youknowriad This might help clear things up. I created a sub-branch off this PR with a small tweak. https://github.com/WordPress/gutenberg/tree/comment-form-hidden-visuals-a11y-test If you build this, you will get the same experience screen reader users have. Just a description that says "Preview of comments form." Honestly, if you had only this information, would you know what to expect when you published this on the front-end? Thanks. |
|
Before After I am not a screen reader user, what I found surprising with this is that it did not tell me I was on a disabled text area, but "selectable text". When VoiceOver announces "Comment, you are currently on a selectable text", the text area is what has the visible focus outline. I think this is an improvement. I still found it confusing that I was not able to just get the information that this disabled form has one text area and one submit button, and perhaps also the text content of the "Leave a reply" H3 heading above the form. |
We already use the Focusability of disabled controls The editor provides a preview of the content. Visually, it does. But is also needs to provide a real preview to non sighted useers. Hiding content from assistive technologi is not the right direction to go. |
|
I don't mind this PR personally but I'm convinced that it's not the right thing even for screen reader users. We're not doing this to "hide things from user", we're doing this because it's not important for the user to know what's within these sections (forms) in the editor. IMO, it creates more confusion for the user. IMO, in the editor, when you insert a comment format that you can't interact with, it's better to say: "this is where the comment form is going to be placed", rather than saying: "this is the submit button of the comment form" but you can't do anything with that. It's a user experience choice, not an a11y fix. |
I'm sure no one has an intention of hiding things from the user. I know we all want to deliver a great experience to everyone, regardless of how you access it.
This is where things can get problematic. I'm sure you have no intention of sending this signal, but I think it's important to be aware of it. "It's not important for the user to know what's within these sections (forms) in the editor," raises the question -- which users? Which users get to know what's within the form, and which users don't? At the moment, visual users get an accurate and clear representation of the comment form in an non-interactive state. By allowing a screen reader access to the form, it provides a clear representation of the comment form in a non-interactive state. This is an accessibility fix to bring an equivalent, better experience for people who rely on screen readers. I think @alexstine's example does illustrate why having "Preview of comments form," is not an equivalent experience for screen reader users. This is not the experience we are providing to sighted users, nor is it a better experience. 
|
What?
Try to make the comments form on the back-end accessible.
Why?
Accessibility is important.
How?
inert.aria-disabledto fields.aria-describedbyto communicate that the form is disabled on the back-end to assistive tech.onSubmitevent handler to disable the form submission.Testing Instructions
aria-disabled.aria-describedbyattribute that points to a unique description which is wrapped in the visually-hidden<div>after the comments form.Testing Instructions for Keyboard
Screenshots or screencast