E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 12 (In chronological order)

From: Lovely, Brian (CONT)
Date: Mon, Jun 19 2017 11:14AM
Subject: Actionable roles vs behaviors
No previous message | Next message →

Hey all,

For purposes of screen reader users, I use the rule of thumb that if an actionable element performs an action on the current page it should be a button element, and if an actionable element directs the browser to another URL, it should be a link element. This is to be followed regardless of how the element is styled. If an element is styled as a button-like lozenge, but still directs the browser to another URL, it should be (or at least announce and behave as) a link.

However, I was recently reminded of the fact that sighted users of software like Dragon Naturally Speaking, may see an element that looks like a button and expect to interact with it like they would a button.

These seem like two irreconcilable views. Anyone have any suggestions on how to think about this issue?


Brian Lovely
Digital Accessibility Team
= EMAIL ADDRESS REMOVED =




The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.

From: Birkir R. Gunnarsson
Date: Mon, Jun 19 2017 2:47PM
Subject: Re: Actionable roles vs behaviors
← Previous message | Next message →

Oh no, you brought up the link vs. button (groan).

This is a never ending debate in the accessibility community. Two
idiots (well at least one of them is an idiot, yours truly) even had a
CSUN discussion panel dedicated to this very topic in fact:
http://linkvsbutton.a11yideas.com/

Honestly, this is a fascinating subject, but I think it is one where
we get so lost in our accessibility induced geekyness we forget the
effects for the user are relatively minor (compared with a lot of
other issues).

And, you are right, I don't think there is any one right answer for this.

If there is disagreement between the element used to implement
something (e.g. a link) and the way it is presented visually (e.g.
link styled as a button), should we lie to the assistive technology
user as well (by using role="button") or create a mismatch between the
perception of the a.t. user and the regular user (which is also
difficult, e.g. for speech recognition users, or if a screen reader
user is working with a non-screen reader user trying to locate the
element on the page, the sighted user will describe the element as a
button, so the screen reader user will look for abutton.

I think we sometimes read too much into what the users think and the
interaction differences.

If you can't activate something with aspace bar, you try the enter key
(so a link styled as a button is focusable and will work with the
keyboard, only not with the spacebar).

A screen reader user will activate the element and see what happens
(incidentally, in browse mode, you can use either the spacebar or
enter key to trigger the onclick event on any link or button element,
the screen reader sends a synthetic onclick event to the element when
you press either, so to those users the keyboard activation
differences don't matter).

There are situations where the diffeences become important.

* If you have a "delete" button, you expect that pressing it will
execute the function (something will be deleted). If it is a "delete"
link, you expect to be taken to a page where you can select and delete
the information. Of course, if the info is important (financial,
legal, or info in database systems) you should get a warning and a
chance to back out or confirm the deletion regardless of the element
you used (see WCAG 3.3.4).

I try to file issues and force developers to use a visual appearance
consistent ith the element purpose. Then I ask themto either use the
correct semantic HTML element to match that appearance, oruse ARIA to
fake it.
If the appearance is wrong, I advocate the the assistive technology
expeience be wrong as well.
Then I file an issue saying the wrong element was used.
-B



On 6/19/17, Lovely, Brian (CONT) < = EMAIL ADDRESS REMOVED = > wrote:
> Hey all,
>
> For purposes of screen reader users, I use the rule of thumb that if an
> actionable element performs an action on the current page it should be a
> button element, and if an actionable element directs the browser to another
> URL, it should be a link element. This is to be followed regardless of how
> the element is styled. If an element is styled as a button-like lozenge, but
> still directs the browser to another URL, it should be (or at least announce
> and behave as) a link.
>
> However, I was recently reminded of the fact that sighted users of software
> like Dragon Naturally Speaking, may see an element that looks like a button
> and expect to interact with it like they would a button.
>
> These seem like two irreconcilable views. Anyone have any suggestions on how
> to think about this issue?
>
>
> Brian Lovely
> Digital Accessibility Team
> = EMAIL ADDRESS REMOVED =
>
>
>
> >
> The information contained in this e-mail is confidential and/or proprietary
> to Capital One and/or its affiliates and may only be used solely in
> performance of work or services for Capital One. The information transmitted
> herewith is intended only for use by the individual or entity to which it is
> addressed. If the reader of this message is not the intended recipient, you
> are hereby notified that any review, retransmission, dissemination,
> distribution, copying or other use of, or taking of any action in reliance
> upon this information is strictly prohibited. If you have received this
> communication in error, please contact the sender and delete the material
> from your computer.
> > > > >


--
Work hard. Have fun. Make history.

From: Jennifer Sutton
Date: Mon, Jun 19 2017 4:39PM
Subject: Re: Actionable roles vs behaviors
← Previous message | Next message →

I'll toss out one idea folks may wish to consider when trying to decide
link or button.


I was vigorously informed that this was an "edge case" when I tried to
make this point on Twitter, so if you think it is, you're welcome to do
so. But I don't happen to, and I'd prefer to avoid another debate. Tia. :)


One circumstance where this can matter is when a screen reader user with
vision issues needs to talk about the UI with customer service, their
sighted colleague(s) in the work place, etc. It can be very confusing if
a sighted person is saying to activate the "blah" button, and I am
looking for that quickly with my button command, but it's not marked up
as such. Folks may dismiss this as a little thing, but when you're
trying to follow phone directions, or learn something for your job,
communication issues can really slow things down. Sure, I can do a
"search" on the screen to try to find the text for the link/button
label, but that doesn't always work (even if we might wish it would).


Whether or not this kind of thing is an "edge case" depends on your use
case(s)/user stories. Thanks for reading and considering.

My aim in responding is simply to note what I've experienced, as well as
what I've observed others experiencing.

I don't believe there is an easy solution.

But I do believe that folks who do functional testing with real users of
screen readers and text input may be gathering some very interesting
information about this topic.



Best,

Jennifer

From: Birkir R. Gunnarsson
Date: Mon, Jun 19 2017 5:47PM
Subject: Re: Actionable roles vs behaviors
← Previous message | Next message →

Jannifer
WE totally agree )I briefly mentioned this edge case in my response,
(which could have been worded better).
This is why I have started recommending that the assistive technology
representation of an element be consistent with its visual
presentation rather than with the out-of-the-box functionality of the
underlying element).
IN other words, if it is a link styled to look like a button, give it
a role of button regardless of whether activating it executes an
action or navigates.
If there is a mismatch between the element's appearance (to regular
users and assistive technology user) and its expected functionality,
file a usability issue, (or a minor case under WCAG 4.1.2 depending on
the element, the function, and the user expectation for that element).

