WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Actionable roles vs behaviors

for

From: Ryan E. Benson
Date: Jun 20, 2017 2:52PM


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