WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Actionable roles vs behaviors

for

From: Karl Brown
Date: Jun 21, 2017 5:50AM

I'm in the camp of "button does a thing, link goes to a place, input=submit
sends a thing" myself, but I can see the argument for calling something
that looks like a button a button.

I have had the conversation with designers, and we've actually settled on
calling things a *call to action* rather than a *button*. This way the
designers aren't telling the developers "this is a button" - rather they're
saying "this is a primary call to action" and the developers have a bit
more freedom to decide on whether to mark it up as a link or a button (the
junior developers will usually ask, and the senior developers have the same
ideas I do so far).

I think for the use case Jennifer pointed out it comes down to the script a
training document or call centre colleague uses. I try to steer away from
"use the red button" or "click the *pay* button" by writing the script as
"choose *pay*" with a screenshot if it's for training, or "choose *Pay* -
it's under the list of items in your basket".

I'll admit I've been lucky and not found a use case that I couldn't
rephrase my way out of, yet. Sometimes the right choice of words saves a
lot of headaches.

On Tue, Jun 20, 2017 at 11:12 PM, Jeremy Echols < <EMAIL REMOVED> > wrote:

> I can't add much that hasn't been said, but I am 100% of the belief that
> links and buttons (and all HTML elements) have important semantic roles,
> and designers need to stop trying to choose one over the other based on how
> it "feels". I find myself constantly trying to make sure I stress the
> importance of using elements as they were intended, not based on how they
> look.
>
> I found this article rather interesting: https://marcysutton.com/links-
> vs-buttons-in-modern-web-applications/
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Birkir R. Gunnarsson
> Sent: Tuesday, June 20, 2017 2:51 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Actionable roles vs behaviors
>
> That is the problem though. Though I think we exaggerate the importance of
> an element's ssemantic role, nevertheless users of assistive technologies
> rely on those to a much larger extent than "regular" users.
> Those who can't see the screen (either not at all, or just a small
> portion) use the role of the element to predict what happens next and
> build expectations based off of that.
> So whether it is link vs. button or something else, semantics matter a
> heck of a lot more to people relying on assistive technologies.
>
>
> On 6/20/17, Ryan E. Benson < <EMAIL REMOVED> > wrote:
> > Tim,
> >
> >>if you have access to the designer, the designer should be the one to
> > explain their intent with regards to what that element is
> >
> > The problem, that I see, is designers don't really care. I was on a
> > forum the other day, and somebody mentioned automatic tools. The
> > click-click boom, you have an app type. I can't say what percentage,
> > but a fair amount seem to be fine with "I don't care what the HTML
> > looks like, as long as my project works." I kept my mouth shut, since
> > I didn't want to dig a hole, but I have seen a movement of thinking this
> way.
> >
> > --
> > Ryan E. Benson
> >
> > On Tue, Jun 20, 2017 at 3:59 PM, Tim Harshbarger <
> > <EMAIL REMOVED> > wrote:
> >
> >> I guess I will add my own thoughts to the discussion.
> >>
> >> Whether an element is a link or a button really is a design
> >> decision--not a development decision. My own thought is that, if you
> >> have access to the designer, the designer should be the one to
> >> explain their intent with regards to what that element is. If the
> >> designer is not available, then I go with the appearance.
> >>
> >> My observation is that designers (in modern web design) seem to have
> >> a variety of approaches and thoughts on how to use buttons and links.
> >> I do not think it is as simple as links take you to another page and
> >> buttons perform other types of actions.
> >>
> >> One way I look at UI's is as a conversation between the "author" and
> >> the "user". My role as an accessibility consultant is to ensure the
> >> communication is as accessible as possible to the user while
> >> maintaining the author's full intent. So I tend to be uncomfortable
> >> with interjecting my own biases on the design (even if I disagree
> >> with the design choices.) The time for me to debate design choices is
> >> during design. That is also why I feel strongly that accessibility
> >> must be a consideration during design.
> >>
> >> Of course, if I am involved in design discussions, one of my goals
> >> would be to persuade the designers to use elements in a consistent
> >> manner that matches potential user expectations. Of course, I suspect
> >> that good designs typically try to ensure that appearance and
> >> behavior support one another.
> >>
> >> Just some thoughts for whatever they are worth.
> >>
> >> Thanks,
> >> Tim
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> >> Behalf Of Ajay Sharma
> >> Sent: Tuesday, June 20, 2017 1:35 PM
> >> To: WebAIM Discussion List < <EMAIL REMOVED> >
> >> Subject: Re: [WebAIM] Actionable roles vs behaviors
> >>
> >> Hi,
> >> >
> >> As there is very fine line between links and buttons, but recently
> >> came across a paradigm that will help to figure out the right control
> >> for a specific purpose.
> >>
> >> every action on a site falls under two different categories:
> >> 1Actions where users affect the website's back-end or front-end
> >> 2Actions where users won't affect the website at all Actions where
> >> users affect the website itself is where you use a button.
> >> For example, sign-up and purchase actions are often buttons. The user
> >> in these situations are creating a new account and completing a
> >> monetary transaction, which are actions that affect the website's
> back-end.
> >> Creating
> >> new posts or making comments are actions that change a website's
> >> content and what the user sees. These actions affect the website's
> front-end.
> >> Whenever there's a change in the website's back or front-end is when
> >> you use a button.
> >> Actions where users won't affect the website are where you use a link.
> >> These are actions that take users from one page to another without
> >> changing anything on the website's back or front-end. The user is
> >> basically a spectator browsing through content. They aren't doing any
> >> actions that require more effort than clicking and viewing. The
> >> back-end and front-end of the website remains the same. It's these
> >> situations when you should use a link over a button.
> >>
> >>
> >> So, based on above assertion if it is a button then its better to
> >> code it as button and same goes out to links as well, to make sure
> >> that the control is actually what it appears visually.
> >>
> >>
> >> Anyways, its just one more point to this never ending discussion :)
> >>
> >> Cheers,
> >> Ajay
> >> > >> > >> archives at http://webaim.org/discussion/archives
> >> > >> > >> > >> archives at http://webaim.org/discussion/archives
> >> > >>
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > at http://webaim.org/discussion/archives
> > > > > >



--
Karl Brown
Twitter: @kbdevelops
Skype: kbdevelopment

Professional Certificate Web Accessibility Compliance (Distinction),
University of South Australia, 2015