W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2016

RE: links as buttons and buttons as links

From: Adam Cooper <cooperad@bigpond.com>
Date: Thu, 14 Jul 2016 18:34:14 +1000
To: <w3c-wai-ig@w3.org>
Message-ID: <003b01d1ddaa$81123d10$8336b730$@bigpond.com>
Someone jump in if I am way off track, but I'm pretty sure that any CSS that
can be applied to one can be applied to the other . and be supported in
contemporary browsers. 

 

It is an interesting question - is there a need any more for both?

 

 

 

 

From: Sean Murphy (seanmmur) [mailto:seanmmur@cisco.com] 
Sent: Tuesday, July 12, 2016 9:00 PM
To: Adam Cooper; w3c-wai-ig@w3.org
Subject: RE: links as buttons and buttons as links

 

All,

 

I am going to ask a real interesting question.

 

>From my understanding, developers use Links as Buttons so they can make them
more visually apealing. If I am correct, then why doesn't the browsers
provide more attributes to make the buttons with the same properties as a
link but is treated as a button? Wouldn't this address some of the
confusions of when to use it?

 

Sean 12/07/2016

From: Adam Cooper [mailto:cooperad@bigpond.com] 
Sent: Tuesday, 12 July 2016 7:02 PM
To: w3c-wai-ig@w3.org
Subject: RE: links as buttons and buttons as links

 

Hi Phil,

 

Yes, agreed - the rule of thumb that buttons are for actions and links are
for navigation is largely appropriate except for those blurry cases like
back and forward controls that are usually buttons but navigate between
pages .  

 

To put the question another way, is the correlation between the role
'button' and 'action tight as in the role of text' (i.e., text means can
only enter text)?

 

Should I recommend adding role="button" to anything that performs an action
regardless of what it looks like?

 

 

 

 

From: Phill Jenkins [mailto:pjenkins@us.ibm.com] 
Sent: Tuesday, July 12, 2016 10:58 AM
To: w3c-wai-ig@w3.org
Subject: Re: links as buttons and buttons as links

 

hmm, 3.2.4 Consistent Identification Level AA Components that have the same
functionality within a set of Web pages are identified consistently.

so, in my opinion it depends on your interpratation of the term "same
functionality" and the term "identified consistently". 

I note that in WCAG 2.0, the Glossary definitions are normative.  See the
definition of the first term "same functionality" in question below:

 <https://www.w3.org/TR/2008/REC-WCAG20-20081211/#samefunctionalitydef>
https://www.w3.org/TR/2008/REC-WCAG20-20081211/#samefunctionalitydef
same functionality 
same result when used 

Example: A submit "search" button on one Web page and a "find" button on
another Web page may both have a field to enter a term and list topics in
the Web site related to the term submitted. In this case, they would have
the same functionality but would not be labeled consistently.

so note that the definition does not explicitly use the HTML element or
WAI-ARIA Role in its definition of the term "same functionality".  The
definition does use the term "labeled consistently" in place of the term
"identified consistently", inferring to me that the term "identified" is at
least referring to the label, and may or may not include the "role" of the
HTML element.  HTML Elements and WAI-ARIA Roles, include "link (i.e.
anchor)", button, etc.  

However, In my opinion, a button and a link can often have the same result,
but shouldn't.  And, in my opinion, if a user is using an AT (screen reader,
magnifier, voice command, etc.) to navigate by button, and misses all the
links, or vice-versa, is navigating by link, and misses all the buttons,
then perhaps it is an AT problem to fix, or at least give the end user the
choice to include both. What is the real difference anyway if both elements
have the same results?

Having said that, there is general UX guidance out there and I agree with
most of it that explains when to use a button vs when to use a link:

 
<https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEw
j75bnX1OzNAhXE7iYKHZjED5sQFggeMAA&url=http%3A%2F%2Fuxmovement.com%2Fbuttons%
2Fwhen-to-use-a-button-or-link%2F&usg=AFQjCNHk6laxZLOvOCtrz5w6vGThhG5Z8g&sig
2=-AilQSF_4VtTXUce33R2cQ>         When to Use a Button or Link - UX Movement
        uxmovement.com/buttons/when-to-use-a-button-or-link/
        Aug 9, 2010 - The button and link have co-existed on websites for a
long time. ... in how you use links vs buttons so users get used to the
difference (whether ...

        Proper Use of Buttons and Links | Web Axe
        www.webaxe.org/proper-use-buttons-links/
        Sep 7, 2014 - After years of arguing for proper use of form elements
and link elements, others are finally doing the same. More recently, this
includes the ...

 
<http://www.blonde.net/blog/2015/09/21/ux-dilemmas-should-we-use-button-or-l
ink> UX dilemmas - should we use a button or a link? | Blonde Digital
 
www.blonde.net/blog/2015/09/21/ux-dilemmas-should-we-use-button-or-link
        Sep 21, 2015 - By Lauren Bowen, User Experience Designer. The
question of whether to use a button or a link seems small. But what starts
as a simple UX ...

 
<http://getlevelten.com/blog/randall-knutson/design-decisions-buttons-vs-lin
ks-fight> Design Decisions: Buttons vs Links. Fight!
 
getlevelten.com/blog/randall-knutson/design-decisions-buttons-vs-links-fight
        May 31, 2011 - There are pretty defined guidelines for when to use
buttons and when to use links and these are often not followed. The
relatively recent ... 
         
The main point is, please do the basics. When designing a website, ensure
controls with button-type behavior (interaction, affects the current page)
are designed and marked-up as buttons and regular text links (go to an
external page, anchor on page, or external document) are marked-up and
designed like text links (such as blue underlined text). 

In my opinion, the first two list items from Nicole's example have a similar
if not button-type result, while the second two have similar link-like
results, so I agree with the current use of the HTML elements:
        button (which opens a self-contained modal/dialogue window within
the app)
        link (which links outside the app to a web page)
and in my opinion, a design can mix buttons and links and plain text for
that matter in an order or unorder list.  Menu items are not list items and
are a different discussion.  

And, I recommend that the WCAG 2.0 editors add some notes and explanations
to the techniques to further give examples of "consistently identified" that
includes HTML Elements and/or WAI-ARIA roles. 
        
In summary, the WCAG guidance refers to labels, names, and text alternatives
as needing to be consistent (not identical) for the same results, but does
not explicitly refer to HTML elements and roles as having the same result
(or same functionality).  So the debate, design, and inconsistent
implementation will continue on whether a button and a link can have the
same (or different) result (or functionality).    

Better AT's and better authoring tools are our only help, Obi-won Kenobi!
___________
Regards,
Phill Jenkins, 
Senior Engineer & Business Development Executive
IBM Research - IBM Accessibility
 <http://www.ibm.com/able> ibm.com/able
 <http://www.facebook.com/IBMAccessibility> facebook.com/IBMAccessibility
 <http://twitter.com/IBMAccess> twitter.com/IBMAccess
ageandability.com
Received on Thursday, 14 July 2016 08:34:48 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 14 July 2016 08:34:48 UTC