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/
>
>