Use 'button' element instead of empty links

It looks semantic incorrect. I'm considering few points:

1. Although BUTTON can placed everywhere, mostly (I) think it is a form element and should be inside the form and act form behavior.
2. href can be omitted in HTML5, as a placeholder
3. div inside the tag is invalid

vtabs is bad for seo and UX. it should use #anchor point to fieldset. and active the tab when users navigate with example.com/#show-vtab

machine name, point to input #id?

tabledrag handle , I think it's absolutely don't need any button or a tag.

Just some random thoughts:

- Shouldn't this get both a quick accessibility and usability review?
- Is seven the only theme affected? Bartik can be used for admin tasks as well?
- regarding the tabledrag discussion: Maybe that got introduced here http://drupal.org/node/448292?page=1#comment-3107944

Clarifying title and correcting the category.

I agree with #5

+++ b/core/modules/system/system.theme.css

+ * Show buttons as links

Such styles commonly mean that some element is abused to do what another element is supposed to do.

This essentially reminds of our weird styling for collapsible fieldsets, which completely abuses the original/actual purpose of fieldsets. (see #1168246: Freedom For Fieldsets! Long Live The DETAILS.)

In this case, the abuse is much clearer, since the styles are lightweight and even the comment clearly states that it is restyling one element to pretend and appear to be another one.

-1 on the idea of abusing buttons for links.

Improving the link URL fragments/hashes where possible looks sensible though.

Needs review, but I don't have time.

- Must still be functional w/ keyboard only
- Must show visual indicator when focused
- Must be accessible with screen-readers
- Semantics must be intuitive, as they drive screen-reader user's perception of functionality (textual affordance)

Sounds like it passes the first two points, now just needs some screen-reader testing. Perhaps VO + Safari on Lion and VoiceOver or JAWS on FF or IE

Semantics must be intuitive, as they drive screen-reader user's perception of functionality (textual affordance)

it's links that are abused as button here not the other way around.

This issue didn't really gave me any pointers on why a button should be preferred over a hyperlink. So I went googling, and this actually made sense to me:
http://stackoverflow.com/questions/10510191/valid-to-use-a-anchor-tag-wi...

Looks good. Attaching screenshots for review.

Before patch

After patch

(content type / field admin page)

node/add/xxxx show/hide summary buttons

Looks good!

I'm not sure about the distinction between the use of a button or a link. You say "Links should always go somewhere.", however I always thought that links should be used for navigation and not for actions? So for example a page like this (screenshot); shouldn't all those links be buttons?

I think the visual aid should be "am I doing something?" (button) or am "I browsing somewhere?" (link), whether this action is trigger on a new page or via Javascript shouldn't be relevant to the end user.

Same with the 'Local Actions' (+ Add block), shouldn't that be buttons too?

Food for thoughts?

Forgot screenshot.

#17, How about this:

Button: do something on this page (or do something which requires a submit/refresh, but always automatically go back to this page).
Link: take me to a different page.

In this case:

• edit role / edit permissions takes you to a different page: should be a link (correct).
• add role is saves the role and shows (after submission) the same page again: should be button (correct)
• Same for "save order": should be button (correct)

If you define it as actions it becomes tricky: basically everything in the administrative overview is an action in some way... Hell, even going to a new section is an action. Everything you do is an action :).

I'd call it "actions on the same page". The rest should be <a>

I tested admin/structure/types/manage/article/fields for keyboard functionality. That seems to work fine.

Going back to #9 from @everett this still leaves:

