#34867 closed enhancement (fixed)
Introduce a CSS class which identifies elements that are either links or buttons depending on JS presence
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.5 | Priority: | normal |
Severity: | normal | Version: | 4.4 |
Component: | Administration | Keywords: | has-patch has-screenshots |
Focuses: | ui, accessibility, javascript | Cc: |
Description (last modified by )
This ticket is related to issue #26504 and specifically comment #28.
ARIA role of "button" should be added to edit linked when javascript is enabled. This will assist those visitors using screen readers because the number of elements reported as links will be significantly fewer. For example, on the Categories page in the .row-actions links div, each of these links are actually buttons if javascript is enabled, however they are currently being reported as links. This is correct when javascript is disabled because they are actually refreshing the page, but if javascript is enabled the action taken by these links is an AJAX call which does not link to any outside page.
Our proposal is to add a class to these types of elements if javascript is enabled. This may look something like .button-if-js (similar to the .hide-if-no-js class being used to toggle display of the .row-action "Quick Edit" link. If the .button-if-js class is present and javascript is enabled role="button" is appended to the element. This will limit the number of reported links on the page and the user will interpret the elements as buttons that take action without leaving the page.
This issue and proposal was identified at WordCampUS Contributor Day. We are working with the Accessibility group to submit a patch.
Contributors on this ticket include:
@garusky
@takayukister
Attachments (2)
Change History (10)
#3
@
9 years ago
- Focuses administration removed
- Keywords has-screenshots added
- Milestone changed from Awaiting Review to 4.5
- Owner set to afercia
- Status changed from new to assigned
- Version changed from trunk to 4.4
I'd strongly recommend this improvement: it's simple and effective. Just one line of JavaScript which provides a reusable solution that can be used in all similar cases across the admin.
For a detailed description of the issue, please refer to the mentioned comment and ticket: https://core.trac.wordpress.org/ticket/26504#comment:28
Looking back at this after WordCamp US 2015 the only thing I'd consider to improve is changing the CSS class name from button-if-js
to aria-button-if-js
because that's what it does. :)
The patch introduces also a first implementation on the Categories and Tags screens. Tested with Firefox+NVDA, the "Quick Edit" and "Delete" links (they act as buttons when JavaScript is on) are no more reported as links but as... buttons! See in the screenshot below, before and after the patch:
When navigating through elements, NVDA reads out:
before: Edit link Quick Edit link Delete link View link after: Edit link Quick Edit button Delete button View link
I'd like to outline that this is not just about abstract semantics. "Edit" and "View" being announced as links let users understand they will land on a new page while "Quick Edit" and "Delete" being announced as buttons will let them understand they "do" something.
#4
@
9 years ago
Just noticed that in this specific case of the Terms list table, we should make sure the links get again the role="button"
after a term gets saved, since the HTML gets rebuilt.
#5
@
9 years ago
Refreshed patch. Will get again the element with a aria-button-if-js
CSS class whenever any Ajax request completes. A bit dumb, not sure if there are better ways. Can't use MutationObserver for lack of support and looks like a bit overkill. Open to suggestions :)
In the proposed patch I tried to address the issue listed above.
More specifically I have added a generic JS rules that append the
role="button"
attribute to all the elements with abutton-if-js
class.In this patch I've enhanced the row-actions links in the Category's screen adding the
button-if-js
class to the Quick Edit and Remove links.The action taken by these links is an AJAX call which does not link to any outside page, so appending a role="button" attribute tell screen reader users that these are not simple links but button that take action without leaving the page.
This solution was discussed with @afercia
Any feedback more than welcome.