WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 2 weeks ago

#26504 reopened task (blessed)

Semantic elements for non-link links

Reported by: GaryJ Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.8
Component: Administration Keywords: has-patch semantic-buttons a11y-task
Focuses: ui, accessibility, javascript Cc:

Description

Using the revenge.css bookmarklet on the dashboard gives a very clear indication that some of the links on there are semantically incorrect - they should be buttons, even if they should look like links.

The Actual Buttons Are Actual section of this article sums it up nicely why.

Unless the accessibility team have indicated otherwise, each of the 74+ occurrences (only counting PHP files, more in JS files) of links with href="#" should probably be a <button>, so that screen readers interpret it as a button that does something, rather than a link that takes you somewhere. It also reduces the number of links that can be pulled out of context.

Appearance isn't a problem either - taking the "See 3 more…" from the screenshot:

// Original:
<a href="#">See 3 more…</a>

// New (might benefit from ARIA attribute):
<button class="no-button">See 3 more…</button>

// Basic CSS:
.no-button {
    background: none;
    border: none;
    color: #0074a2;
}
.no-button:hover {
    color: #2EA2C9;
    cursor: pointer;
}

Attachments (1)

26504.patch (594 bytes) - added by joedolson 16 months ago.
Support spacebar activation of role=button links

Download all attachments as: .zip

Change History (52)

#1 @jdgrimes
4 years ago

  • Cc jdg@… added

#2 @joedolson
4 years ago

Agreed - if it behaves like a button, it should be a button. Speaking from the Accessibility team, this is a good suggestion. I'd recommend that this get broken up into discrete tickets, referencing buttons based on functionality/component or file, so that it's easier to handle, however -- as is, this is likely to end up as a mega ticket that nobody has the scope to handle...

#3 @sharonaustin
4 years ago

  • Cc sharon.austin.2014@… added

@GaryJ Would you mind if I took a crack at breaking this ticket up into smaller components? I'd like to lend a hand if I could.

#4 follow-up: @GaryJ
4 years ago

@sharonaustin,

Go ahead, knock yourself out with it :-)

#5 in reply to: ↑ 4 @sharonaustin
4 years ago

Replying to GaryJ:

@sharonaustin,

Go ahead, knock yourself out with it :-)

Okay, great--I'll try and get it done this weekend. I may be contacting you via email for further clarification as I break this down into smaller components, if that's okay.

#6 @sharonaustin
4 years ago

Ticket #26837 opened; I'd like a chance to check that I've handled the first ticket correctly before opening the rest of them for the admin screen. Any feedback is welcome.

#7 @nacin
4 years ago

  • Component changed from Accessibility to Administration
  • Focuses accessibility added

#8 @GaryJ
3 years ago

The <button> element implicitly has the role="button"§, but we could look at adding aria-pressed and aria-expanded attributes to the right elements, and updating with JS.

§ As per http://www.w3.org/TR/2013/WD-aria-in-html-20131003/#recommendations-table role="button" is needed if using aria-pressed since some browsers don't recognise the latter without the former being present.

#9 in reply to: ↑ description @afercia
3 years ago

Replying to GaryJ:

each of the 74+ occurrences (only counting PHP files, more in JS files) of links with href="#" should probably be a <button>

Just to point out there are also links with a URL fragment, e.g.:
<a href="#post_status" class="save-post-status hide-if-no-js button">OK</a>
which aren't used to point to a target within the current document but they're used as buttons so when searching for occurrences we should search for any link that *starts* with #. At the time of writing (revision 30292), I get 105 occurrences only counting PHP files in /wp-admin/

#10 @joedolson
3 years ago

  • Keywords close added
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Hey, Gary - if you could open individual tickets for specific areas that need these changes, that would be great - I'm closing this ticket in favor of more specific patches.

These would be great first bugs if they were small and more clearly defined; if you want to open them based on specific screens or files, that would be awesome.

#11 @afercia
3 years ago

  • Focuses ui added

Divs, spans that behave like buttons should be buttons for sure but thinking about links, as I see it we have two different cases:

  • links that should be buttons and already look like buttons
  • links that should be buttons but current design choices want to look like links

Ideally, we should serve all users the same content and just change them in buttons, for example:

https://cldup.com/Aqe453FDmO.png

Or, to keep the current visual, add to the second ones an ARIA role="button". Visually, they will look like links but their semantics would be "button". Worth nothing screen readers won't list them as links and they will announce them as (based on the example below):

Cancel button

https://cldup.com/Lkjd26iIXD.png

BTW this would work just for screen reader users. We would end up serving content with different semantics to different users. Not sure this is a good thing, fair way to say I'm pretty convinced it would be bad.

A third way could be trying to "fake" buttons with CSS to make them look like links, trying to rebuild hover/focus states. I'm not a big fan of this and not even sure it can be done.

