WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Actionable roles vs behaviors

for

From: Birkir R. Gunnarsson
Date: Jun 20, 2017 3:50PM

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


--
Work hard. Have fun. Make history.