Re: links as buttons and buttons as links

To me this seems to be a classic case of visual design acting to blue the semantics between BUTTON and LINK (A tags).  This is OK for visual users because most are able to distinguish either underlined text (class link styling) or text in colored boxes with a border/icons (buttons or links) as “clickable” items.  For us, the distinction has been blurred.

Unfortunately, the same isn’t always true on a screen reader. So as I mentioned before, I have seen people on screen readers miss buttons acting as navigation because they were just going through the list of LINKs (A tags).

There are definitely ambiguous cases, so when in doubt I would recommend is usability testing with people using a screen reader if possible, with or without ARIA.  Assigning an ARIA role to a tag not normally in the semantic range can be problematic in a lot of cases. It’s also not 100% consistent across screen readers, especially older versions of screen readers.

FWIW - I think a screen reader user is more likely to detect a button when it is enclosed in a FORM tag.

You can definitely use CSS to make a link look like a button and a button look like a link, but the screen reader will almost always rely on semantics. So it’s best to understand how they are being used.

Another two cents.

Elizabeth


> On Jul 12, 2016, at 6:59 AM, Sean Murphy (seanmmur) <seanmmur@cisco.com> wrote:
> 
> 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
> 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:
> 
>         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 ...
> 
>         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 ...
> 
>         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
> ibm.com/able
> facebook.com/IBMAccessibility
> twitter.com/IBMAccess
> ageandability.com
> 

=-=-=-=-=-=-=-=-=-=-=-=-=
Elizabeth J. Pyatt, Ph.D.
Instructional Designer
Teaching and Learning with Technology
Penn State University
ejp10@psu.edu, (814) 865-0805 or (814) 865-2030 (Main Office)

210 Rider Building  (formerly Rider II)
227 W. Beaver Avenue
State College, PA   16801-4819
http://www.personal.psu.edu/ejp10/psu
http://tlt.psu.edu

Received on Tuesday, 12 July 2016 13:15:51 UTC