I started out in the "go with the functionality" band camp before the
aforementioned CSUN panel, but the more I worked on examples and
thought about them, the more I felt that the assistive technology
presentation of an element should match its visual appearance.



On 6/19/17, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
> I'll toss out one idea folks may wish to consider when trying to decide
> link or button.
>
>
> I was vigorously informed that this was an "edge case" when I tried to
> make this point on Twitter, so if you think it is, you're welcome to do
> so. But I don't happen to, and I'd prefer to avoid another debate. Tia. :)
>
>
> One circumstance where this can matter is when a screen reader user with
> vision issues needs to talk about the UI with customer service, their
> sighted colleague(s) in the work place, etc. It can be very confusing if
> a sighted person is saying to activate the "blah" button, and I am
> looking for that quickly with my button command, but it's not marked up
> as such. Folks may dismiss this as a little thing, but when you're
> trying to follow phone directions, or learn something for your job,
> communication issues can really slow things down. Sure, I can do a
> "search" on the screen to try to find the text for the link/button
> label, but that doesn't always work (even if we might wish it would).
>
>
> Whether or not this kind of thing is an "edge case" depends on your use
> case(s)/user stories. Thanks for reading and considering.
>
> My aim in responding is simply to note what I've experienced, as well as
> what I've observed others experiencing.
>
> I don't believe there is an easy solution.
>
> But I do believe that folks who do functional testing with real users of
> screen readers and text input may be gathering some very interesting
> information about this topic.
>
>
>
> Best,
>
> Jennifer
>
>
>
> > > > >


--
Work hard. Have fun. Make history.

From: Ajay Sharma
Date: Tue, Jun 20 2017 12:34PM
Subject: Re: Actionable roles vs behaviors
← Previous message | Next message →

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

From: Lovely, Brian (CONT)
Date: Tue, Jun 20 2017 1:22PM
Subject: Re: Actionable roles vs behaviors
← Previous message | Next message →

From: Tim Harshbarger
Date: Tue, Jun 20 2017 1:59PM
Subject: Re: Actionable roles vs behaviors
← Previous message | Next message →

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

From: Ryan E. Benson
Date: Tue, Jun 20 2017 2:52PM
Subject: Re: Actionable roles vs behaviors
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Tue, Jun 20 2017 3:50PM
Subject: Re: Actionable roles vs behaviors
← Previous message | Next message →

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

From: Jeremy Echols
Date: Tue, Jun 20 2017 4:12PM
Subject: Re: Actionable roles vs behaviors
← Previous message | Next message →

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/

From: Karl Brown
Date: Wed, Jun 21 2017 5:50AM
Subject: Re: Actionable roles vs behaviors
← Previous message | Next message →

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

From: Patrick H. Lauke
Date: Wed, Jun 21 2017 6:57AM
Subject: Re: Actionable roles vs behaviors
← Previous message | No next message

On 21/06/2017 12:50, Karl Brown wrote:
> 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.

Echoing this from Karl. Well put. (I've stayed out of the discussion on
list, but had a bit of a tweetstorm last night anyway on the topic)...
https://twitter.com/webaim/status/877294402217037824

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke