- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Fri, 19 Nov 2021 15:14:59 +0000
- To: w3c-wai-ig@w3.org
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://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Friday, 19 November 2021 15:15:13 UTC