E-mail List Archives
Thread: Link vs Button for "Cancel"
Number of posts in this thread: 24 (In chronological order)
From: Renato Iwashima
Date: Mon, Jan 08 2018 1:28PM
Subject: Link vs Button for "Cancel"
No previous message | Next message →
Hi,
I have a form that contains a submit button and a cancel link. The "cancel"
takes the user to another page thus behaves like a link.
But because it is a destructive action and is related to the form, I wonder
if it should actually be a button. If thats the case, does it mean I need
to implement JS to actually route the user to navigate to a different page?
Can I just leave it as a link?
Thanks!
From: Steve Faulkner
Date: Mon, Jan 08 2018 1:33PM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
>
> The "cancel" takes the user to another page thus behaves like a link.
does it have a href with a URL? if so sounds like a link to me
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
On 8 January 2018 at 20:28, Renato Iwashima < = EMAIL ADDRESS REMOVED = > wrote:
> Hi,
>
> I have a form that contains a submit button and a cancel link. The "cancel"
> takes the user to another page thus behaves like a link.
>
> But because it is a destructive action and is related to the form, I wonder
> if it should actually be a button. If thats the case, does it mean I need
> to implement JS to actually route the user to navigate to a different page?
> Can I just leave it as a link?
>
> Thanks!
> > > > >
From: JP Jamous
Date: Mon, Jan 08 2018 1:46PM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
In addition, I have found it to be an excellent UX design practice to use role="button" if the link is styled as a button visually. I cannot count the many times I would be interacting with a sighted user and state, "Click on the whatever link." The user would always say, "I don't see a link, rather a button." In some situations, it can be quite confusing.
I know this does not fall under WCAG, but I find it a best user experience for users across the board.
From: Renato Iwashima
Date: Mon, Jan 08 2018 2:11PM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
I thought about adding role="button" since it does visually look like a
button, but then someone mentioned to me that a button activates with space
bar while a link does not. If I add a role="button", would I have to
implement some javascript to handle space bar?
On Jan 8, 2018 12:46 PM, "JP Jamous" < = EMAIL ADDRESS REMOVED = > wrote:
In addition, I have found it to be an excellent UX design practice to use
role="button" if the link is styled as a button visually. I cannot count
the many times I would be interacting with a sighted user and state, "Click
on the whatever link." The user would always say, "I don't see a link,
rather a button." In some situations, it can be quite confusing.
I know this does not fall under WCAG, but I find it a best user experience
for users across the board.
From: Beranek, Nicholas
Date: Mon, Jan 08 2018 2:30PM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
Yes, you will need to add keypress event handlers for Enter key and Space bar to activate the element with role="button". Also, if the element is not natively keyboard-focusable, then you'll need to add tabindex="0".
This does beg the question: Why not just use a <button>? If you decide to go the button route for your "Cancel" action, then I suggest an HTML <button>.
Nick Beranek
Capital One
From: Renato Iwashima
Date: Mon, Jan 08 2018 2:35PM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
> This does beg the question: Why not just use a <button>? If you decide to
go the button route for your "Cancel" action, then I suggest an HTML
<button>.
Primarily because it behaves like a link, it has its own URL and just
navigate the user away to a different page. If I make it a button, I'd need
to implement javascript to navigate the user to a different page which
seems unnecessary.
This is probably an issue with the visual design (it shouldn't look like a
button). But at this point it isn't a change I can make or push back. So I
was wondering if just going with a link would be sufficient enough, without
role="button".
On Mon, Jan 8, 2018 at 1:30 PM, Beranek, Nicholas via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:
> Yes, you will need to add keypress event handlers for Enter key and Space
> bar to activate the element with role="button". Also, if the element is not
> natively keyboard-focusable, then you'll need to add tabindex="0".
>
> This does beg the question: Why not just use a <button>? If you decide to
> go the button route for your "Cancel" action, then I suggest an HTML
> <button>.
>
> Nick Beranek
> Capital One
>
>
From: Mr K M I Brown
Date: Mon, Jan 08 2018 2:39PM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
It's hard to tell without the design, but because the link goes somewhere a link is more appropriate.
If you can't change or influence the design, can you influence the text? Cancel feels like an action rather than a destination, could you make it clear to the user they'll go somewhere specific?
On 8 January 2018, at 21:35, Renato Iwashima < = EMAIL ADDRESS REMOVED = > wrote:
> This does beg the question: Why not just use a <button>? If you decide to
go the button route for your "Cancel" action, then I suggest an HTML
<button>.
Primarily because it behaves like a link, it has its own URL and just
navigate the user away to a different page. If I make it a button, I'd need
to implement javascript to navigate the user to a different page which
seems unnecessary.
This is probably an issue with the visual design (it shouldn't look like a
button). But at this point it isn't a change I can make or push back. So I
was wondering if just going with a link would be sufficient enough, without
role="button".
On Mon, Jan 8, 2018 at 1:30 PM, Beranek, Nicholas via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:
> Yes, you will need to add keypress event handlers for Enter key and Space
> bar to activate the element with role="button". Also, if the element is not
> natively keyboard-focusable, then you'll need to add tabindex="0".
>
> This does beg the question: Why not just use a <button>? If you decide to
> go the button route for your "Cancel" action, then I suggest an HTML
> <button>.
>
> Nick Beranek
> Capital One
>
>
From: Beranek, Nicholas
Date: Mon, Jan 08 2018 2:51PM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
I'm reminded of an article from Marcy Sutton about this very topic:
https://marcysutton.com/links-vs-buttons-in-modern-web-applications/
I know the argument, "if it looks like a button, then it should be a button." However I feel that maintaining the hyperlink is more appropriate here to satisfy user expectations, as others have mentioned. If the link does look like a button to you, then you may want to push back on design to have them make it appear as a hyperlink.
From: JP Jamous
Date: Mon, Jan 08 2018 3:50PM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
I agree with all of the folks who responded Renato. I personally prefer a link for its simplicity with the href. Also, a link is used to take the user to another page, whereas a button would need a JS function.
Yet, I had a strong feeling that the Cancel link might be styled as a button. I have witnessed this over and over. If you can push back at the designers, go for it. If not, you can keep it as a link and use role="button". That way, the screen reader would announce it as a button just to keep that harmony between visual and programmatic design.
I don't think the space bar is an issue at this point if you use role="button". You can activate a button using space bar with a screen reader running. For keyboard only users, they would most likely use the Enter key. I would not sweat over this one much.
From: Tim Harshbarger
Date: Mon, Jan 08 2018 7:45PM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
I think the javascript for either having an HTML button move the user to a new page or to make the control activate using space or Enter is trivial. I remember reading a brief article by Karl Groves that actually provides the javascript for setting up a link with role="button" to trigger using spacebar or enter. And the javascript for loading a new URL when the button is clicked is pretty simple.
Personally, I have a feeling that normal people (people who are not technologists like us) do not have such a technical view of links vs. buttons. That is why I tend to use the duck rule. If it looks like a duck, give it a role="duck". Better yet, if you want it to look like a duck, just use a real duck. Stop making flamingos look like ducks and then giving them role="duck". But that is just a personal opinion--and I have colleagues I respect greatly who have very different opinions on the matter.
From: Bim Egan
Date: Tue, Jan 09 2018 1:25AM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
I don't think the duck rule floats. It puts design over functionality, which
doesn't feel right at all. There are button-like links used on every page of
some web sites, it's a design decision. What really matters is what it does,
so that people who can't see the design can find the control type they need
and expect in the context of the page and that it behaves as expected when
it is activated. The people most exposed to roles are those using AT, who
rely on roles to give them a clue to what action will occur.
*Links take the user to a new page; same page links move focus to other
locations in the same page
* Buttons have a same page action or submit forms.
From: Lovely, Brian
Date: Tue, Jan 09 2018 7:04AM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
>>>>>>Personally, I have a feeling that normal people (people who are not technologists like us) do not have such a technical view of links vs.
buttons.
I support the "acts like a link = link, acts like a button = button" practice. I also tend to walk on the right in hallways, go through the right hand door, etc. I don't know if other people do this consciously or not, but I do see a significant percentage of people doing the same thing (I'm in the US, btw). I'm sure there are people to whom this doesn't occur (non-technologists, so to speak), but in general I think this is a good way to ensure foot traffic flow. Whether or not it is universally understood, the link/button practice is logical and will, worst case scenario, benefit those who are aware of it. Best case scenario, it will become universally accepted and will be a logical and useful practice, whereas assigning roles randomly will never provide any added benefit.
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: JP Jamous
Date: Tue, Jan 09 2018 7:35AM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
Brian,
I sure agree with you guys. Stick to proper HTML semantic. Unfortunately, that's not the facts of the real world.
I preach in all of my training classes and workshops to stick to proper HTML semantic. Yet, the resistance with the addition to presenting A11Y as a positive component of the SDLC force us to bend the rules.
High jacking a link is definitely not a proper HTML semantic, but HTML was all built wrong from the beginning. I am talking back into the 90's. That's why I love coding with strict languages like C++, C#.NET, VB.NET and SQL. One tiny mistake and that compiler gets ticked off and comes back at the developer with an angry face. I wish there is such a thing for HTML besides the W3C validator.
I think of those native coding languages as professional boxing, whereas HTML is street fighting. Use whatever means to win even if they are against the rules. *Smiles*
From: Birkir R. Gunnarsson
Date: Tue, Jan 09 2018 8:36AM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
It's a double edged sword.
If HTML was as strict as C# or what have you, I doubt the internet
would ever have took off.
Most people with a little patience can create a webpage. Not a
beautiful, attractive, interactive and rich webpage, but a functional
webpage that displays text and images.
If their compiler had failed their code for a small semantic error,
they would have given up.
But it makes HTML messy, confusing and allows people who don't have
the faintest idea how to code good HTML to have a website.
I'm in the "we're over analyzing" camp on links vs. buttons.
In fact I think the "cancel" action should be a link rather than a
button. It navigates you away from the page without taking an action
(granted it takes an implicit action by eliminating all the data you
provided).
The problem in this particular setup, in my opinion, is that the
cancel link shouldn't look like a button.
I wrote a long piece on links vs. buttons once. I never got around to
publishing it, but I became increasingly convinced that we are
spending too much energy focusing on this vs. other issues such as
keyboard accessibility, semantics, color contrast and clarity of
content.
If it has the approximate appropriate text for the job and if it shows
up in the expected location, the user will try to click it. A keyboard
only user will try to activate it. If spacebar doesn't work, he will
try the enter key, The enter key will work.
I'm not saying this discussion is invalid or that there isn't a
problem, I am just saying that this is hardly ever going to be a user
blocker.
Cheers
-B
On 1/9/18, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
> Brian,
>
> I sure agree with you guys. Stick to proper HTML semantic. Unfortunately,
> that's not the facts of the real world.
>
> I preach in all of my training classes and workshops to stick to proper HTML
> semantic. Yet, the resistance with the addition to presenting A11Y as a
> positive component of the SDLC force us to bend the rules.
>
> High jacking a link is definitely not a proper HTML semantic, but HTML was
> all built wrong from the beginning. I am talking back into the 90's. That's
> why I love coding with strict languages like C++, C#.NET, VB.NET and SQL.
> One tiny mistake and that compiler gets ticked off and comes back at the
> developer with an angry face. I wish there is such a thing for HTML besides
> the W3C validator.
>
> I think of those native coding languages as professional boxing, whereas
> HTML is street fighting. Use whatever means to win even if they are against
> the rules. *Smiles*
>
>
From: Don Mauck
Date: Tue, Jan 09 2018 8:50AM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
I disagree, from a training and support standpoint, if you tell someone to find a button, that's what they would expect to find. It is fine if you visual folks want things to look a certain way, but if you want it to look like a button, then at least use a "role=button". To me, any action control would be a button. Cancel may leave a page, however, I see in many of our applications "cancel" performs a partial page refresh, thus never leaving the page. I believe that in general, buttons perform actions and links take you somewhere even if it is on the same page.
I think we need to remember that not all users will understand that when told to find a "button," it could be a link instead. No need to make things any more convoluted than necessary.
From: Birkir R. Gunnarsson
Date: Tue, Jan 09 2018 9:15AM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
Yeah, I forgot to add to my last post that we should use ARIA to
replicate the element's visual appearance except in situations where
that might prevent the user from operating the control.
In the case of link that looks like a button, add a button role, for
the exact reasons that Don explained.
The developer chose to use the incorrect semantics for a button, but
it still looks like a button, and people will refer to it as a button,
they don't dig into the code. So the assistive technology user should
perceive it as a button.
On 1/9/18, Don Mauck < = EMAIL ADDRESS REMOVED = > wrote:
> I disagree, from a training and support standpoint, if you tell someone to
> find a button, that's what they would expect to find. It is fine if you
> visual folks want things to look a certain way, but if you want it to look
> like a button, then at least use a "role=button". To me, any action control
> would be a button. Cancel may leave a page, however, I see in many of our
> applications "cancel" performs a partial page refresh, thus never leaving
> the page. I believe that in general, buttons perform actions and links take
> you somewhere even if it is on the same page.
> I think we need to remember that not all users will understand that when
> told to find a "button," it could be a link instead. No need to make things
> any more convoluted than necessary.
>
>
From: Mallory
Date: Wed, Jan 10 2018 2:39AM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
We had a similar issue, and also decided we're stuck with a real link looking like a button.
Not only do buttons work with spacebar, but links offer context menus, show URLs at the bottom of the browser on hover/focus, and offer things like shift-enter or ctrl-enter for opening in a different context... so I'm wary of setting button roles on links if there's a URL better than "#".
On Mon, Jan 8, 2018, at 10:35 PM, Renato Iwashima wrote:
> > This does beg the question: Why not just use a <button>? If you decide to
> go the button route for your "Cancel" action, then I suggest an HTML
> <button>.
>
> Primarily because it behaves like a link, it has its own URL and just
> navigate the user away to a different page. If I make it a button, I'd need
> to implement javascript to navigate the user to a different page which
> seems unnecessary.
>
> This is probably an issue with the visual design (it shouldn't look like a
> button). But at this point it isn't a change I can make or push back. So I
> was wondering if just going with a link would be sufficient enough, without
> role="button".
>
> On Mon, Jan 8, 2018 at 1:30 PM, Beranek, Nicholas via WebAIM-Forum <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > Yes, you will need to add keypress event handlers for Enter key and Space
> > bar to activate the element with role="button". Also, if the element is not
> > natively keyboard-focusable, then you'll need to add tabindex="0".
> >
> > This does beg the question: Why not just use a <button>? If you decide to
> > go the button route for your "Cancel" action, then I suggest an HTML
> > <button>.
> >
> > Nick Beranek
> > Capital One
> >
> >
From: Robert Fentress
Date: Thu, Jan 11 2018 10:40PM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
I don't know what the right approach is, but if the argument is that it
should be coded as a link just because it takes you to a page, I don't
think it is that simple. The submit button may *also* take you to a
different page. Perhaps it would be better to think of it in these terms:
If it performs an action related to the form (such as cancelling the
process), then it should be treated as a button. Again, I see both sides,
but this might be another way to frame it.
On Jan 10, 2018 4:39 AM, "Mallory" < = EMAIL ADDRESS REMOVED = > wrote:
> We had a similar issue, and also decided we're stuck with a real link
> looking like a button.
>
> Not only do buttons work with spacebar, but links offer context menus,
> show URLs at the bottom of the browser on hover/focus, and offer things
> like shift-enter or ctrl-enter for opening in a different context... so I'm
> wary of setting button roles on links if there's a URL better than "#".
>
> On Mon, Jan 8, 2018, at 10:35 PM, Renato Iwashima wrote:
> > > This does beg the question: Why not just use a <button>? If you decide
> to
> > go the button route for your "Cancel" action, then I suggest an HTML
> > <button>.
> >
> > Primarily because it behaves like a link, it has its own URL and just
> > navigate the user away to a different page. If I make it a button, I'd
> need
> > to implement javascript to navigate the user to a different page which
> > seems unnecessary.
> >
> > This is probably an issue with the visual design (it shouldn't look like
> a
> > button). But at this point it isn't a change I can make or push back. So
> I
> > was wondering if just going with a link would be sufficient enough,
> without
> > role="button".
> >
> > On Mon, Jan 8, 2018 at 1:30 PM, Beranek, Nicholas via WebAIM-Forum <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> > > Yes, you will need to add keypress event handlers for Enter key and
> Space
> > > bar to activate the element with role="button". Also, if the element
> is not
> > > natively keyboard-focusable, then you'll need to add tabindex="0".
> > >
> > > This does beg the question: Why not just use a <button>? If you decide
> to
> > > go the button route for your "Cancel" action, then I suggest an HTML
> > > <button>.
> > >
> > > Nick Beranek
> > > Capital One
> > >
> > >
From: Mohith BP
Date: Thu, Jan 11 2018 11:28PM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
I prefer providing role button for the link. addition to the points
mentioned from the training and usability point is:
1. When a user uses brows mode navigation as the submit is a button
tries to find Cancel in the similar way with the 'B' key.
2. In general Submit, Login, Cancel are found as buttons hence users
may expect the same.
3. AS mentioned by others in the previous posts is the visual
appearance and interacting with sighted folks.
Thanks & Regards,
Mohith B. P.
On 1/12/18, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
> I don't know what the right approach is, but if the argument is that it
> should be coded as a link just because it takes you to a page, I don't
> think it is that simple. The submit button may *also* take you to a
> different page. Perhaps it would be better to think of it in these terms:
> If it performs an action related to the form (such as cancelling the
> process), then it should be treated as a button. Again, I see both sides,
> but this might be another way to frame it.
>
> On Jan 10, 2018 4:39 AM, "Mallory" < = EMAIL ADDRESS REMOVED = > wrote:
>
>> We had a similar issue, and also decided we're stuck with a real link
>> looking like a button.
>>
>> Not only do buttons work with spacebar, but links offer context menus,
>> show URLs at the bottom of the browser on hover/focus, and offer things
>> like shift-enter or ctrl-enter for opening in a different context... so
>> I'm
>> wary of setting button roles on links if there's a URL better than "#".
>>
>> On Mon, Jan 8, 2018, at 10:35 PM, Renato Iwashima wrote:
>> > > This does beg the question: Why not just use a <button>? If you decide
>> to
>> > go the button route for your "Cancel" action, then I suggest an HTML
>> > <button>.
>> >
>> > Primarily because it behaves like a link, it has its own URL and just
>> > navigate the user away to a different page. If I make it a button, I'd
>> need
>> > to implement javascript to navigate the user to a different page which
>> > seems unnecessary.
>> >
>> > This is probably an issue with the visual design (it shouldn't look like
>> a
>> > button). But at this point it isn't a change I can make or push back. So
>> I
>> > was wondering if just going with a link would be sufficient enough,
>> without
>> > role="button".
>> >
>> > On Mon, Jan 8, 2018 at 1:30 PM, Beranek, Nicholas via WebAIM-Forum <
>> > = EMAIL ADDRESS REMOVED = > wrote:
>> >
>> > > Yes, you will need to add keypress event handlers for Enter key and
>> Space
>> > > bar to activate the element with role="button". Also, if the element
>> is not
>> > > natively keyboard-focusable, then you'll need to add tabindex="0".
>> > >
>> > > This does beg the question: Why not just use a <button>? If you decide
>> to
>> > > go the button route for your "Cancel" action, then I suggest an HTML
>> > > <button>.
>> > >
>> > > Nick Beranek
>> > > Capital One
>> > >
>> > >
From: Patrick H. Lauke
Date: Fri, Jan 12 2018 1:56AM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
On 08/01/2018 20:46, JP Jamous wrote:
> In addition, I have found it to be an excellent UX design practice to use role="button" if the link is styled as a button visually. I cannot count the many times I would be interacting with a sighted user and state, "Click on the whatever link." The user would always say, "I don't see a link, rather a button." In some situations, it can be quite confusing.
If it doesn't behave like a button, don't add a role="button".
Regardless of the visual styling.
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
From: Patrick H. Lauke
Date: Fri, Jan 12 2018 2:00AM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
On 08/01/2018 20:28, Renato Iwashima wrote:
> Hi,
>
> I have a form that contains a submit button and a cancel link. The "cancel"
> takes the user to another page thus behaves like a link.
>
> But because it is a destructive action and is related to the form, I wonder
> if it should actually be a button. If thats the case, does it mean I need
> to implement JS to actually route the user to navigate to a different page?
> Can I just leave it as a link?
Making the link a button doesn't make it any less destructive. And it
should be fairly well understood by users that if they've filled in a
form, and then activate a link to another page, that their form won't be
submitted and the data potentially lost.
If you're really concerned that users would accidentally hit "cancel"
(regardless of whether it's a link or a button) and lose data, a better
approach would be to pop up an alert letting them know that if they
cancel now, their data will be lost...but to be honest, that's overkill
I'd say (unless it's a REALLY long and complex form, where losing the
data accidentally would really be a great annoyance).
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
From: Patrick H. Lauke
Date: Fri, Jan 12 2018 2:11AM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
On 08/01/2018 21:51, Beranek, Nicholas via WebAIM-Forum wrote:
> I'm reminded of an article from Marcy Sutton about this very topic:
>
> https://marcysutton.com/links-vs-buttons-in-modern-web-applications/
>
> I know the argument, "if it looks like a button, then it should be a button."
It's not always as cut-and-dried as that, though. It's quite common to
have things like "call to action" links styled to look button-like, and
to me that's a perfectly valid case for still using a link, while also
visually highlighting the link for prominence.
What counts is the intent/action, not the appearance (unless the
appearance strongly suggests an intent/action in and of itself).
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
From: Birkir R. Gunnarsson
Date: Fri, Jan 12 2018 5:04AM
Subject: Re: Link vs Button for "Cancel"
← Previous message | Next message →
That touches on a different subject that has been discussed on Twitter.
There is no ARIA )or an equivalent easy to use standard way) to
indicate primary calls to action for a screen reader.
IN fact, using role="button" can be the closest we get to it (since
CTAs often visually look a bit like buttons).
I think the fact that something is highlighted as the primary action
on a webpage is visual information that needs to be communicated.
I am hoping we can get something like aria-primary into the ARIA 2.0 standard.
Alternatively, we could add a toen value to aria-current something
like aria-current="action".
ON the link vs. button argument, where would you fall on back and
continue (or right/left arrow actions) in a multi-page form?
YOu could say these are links because they take you to another page,
and they do not cause information to be submitted.
ON the other hand, they do update information in a database (at least
temporarily, and at least the next/continue control does).
Also they need to be easily distinguisable for a screen reader and
users expect these controls to be buttons, from operating system
experience.
Point is, this is not always cut and dry, and I still think we read
way more into this than a user does.
I started on the functional aspsect of the spectuum myself, but by now
I believe the assistive technology experience should reflect the
visual appearance.
After all, if it performs the action of a link, all users, not just
screen reader users, should perceive it as a link. So try to get the
developers to change the stling to match the functionality as a first
step.
If they refuse, deceive all users equally.
On 1/12/18, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 08/01/2018 21:51, Beranek, Nicholas via WebAIM-Forum wrote:
>> I'm reminded of an article from Marcy Sutton about this very topic:
>>
>> https://marcysutton.com/links-vs-buttons-in-modern-web-applications/
>>
>> I know the argument, "if it looks like a button, then it should be a
>> button."
>
> It's not always as cut-and-dried as that, though. It's quite common to
> have things like "call to action" links styled to look button-like, and
> to me that's a perfectly valid case for still using a link, while also
> visually highlighting the link for prominence.
>
> What counts is the intent/action, not the appearance (unless the
> appearance strongly suggests an intent/action in and of itself).
>
> 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
> > > > >
--
Work hard. Have fun. Make history.
From: Lovely, Brian
Date: Fri, Jan 12 2018 6:53AM
Subject: Re: Link vs Button for "Cancel"
← Previous message | No next message
Perhaps more to the point: "If it's going to behave like a button, design it to look like a button, then either use a button element or code it to announce and behave like a button"
On 08/01/2018 21:51, Beranek, Nicholas via WebAIM-Forum wrote:
> I'm reminded of an article from Marcy Sutton about this very topic:
>
> https://marcysutton.com/links-vs-buttons-in-modern-web-applications/
>
> I know the argument, "if it looks like a button, then it should be a button."
It's not always as cut-and-dried as that, though. It's quite common to have things like "call to action" links styled to look button-like, and to me that's a perfectly valid case for still using a link, while also visually highlighting the link for prominence.
What counts is the intent/action, not the appearance (unless the appearance strongly suggests an intent/action in and of itself).
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 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.