Comments: row action links and forms accessibility improvements

[afercia]

In the Comments screen, all the "row action" links behave differently depending if JavaScript support is on or off. The Reply and Quick Edit links are special cases, and #43376 is going to take care of them.

For all the other row action links except "Edit":

• when JavaScript is off, they behave like real links
• when JavaScript is on, they don't trigger navigation but they "do something" so for better semantics and accessibility they should have a role="button".

Basically, all the following links:

Approve / Unapprove | Spam | Trash 
Not Spam | Delete Permanently
Spam | Restore | Delete Permanently

should use the CSS class .aria-button-if-js so the related jQuery function in common.js adds the button role.

Additionally, in the Reply and Quick Edit forms the links "Cancel" and "Submit" (actually this link has different text depending on what it does) should be real buttons.

Lastly, in the edit post screen, in the Comments metabox, the "Add Comment" link should be a button:

[afercia]

Note: the above should be applied also to the similar links in the "Recent Comments" Dashboard widget.

[afercia]

43412.diff​ is a first pass for better link / buttons semantics. Some testing would be nice :)

• check in the comments lists pages and in the dashboard, all the UI controls work as expected
• check using a screen reader all UI controls that "do something" are announced as buttons, and UI controls that navigate to a page are announced as links.

Additionally, to start implementing the "proximity of controls" principle (see #40822) and to introduce consistency, the patch aligns the Reply and Quick edit forms buttons on the left. Screenshots:

before:

after:

Note: the same change applies to the Quick Edit form and the Reply form in the Dashboard.

[afercia]

Additionally, to start implementing the "proximity of controls" principle (see #40822) and to introduce consistency, the patch aligns the Reply and Quick edit forms buttons on the left.

To give more visibility to the "proximity of controls" issue, I'd be in favor of splitting this part in a separate ticket.

[afercia]

Discussed during today's accessibility bug-scrub an agreed we'd like to propose this for 4.9.9 consideration.

[audrasjb]

Hi,

5.0.3 is going to be released soon. We are currently sorting the remaining tickets in the milestone.

That would be awesome to get some UI/UX feedback on this one and a component maintainer validation. If not, we are going to address this in 5.1 which is coming in February.

[audrasjb]

Hi,

Per today's bug scrub, let's address this ticket in the next major, 5.1, scheduled in February.

That would be great to get a design feedback so this one can land in 5.1.

[afercia]

Re: the buttons, worth reminding placing related UI controls at the opposite sides of the screen is a huge accessibility barrier for low vision users. Person with a limited viewing field are able to view just a small portion of the screen at any time. Sometimes they use screen magnifiers at a very high zoom level. A button at the opposite side of the screen is basically invisible.

Also, worth reminding the discussion and design feedback given on the tracking ticket for the proximity of controls: https://core.trac.wordpress.org/ticket/40822#comment:9

Based on ​https://www.lukew.com/ff/entry.asp?571, I think we should:

• Have the primary action (like update, etc.) on the left, as a primary button.
• If relevant, list secondary actions immediately to the right of the primary action, as secondary buttons.
• List all negative action (cancel, delete) next, as links.

In most cases, the actions should be left aligned, to line up with the forms. This would happen on Settings, bulk edit screens, edit term screens, etc.

In the case of things like the theme modal, actions should remain centered (since the content within the modal doesn't follow the same left-aligned linear path as forms do).

These are the patterns I'd strongly recommend for better accessibility. If the concern is about avoiding clicks on the wrong button, then increasing the clickable area of the buttons would probably be a better option, as for example some mobile operating systems do (see screenshot below).

[afercia]

As said in a previous comment, I'd be in favor of splitting the "proximity of controls" part in a separate ticket. The 5.1 release beta 1 is today. Punting to 5.2 because there's a patch.

[afercia]

43412.2.diff​ removes the changes for proximity of controls, will split them in a separate ticket.

[afercia]

43412.3.diff​ updates the patch after [44757]

[afercia]

In 44759:

Accessibility: Comments: Improve links and buttons semantics and interaction.

With the exception of the "Edit" link, the "row actions" controls in the Comments table behave differently depending if JavaScript support is on or off.
When JavaScript support is off, they behave like links. When JavaScript support is on, they behave like buttons and they need to be buttons or have an ARIA role="button" added via JavaScript.

Lastly, the buttons in the Reply/Quick Edit form and the "Add Comment" in the edit post page meta box need to be buttons.

Fixes #43412.