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: Tue, 12 Jul 2016 19:02:00 +1000
To: <w3c-wai-ig@w3.org>
Message-ID: <003b01d1dc1c$0d812ee0$28838ca0$@bigpond.com>
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:

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:

2=-AilQSF_4VtTXUce33R2cQ>         When to Use a Button or Link - UX Movement
        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
        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 ...

ink> UX dilemmas - should we use a button or a link? | Blonde Digital
        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 ...

ks-fight> 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!
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
Received on Tuesday, 12 July 2016 09:02:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 12 July 2016 09:02:36 UTC