RE: Buttons styled as links and links styled as buttons

I'm in that sighted keyboard group - I activate buttons with space, mostly out of "defense". On the web and on a desktop, the spacebar can often be canceled and/or is less of a "final" operation unless my focus is on some sort of "done with this thing" control. The enter key submits with a default operation, and that's that - close a window accepting whatever changes you made (desktop), submit a form (web), etc.

So I just make the spacebar my habitual button-presser. Which scrolls the page when it's not a button. Yes, I can scroll back to where I was and use the enter key when I realize a button is actually a link, but it is disruptive and unnecessary.

The "it's a minor nuisance for only a small section of the populace" argument does not hold water in my opinion. I can easily make a case that small fonts with 3:1 contrast are "just a nuisance" and that the workaround is to use the browser zoom. That doesn't make it okay to do.

I also don't get the whole "CTA" argument. You can call out links without using button-like styling on them. And a presenter's intent is irrelevant. I could build an atrocious site that is only usable by very high-functioning individuals because of the design, but I can't hide behind "that wasn't my intent".

Is there a normative way to handle this? Not a clue. But it's not hard to say a best practice is to make your site's buttons and links clearly different where at all possible. If your call to actions "must" look like buttons, see if you can add something that makes them different from your site's buttons. Underline on focus/hover. Different border. *Something*.

-----Original Message-----
From: Patrick H. Lauke <redux@splintered.co.uk> 
Sent: Friday, November 19, 2021 7:15 AM
To: w3c-wai-ig@w3.org
Subject: Re: Buttons styled as links and links styled as buttons

On 19/11/2021 15:01, Jonathan Avila wrote:
> WCAG SC 1.3.1 indicates that information and relationships that are communicated via presentation need to be communicated programmatically or as text - so if something looks like a button but acts like a link and is given a link role would potentially cause a failure there.

Arguably though, taking the example of a CTA link that's styled without underline, and a big "pill-like" background behind it, a designer hasn't chosen that presentation there to imply "this is a button", but rather they've used that purely to visually highlight/distinguish it. So the presentation/intent doesn't try to communicate anything special about what that control is.

Also, this is where it gets very squishy trying to normatively pin down 1.3.1, and trying to set testable and unambiguous parameters for styling ... at what point is something looking more like a button than a link? 
It can be very subjective.

> In this discussion many people cite screen reader users who only use the list of links - but I don't think that gives enough credit to screen reader users as true buttons would then be removed from that list and they'd have a similar issue.  It's better fixed by screen reader manufacturers to have something that allows both buttons and links as well as each separately.   Others say users won't know to press enter - keyboard users in Windows often use enter and ENTER should work on both buttons and links and this is a long standing interaction pattern although I can understand that some might be concerned about enter activating a default button or Mac users who may be use to space to activate buttons.

Anecdotally as well, on the problem for sighted keyboard users "if I'm on a link that appears to be a button, and I press SPACE, then my page scrolls instead", I spoke to a few keyboard users ages ago that mentioned this, but then also mentioned that while it can be annoying/surprising when that happens, they know to then just scroll back and use ENTER instead...so it's not like they're then completely lost and dismayed.

> I think the primary issue though is this is not solved programmatically but often requires visual treatment changes and affects design and most designers would likely push back.  Submitting a form to go to another page is both a button pattern and navigation pattern.  If links are used then links should be underlined - should we then start underlining everything?  That's even greater push back.

And rightly so, I'd say. Because why stop at underlines? Could also require links to keep their default blue colour, etc. That's the slippery slope of trying to normatively define styling that is/isn't allowed.

P
--
Patrick H. Lauke

https://urldefense.com/v3/__https://www.splintered.co.uk/__;!!C5qS4YX3!Tc86tWxLboy8SO8KrxwLsx2OQV2ig_q_8fnf1JM8hW1S1PaPQ27zFUACnEyLU6fIug$  | https://urldefense.com/v3/__https://github.com/patrickhlauke__;!!C5qS4YX3!Tc86tWxLboy8SO8KrxwLsx2OQV2ig_q_8fnf1JM8hW1S1PaPQ27zFUACnEx0yXvPGQ$

https://urldefense.com/v3/__https://flickr.com/photos/redux/__;!!C5qS4YX3!Tc86tWxLboy8SO8KrxwLsx2OQV2ig_q_8fnf1JM8hW1S1PaPQ27zFUACnEzCMPuZ6g$  | https://urldefense.com/v3/__https://www.deviantart.com/redux__;!!C5qS4YX3!Tc86tWxLboy8SO8KrxwLsx2OQV2ig_q_8fnf1JM8hW1S1PaPQ27zFUACnEwZdLY3bg$

twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Friday, 19 November 2021 18:19:41 UTC