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

RE: links as buttons and buttons as links

From: Harry Loots <harry.loots@ieee.org>
Date: Thu, 14 Jul 2016 09:59:32 +0100
Message-ID: <CA++-QFfWPuq0L45xdMGwZKAAEmkNsntdpC2gfTgdb9qcT6M-eQ@mail.gmail.com>
To: Adam Cooper <cooperad@bigpond.com>
Cc: W3C WAI ig <w3c-wai-ig@w3.org>
Good ux designers will avoid using links as buttons, and will consistently
apply this throughout the sure.  A button suggests an action,  a link
navigation.  And that's how it should be maintained so that all users may
understand the conventions and know what to expect.
Unfortunately once the designer step out and the site manager takes over
their love for making changes to a well thought out convention, based on
subjective viewpoints will often lead to exactly the kind of confusion
described in this issue.
Kindest, Harry
On 14 Jul 2016 09:52, "Adam Cooper" <cooperad@bigpond.com> wrote:

> The original question was whether using different roles on different pages
> for the same operation was an issue for precisely the reasons you identify
> - namely, expectation that  role x on one page performs y so I can
> reasonably expect to find the same operation with role x elsewhere...
>
> As a screen reader user, I ffind it (very mildly, admittedly) irritating
> to have operations that one would expect to be associated with a link
> associated with a button and vice versa ... but is this just - as I think
> someone said previously - how this or that screen reader has implemented
> this?
>
>
>
>
> -----Original Message-----
> From: Elizabeth Pyatt [mailto:ejp10@psu.edu]
> Sent: Tuesday, July 12, 2016 11:15 PM
> To: Sean Murphy (seanmmur)
> Cc: Adam Cooper; w3c-wai-ig@w3.org
> Subject: 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 Thursday, 14 July 2016 09:00:04 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 14 July 2016 09:00:05 UTC