RE: Buttons styled as links and links styled as buttons

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.  

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.

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.  

The far greater issue is things that don't look like they have affordance and don't look actionable but are actionable and vice versa - and this is something we were unsuccessful in getting into WCAG 2.2 as it would impact visual design too much and people pushed back.

On a related note I've seen radio buttons styled as buttons and it's unclear to the user what activating them does - so this issue does extend beyond links/buttons as well.

Jonathan

-----Original Message-----
From: Urban, Mark (CDC/OCOO/OCIO/CEO) <fka2@cdc.gov> 
Sent: Friday, November 19, 2021 9:32 AM
To: Patrick H. Lauke <redux@splintered.co.uk>; w3c-wai-ig@w3.org
Subject: RE: Buttons styled as links and links styled as buttons

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Hi all,

I agree and disagree with my very esteemed colleague Patrick here:

AGREE: Yes, we spend too much time on this issue.
DISAGREE: because we never just bite the bullet and make a call as to what's the best practice way to do this.

Style does matter, in this instance especially to persons using screen mags and heavy keyboard/voice input.  When you make something look like something it isn't, people get confused on functionality ad purpose.  Or, put another way, slapping a Subaru logo on my daughter's sedan doesn't suddenly give it 4-wheel drive.

Regards,

Mark D. Urban
CDC/ATSDR Accessibility Program Manager
Office of the Chief Information Officer (OCIO) Office of the Chief Operating Officer (OCOO) Murban@CDC.gov | 919-541-0562 office

-----Original Message-----
From: Patrick H. Lauke <redux@splintered.co.uk>
Sent: Tuesday, October 26, 2021 7:36 PM
To: w3c-wai-ig@w3.org
Subject: Re: Buttons styled as links and links styled as buttons

My personal take on this is that it's a "talismanic" issue that is really a non-issue, but for some reason seems to constantly suck up all the energy and effort, as if it was the most pressing aspect to solve in the accessibility discourse.

I'm a proponent of the role ideally matching the function (and if not, failing der 4.1.2), but leaving 1.3.1 well out of this as there really is far too much of a gray area between how a link or button "traditionally" looks and what the reality is (with call-to-action links, download links, graphical links, etc)

and voice users can generally easily activate a control by saying "click [visible text]" without even needing to specify link or button...

P

Received on Friday, 19 November 2021 15:01:21 UTC