- Testing with screen-readers (JAWS, VoiceOver, NVDA)
- Must show visual indicator when focused (this issue needs to be re-opened generally, previous effort in D7 #418306: Adding Visual Focus to Form Elements)
- Add semantics with ARIA -- roles role="button" aria-pressed="true" http://yaccessibilityblog.com/library/easy-fixes-to-common-accessibility...

I really don't understand this, the markup cleanup pretty much removes a usability feature?

I understand there is confusion that we from a markup sense apply the wrong element, but the feature that we have buttons that appear as links is still valid. We are long past an era, where users only understand buttons as buttons and links as links - testing has proved over and over again that this link pattern works. We use it for buttons that have a highly "decreased" importance.

I fully understand the need to fix the markup, but I do not agree with changing the styling to remove this usability feature and create aesthetic imbalance on a large number of pages.

AFAIK, aria-pressed is only required if a button is in a 'pressed' state (e.g. toggle button)

I didn't find an example where the pressed state should be pressed. Not sure if this does anything for empty links either.

So at the least this needs to be re-titled.

Provided that the markup is either button or link, and that the explicit aria role matches the visual design, I don't foresee any accessibility problems.

<button /> // A button
<a href="" /> // A link
<button role="link" /> // A button w/ link semantics (should look like a link)
<a href="" role="button" /> // A link with button semantics (should look like a button)

So just to summarize some previous points brought up earlier and which seem to be unresolved so far (and please correct me if I'm wrong!!!!!):

• Sun (#8) is against styling buttons as links because: "In this case, the abuse is much clearer, since the styles are lightweight and even the comment clearly states that it is restyling one element to pretend and appear to be another one." He is therefore against using buttons at al
• Bojhan (#21) is not opposed to changing buttons perse, but is opposed to NOT styling them like links.

Regarding the aria-role: isn't this what this topic is all about? Links added via js have the behavior of a button, but the looks of a link. If we make them semantically buttons, we don't need to add an aria role saying that they are semantically a link?

How they look shouldn't have anything to do with the aria role?

It will when it comes to writing up the patch.

However, it's secondary to defining how it should look.

Things like vtab buttons, if made a button not an anchor, might be a bit clunky to get the (selected tab) text associated with. The text has to be set in the innerhtml of the anchor now, but cannot be set as a hidden part of the value of the button.

So, yhea my review is above.

I'm warming up to this idea.

However, we need to (heavily) restyle these buttons to appear like links and visually clarify that they are triggering pure user interface actions on the same page, which do not involve concepts such as submitting data to anywhere or leaving the page.

The buttons also take up a lot more visual space than the links, which increases their importance, although their intended importance is very/super low. E.g., the "Show weights" button is way too distracting; the machine name "Edit" link is equally optional.

Especially the machine name [ Edit ] link was added to D7 and attempted to introduce a special .admin-link styling for quick UI action links. The goal was to provide a visual pattern that allows to put an action widget along with text output right next to it (i.e., Machine name: foo_bar [ Edit ]), having both the text and the link appear in one visual line and size. AFAIK, in particular this pattern was taken up by a couple of contributed modules for exposing similar links.

I think everyone is OK with this if we're able to fully retain the visual appearance, which is probably possible. (I especially care about the details outlined in #31)

Let's use modern selectors; i.e., button[role=link]

(that said, not sure whether that's over-specified; I guess that [role=link] could easily lead to false-positives)

#35:

IE8 supports it, so big +1 from me! Removing the class should also clean up the markup a bit (double +1). I'd support using button[role=link] for reasons you mentioned.

Reference:
http://kimblim.dk/css-tests/selectors/

Looks fine to me, so +1 for RTBC from my side.

#21 has never been addressed, so this is not RTBC at all.

Related, but not a duplicate (providing this here for convenience):
http://drupal.org/node/1342066

It worked for me, and didn't change anything visual. Since #39 I am gonna mark this RTBC

+++ b/core/themes/seven/style.cssundefined
@@ -6,11 +6,13 @@ body {
+button[role=link] {

can we add a quote to every attribute selectors ?

foo[type="bar"]

+++ b/core/themes/bartik/css/style.cssundefined
@@ -128,7 +128,7 @@ table,
+button {
   font-family: "Lucida Grande", "Lucida Sans Unicode", Verdana, sans-serif;
 }

seems like missing font declaration in *seven* theme. it needs "font-family: inherit;" or specified fonts

remove spacing problem in FF.

<button type="button" role="link">
Does it a button or a link ?

<button type="button|submit|reset">

The button is a clickable button, and does nothing related to submitting or resetting a form. Therefore type="button". But it is styled to look like a link (see earlier comments why): for consistency regarding accessibility role="link" is added.

Interesting I didnt know we are breaking with font-styling, that clearly needs to be fixed.

Semantically, I'm not very fan of the idea. <button> is a form-associated element, so you would expect it to be... associated to a form. The MDC page for <button> for example, specifies (emphasis mine):

form (HTML5)
The form element that the button is associated with (its form owner). The value of the attribute must be the id attribute of a
element in the same document. If this attribute is not specified, the element must be a descendant of a form element. This attribute enables you to place elements anywhere within a document, not just as descendants of their
elements.

Looking at HTML5 itself, the constraint seems to have been lifted. HTML5 defines a "form-associated element" as (emphasis mine):

A form-associated element can have a relationship with a form element, which is called the element's form owner.

I would recommend standardizing on:

<a role="button" href="#">

By the way, <button type="button" role="link"> is *just wrong* anyway. The definitions of the roles according to ARIA are:

role=button:

An input that allows for user-triggered actions when clicked or pressed.

role=link:

An interactive reference to an internal or external resource that, when activated, causes the user agent to navigate to that resource.

ARIA even adds:

If pressing the link triggers an action but does not change browser focus or page location, authors are advised to consider using the button role instead of the link role.

Using role="link" for pure styling purposes is an abuse of the role marker.

I give a +1 to this issue because I hate <a href="#"> with passion. But I still concerned by two things about it:

- I don't think majority of themers will replicate link styles to our "link buttons". This not gonna happen, unless there is a button slapping in their faces. Otherwise they will find some time later that "that obscure 'cancel' link just start looking like a button in my custom theme. WTF?".

I don't think this is critical, because we can count that base themes widely used like Zen can implement a link styles to buttons. But we should be aware about it anyway (i.e. we can't count that every link-styled-button will always look like a link just because that's what we do - so we should avoid texts link "click the link below to edit the machine name").

- Also, if we're styling buttons as links, it's important that we provide also, at least for default themes, styles for normal buttons to look like buttons, since that's what third party code expects buttons to be. If I put a Twitter box in my site, it probably will use as a button. I didn't look at the final result, so sorry if this is already addressed.

Also I agree with going back to class="link" instead of role="link". The role is clearly a button, that's why this issue exists in the first place.

There have been plenty of comments already, many referring to standards. I would just like to note that Links make it easy to open a page in another tab, another window, whereas Buttons don't provide that flexibility. And sometimes that makes the most sense, as in this case I think, since we're triggerring something javascript and it hardly makes sense to open another browser tab/window.

As I mentioned on IRC, if we want to standardize on <button> I would rather see <button type="button" class="link"> then: <button type="button" role="link">. Those are *not* links, but buttons visually styled as links (which is kind of wrong too).

- fix seven font in FF
- fix button padding in FF

Before:

after:

+++ b/core/misc/tabledrag.js
@@ -104,7 +104,7 @@ Drupal.tableDrag = function (table, tableSettings) {
+  $table.before($('<button class="link tabledrag-toggle-weight"></button>')

+++ b/core/misc/tableresponsive.js
@@ -35,7 +35,7 @@ function TableResponsive (table) {
+  this.$link = $('<button class="link tableresponsive-toggle"></button>')

Missing type=button.

We always need that to prevent a button from being misinterpreted as a form submit button (type=submit is the default).

+++ b/core/modules/system/system.theme.css
@@ -179,6 +181,21 @@ abbr.form-required, abbr.tabledrag-changed, abbr.ajax-changed {
+label button.link {
+  font-weight: bold;
+}

Can't we merge this into button.link and simply say

font-family: inherit;
font-size: inherit;
font-weight: inherit;

?

+++ b/core/themes/bartik/css/style.css
@@ -1102,13 +1105,10 @@ a.button {
+/* Remove firefox focus padding */
+button.link::-moz-focus-inner{
+  padding: 0;
 }

Hm. I don't know off-hand what the exact rules for system.theme.css are, but if we need that FF fix in all themes, we should consider to move it into system.theme.css?

Aside from these issues, this looks good to go. So let's get those last bits quickly done and resolve this issue.

Regarding final tests, I'd like to request before/after screenshots for:

1) Stark, Bartik, Seven
2) I'd also like to see + confirm that the machine name widget still looks and works as expected.

Lastly, there are a couple of possible follow-up improvements that could be investigated after this has landed:

- Consider adding a new render #type for link buttons?
- Convert confirmation form "Cancel" links to link buttons?
- Convert "Delete" form buttons to link buttons?
- Investigate conversion of span.admin-link pattern to the new link buttons (used by machine name)

The patch no longer applied. Rerolled.

- Added the missing type="button" as noted by @sun.
- The -moz-focus-inner issue @sun noted is no more, thanks to normalize.css, which includes it (added in #723392: Tame seven's reset.css, and deleted seven's reset.css). Hence the changes to reset.css are no more; but this does not show up in the interdiff because the patch above didn't apply anymore.

Testing: machine name works fine, collapsible fields too, as does the "Show weights" table drag button and the "Edit summary". Everything still looks identical.

- Consider adding a new render #type for link buttons?

I agree that this can be useful, especially if we want contrib to use this too. Secondly, we should then also provide Drupal.theme.linkButton() (or whatever the appropriate name would be), which would have helped prevent the missing type="button" in the first place.

- Convert confirmation form "Cancel" links to link buttons?
- Convert "Delete" form buttons to link buttons?

These sound sensible to me.

+++ b/core/themes/seven/style.css
@@ -621,7 +623,6 @@ a.button,
-a.button,

We should keep these styles, regardless of this issue. Styling links as buttons is a perfectly legit use-case that should be retained, regardless of how our JavaScript wants to inject buttons.

+++ b/core/themes/bartik/css/style.cssundefined
@@ -1115,6 +1120,11 @@ a.button:active {
+/* Remove firefox focus padding */
+button.link::-moz-focus-inner{
+  padding: 0;
+}

Huh? Why did you add these? See my comment at #60.

Other than that, this looks good to go?

What do we need here to get to RTBC? A final sign-off from sun or Damien Tournoud?

Found a little bug, for keyboard users, missing tab focus styles.

hmm. Seven ?

Edit summary

+++ b/core/modules/text/text.jsundefined
@@ -22,19 +22,19 @@ Drupal.behaviors.textSummary = {
+      var $link = $('<span class="field-edit-link"> (<button type="button" class="link link-edit-summary">' + Drupal.t('Hide summary') + '</button>)</span>');

missing link:focus.

ack -a 'link:focus'
core/themes/bartik/css/colors.css
39:.link:focus {

core/themes/bartik/css/style.css
21:.link:focus {

core/themes/bartik/css/style.css
1105:.button:focus,

core/themes/seven/jquery.ui.theme.css
365:.ui-dialog .ui-dialog-buttonpane button:focus {

core/themes/seven/style.css
626:.button:focus,

shouldn't it move to system base style sheet?

Oh, there are too many problems with buttons. Assuming you wan’t to style them nicely.
On FF you need to kill the inner focus, on IE you need hacks to vertically center the text (different hacks for different versions), on Opera you need to kill the “press-down” effect. Too much CSS hackery and generally not worth the trouble.

rel: http://www.nczonline.net/blog/2013/01/29/you-cant-create-a-button/

Ouch, I've done some more tests. and only FIREFOX has "focus styles" problem.

Keep Drupal.t('Hide summary') as it will be toggled if no summary is set.

I can't understand why we should move the CSS though, colors are proper to each theme, only placing properties like text-decoration in system theme could be relevant.

I found a little typo though, so rerolling.

This patch is part of the #1day1patch initiative.

Hey, maybe better to properly implement "button" element that rendered as submit now. There's a some issues asked for this #289240: There is no way to make a button element that can use the AJAX functionality #72855: form #type 'button' does not work as advertised - it's always a submit
This require only a small changes but bring more consistency in theme layer

#72: core-js-button-1719640-72.patch queued for re-testing.

#72: core-js-button-1719640-72.patch queued for re-testing.

#78: core-js-button-1719640-78.patch queued for re-testing.

Where should we go to test this? I'd have thought admin/people/roles but that doesn't seem to be it.

Looked in a few folks with firebug to seek out a reference to <button> but kept coming up blank.

What's the best way to test this? I'd love to eliminate the empty links.

Tested on Chrome, Firefox, IE8, and iPad. Looking good

+1 RTBC

I still think we need to refactor 'button' core element to have no confusion and usage in follow-up issue

I can't quite parse that either, but it says follow-up, so I think we're good to go here.

Committed and pushed to 8.x. Thanks!

Hope this didn't break anything. ;)

It is really used all over the place. It's a great step ahead though not to use the empty links. Great work!

Thanks @nod_ these don't really cut the places where these changes are found, but I took a quick zip around after @webchick's commit.
node/add/article
admin/structure/block
admin/structure/contact/manage/feedback/fields
admin/structure/menu/manage/admin/edit
admin/structure/custom-blocks/manage/basic/fields
admin/structure/types/manage/article/fields

Some ref / info worth to read:
http://www.nczonline.net/blog/2013/04/01/making-accessible-icon-buttons/

Thanks for the link. Definitely interesting.

It's different in a few places though aside from not using Font Awesome. This patch introduces buttons with Javascript, while the author is concerned with ensuring buttons are available with javascript disabled.

I think the a Drupal version of this would be something like <button type="button"><span class="element-invisible">Email</span></button>

As I read the patch, these two lines will insert a blank button:
+ $table.before($('<button type="button" class="link tabledrag-toggle-weight"></button>')
+ this.$link = $('<button type="button" class="link tableresponsive-toggle"></button>')

In which case this could be improved to include text like the other buttons of this patch.

@droplet is that how you read this?

Great that this is fixed in D8, just adding this as a resource for folks who stumble across this thread in the future. Love Karl's quote here "if it looks like a button and acts like a button, what compelling reason is there to not just use a button?"
http://www.karlgroves.com/2013/05/14/links-are-not-buttons-neither-are-d...

add S.O. link