Any thoughts and feedback more than welcome, especially from UI and design people. The functional part is clear, we need UI feedback :)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 years ago

This ticket was mentioned in Slack in #core by afercia. View the logs.


3 years ago

This ticket was mentioned in Slack in #core by afercia. View the logs.


3 years ago

This ticket was mentioned in Slack in #core by johnbillion. View the logs.


2 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 years ago

#18 @joedolson
2 years ago

Some notes from the February 25th accessibility team meeting discussing this ticket (https://wordpress.slack.com/archives/accessibility/p1424892308002647)

How to address whether a button or link should be changed:

Anchors with null or meaningless HREF values: href='#', no href, href='#something' where #something does not exist

  • Should be a button

Anchors with meaningful on-page HREF values href='#something' where #something does exist

  • Could be a either a button or an anchor

Anchors with meaningful off-page HREF values that are renderable (but actual behavior is AJAX)

  • Could be a link when JS not available, should be a button the rest of the time.

Anchors with meaningful off-page HREF values that are *not* renderable

  • Should always be a button, but perhaps the target should be made renderable

Buttons that direct to new locations on the same page

  • Could be either a button or a link.

Buttons that direct to new locations on different pages.

  • Should be a link.


With the 'either/or' cases, each button or link will need individual consideration, depending on the context of the control. If it could be an anchor, but is in the middle of a whole bunch of buttons, then it would probably be better UX to leave it as a button, for example.

For HTML, we'll be using the classes .button-link for buttons that should look like links.

To organize the work, we'll be creating new tickets. Each new ticket will pertain to a specific file that displays buttons or links that need to be changed. When creating patches, be sure to address both the file that displays the button or link and any JS files that manage the behavior of the control.

Name tickets with something consistent and meaningful, such as the file name and location of the file being worked on.

This ticket was mentioned in Slack in #accessibility by cheffheid. View the logs.


2 years ago

#20 @afercia
2 years ago

  • Focuses javascript added

Wondering how to approach links that behave like buttons when JavaScript is enabled but should behave like normal links when JS is not enabled, see Andrew Ozz's comment https://core.trac.wordpress.org/ticket/23760#comment:10

We can probably have both and show the link/hide the button when no-js.

For example, the "row actions" links, where Approve/Unapprove, Spam, Trash, Reply, Quick Edit, behave like buttons when JS is on. Only the "Edit" link always behaves as a real link regardless of JS support.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 years ago

#22 @DrewAPicture
2 years ago

  • Keywords close removed
  • Milestone set to 4.2
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Type changed from defect (bug) to task (blessed)

Reopening this to serve as a tracking ticket per a request from the a11y team.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 years ago

#24 @afercia
2 years ago

Going to work on /wp-admin/includes/media.php

This ticket was mentioned in Slack in #core by drew. View the logs.


2 years ago

#26 @DrewAPicture
2 years ago

  • Milestone changed from 4.2 to Future Release

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 years ago

#28 @afercia
2 years ago

Had an in-depth conversation on Slack Accessibility with @azaozz about no-js links, that's the case where:

Could be a link when JS not available, should be a button the rest of the time.

While that's technically possible, we couldn't find a clean, solid solution. Consider for example the "row actions" links (e.g. in the posts or comments listings). Except "Edit" (which is always a link), with no JS these links are fully functional and semantic, for example:

href="comment.php?c=5&action=trashcomment&_wpnonce=d635621ec8"

so, when no JS, that's a link with GET parameters and it just works. BTW, when JS is on, it acts like a button and uses an AJAX POST.

  • they should have been built as submit buttons using POST in the first place... unless there's a specific reason to use GET. But refactoring all the admin is out of question.
  • we could double the markup and serve links + buttons then hide the links when JS is on and hide the buttons when JS is off. But it would end up with ugly markup and ugly PHP.
  • we could transform the links into buttons with JS. A rabbit hole, especially about events: will break any directly attached events.

The only "clean" solution we could think of is to add via JS role=button on the links. This would help just users who use software that understand ARIA. For all other users, the semantic value of those links would still be "link".
Any thoughts more than welcome.

#29 @joedolson
2 years ago

I think that's a reasonable case for using role=button; the role exists for scenarios where it's an undue burden to convert to a real button, and this seems like exactly that case. Using role=button is something we can always keep an eye on in the future as a candidate for a later revision, if we feel it's necessary.

We should make sure to do testing with AT so that the AT interaction behaves as expected with the button role. We don't want this to report as a button but require activation as a link.

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


2 years ago

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


2 years ago

This ticket was mentioned in Slack in #core by afercia. View the logs.


2 years ago

#33 @garusky
21 months ago

Hi all,
today at WordCampUS Contributor Day, we have worked on a first solution to this topic of adding ARIA attribute role=button to links when needed.
Have a look.
Any feedback more than welcome.

Related: #34867

#34 @afercia
20 months ago

In 35947:

Accessibility: Add an ARIA role button to links that behave like buttons when JavaScript is on.

Introduces a simple way to give a proper semantics of button to links that behave
like UI controls when JavaScript is on and behave like actual links when JavaScript
is off. First implementation on the Terms list table.

Patch prepared during WordCamp US 2015 Contributor Day.

Props mcapybara, garusky, takayukister.

See #26504.
Fixes #34867.

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


16 months ago

#36 @joedolson
16 months ago

If we're going to add role=button, then we should also make sure that any relevant link can be activated by the spacebar, so that it behaves more like a button. Attached patch lets any link with the class 'aria-button-if-js' be activated using the spacebar.

@joedolson
16 months ago

Support spacebar activation of role=button links

#37 @joedolson
16 months ago

  • Keywords has-patch added

#38 @afercia
16 months ago

@joedolson not 100% sure about this, it seems to me we should consider 2 different cases:

Screen reader users
Screen readers understand role=button and they activate the control when using Spacebar. An example of this are the "Quick Edit" and "Delete" links in the Categories and Tags screens. When not using a screen reader, Spacebar doesn't work. When using a screen reader, Spacebar magically works. No need for any JavaScript.

Keyboard users (no AT)
They are not informed about role=button. Visually, they see a link. It is unlikely they're going to press Spacebar because the link looks like a link. By the way, it gets a bit more complicated because sometimes links are styled like buttons :) Probably we should make Spacebar work just in this case because what users "see" is a button and users will likely expect it behaves like a button.

Worth considering it's even more complicated than this because there are also low-vision users who use screen readers as an aid in their navigation. They will "see" links that look like links being announced as "buttons". Unrelated to your proposed patch actually, this already happens because of the class aria-button-if-js.

Thoughts?

#39 follow-up: @joedolson
16 months ago

I think that anytime we add an aria attribute that describes something as a button, it *must* be possible to operate it as a button. The fact that some users are unlikely to do so, because they're unaware it can be done, isn't going to have any impact. They'll still be able to activate it using enter.

Honestly, I'd rather that all our buttons looked like buttons; but if we're trying to minimize impact on the design of the admin, I can live with that.

Do all screen readers now add the space bar as a keyboard control for role=button?

#40 in reply to: ↑ 39 @afercia
16 months ago

Replying to joedolson:

Do all screen readers now add the space bar as a keyboard control for role=button?

JAWS, NVDA, VoiceOver do. VoiceOver needs the Control-Option-Space combination that is standard for buttons.

https://cldup.com/AOsKp85F8E.png

I think that anytime we add an aria attribute that describes something as a button, it *must* be possible to operate it as a button.

It is possible already, for technologies that understand ARIA. My concern here is while ARIA works only for assistive technologies users, that JavaScript bit will work for all users and basically it will alter the standard interaction with links for users that don't use AT.

#41 @joedolson
16 months ago

I don't think it will harm the user experience to have an additional option for using these link/buttons; and if somebody is using a future technology that reports ARIA information to them visually, it could be important in the future.

But I'm also uncomfortable with the idea of offering a different user interaction depending on what technology people use that isn't fundamental to their technology. I can easily imagine a scenario where a screen reader user is trying to instruct somebody on a task in WordPress, and they keep saying "tap the spacebar to quick edit", because that's how it works for them.

I don't like the "sort of a button" interaction model, regardless of the design of the element.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


15 months ago

#43 @ocean90
13 months ago

In 38031:

Accessibility: Add aria-button-if-js class to links in the media list table that behave like buttons when JavaScript is on.

Props joedolson, afercia.
See #26504.
Fixes #36555.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


11 months ago

#45 @afercia
11 months ago

Still a lot of work to do about non-links :) this ticket need some traction! Any help very welcome!

This ticket was mentioned in Slack in #accessibility by cheffheid. View the logs.


10 months ago

#47 @afercia
8 months ago

  • Keywords semantic-buttons added

#48 @afercia
3 months ago

  • Keywords a11y-task added

#49 @afercia
3 months ago

In 40578:

Accessibility: Make the Get Shortlink button be a real button.

Worth noting, as of WordPress 4.4, the Get Shortlink button is hidden by default
but it can be restored via filters.

Props Cheffheid.
See #26504.
Fixes #40448.

#50 @afercia
3 months ago

In 40646:

Accessibility: Change the "Show details" links in the update core screen to buttons.

These controls toggle the visibility of the update progress: they perform an action
therefore they should be buttons. Also:

  • uses aria-expanded to communicate the toggle button state
  • removes some inline JavaScript
  • when clicking the toggle buttons, the progress details get moved with JavaScript after the button: this helps users of assistive technologies in finding them and makes the UI a bit more intuitive

Props Cheffheid, afercia.
See #26504.
Fixes #40453.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 weeks ago

Note: See TracTickets for help on using tickets.