RE: [EXTERNAL] Links and Buttons: Convention Or Violation

Hello Colton, 

 

My sympathies for inheriting a bunch of government web sites! ☺

 

<rant type=”frequent” class=”weary tired”>

The items in a menu you describe shouldn’t programmatically be hyperlinks, but menuitems instead.

 

Them being hyperlinks is a longstanding hangover from when the web didn’t work very well and people believed – erroneously, in my view – that there was a lowest common denominator everyone should be able to use if things went haywire.

 

Menus in web pages shouldn’t function in ways different from operating system menus, but lists of links do … and people persist in building them like this in the mistaken belief that they’re doing everyone a favour.

 

As a screen reader user of more than twenty years, I can assure you that nothing gets my goat more than having to tab fifty zillion times to arrive at a hyperlink in a flyout menu that is buried in the last dropdown because someone believes that using ARIA and javascript to create a menu that emulates an operating system is somehow excluding people …  

 

TAB is not the appropriate key for navigating up and down a menu - that would be the ARROW keys.  This is because TAB is for navigating between widgets and ARROW keys are for navigating within a widget. 

 

It has ever been thus for screen reader applications on desktop yet people keep using stupid menus comprising lists of hyperlinks.

 

And, while I’m here, screen reader applications provide navigational techniques based on programmatic role so if I am using the letter B in browse mode, for example, to cycle through a collection of buttons in a view, I am going to miss anything that is marked up as a hyperlink and has either an implicit or explicit role of link regardless of how it is styled or what it does.

 

This is not an issue when using other input methods.

</rant>

 

There are cases in which both navigation and action occur on activation in either order such as a ‘save and continue’ control that simultaneously saves/submits form data and navigates to a new view etc. 

 

Putting aside the styling for a moment and focusing only on the programmatic role, my rule-of-thumb for dual functions is to use a button because the action occurs first. 

 

And then the type of HTML element or its role, and how it appears naturally follows. Good design is key here as is not using crappy out of the box point and click platforms.

 

Using sufficiently instructive labels like ‘save and continue’ or ‘discard and Go to Home’ or whatever can also assist with understanding the purpose of a control. 

 

Perhaps an easier way to put this is that there are only a few cases in which hyperlinks (styling and role wise) should be used – everything else should look like a button, have a role of button, and perform an action notwithstanding the cases in which there might be a dual purpose (for example: ’go to Your Information to update your address’).

 

For your purposes, you may wish to create a simple algorithm or decision support tool which guides what styling and programmatic role each UI component should have … and then build on this with conventions around labelling, interaction behaviour, necessary keyboard support, etc. so that at least there’s a documented rationale for why something is the way it is.

 

The key in my view is to drive any decision about which component to use from the perspective of the people using it and not a developer or a UI designer … designers and developers are not ‘users’ (as much as I loathe that term)  and only see any such decision from the pixel thin perspective of a wireframe or as code. 

 

Cheers,

Adam 

 

 

 

 

From: Hash, Colton <Colton.Hash@mt.gov> 
Sent: Friday, February 6, 2026 11:07 AM
To: Adam Cooper <cooperad@bigpond.com>; 'Jim Homme' <jhomme@benderconsult.com>; 'Mark Magennis' <Mark.Magennis@skillsoft.com>; 'Wai Interest Group' <w3c-wai-ig@w3.org>
Subject: RE: [EXTERNAL] Links and Buttons: Convention Or Violation

 

I have tried to find some clear resources online about this topic, and I can share about my decisions around this as a developer (but as Adam pointed out, being a developer might mean that I can’t be trusted to make decisions about accessibility issues)

 

 

I inherited control of multiple government websites where prominent links are stylized to look like buttons, and where navigation links in nav menus also are stylized differently than normal text links. These are all created with anchor tags, and are announced by screen readers as links. From a UI perspective, it seems useful to be able to distinguish nav menu links and links to important resources from normal text links.

 

For buttons used to submit forms, or that operate widgets on a webpage, I have stylized these differently from the stylized links that look like buttons. These functional buttons are created with button elements and are announced by screen readers as buttons. These have a distinct visual style, with different colors and shapes than the navigation links and links that look like buttons.

 

I found the following article useful in thinking about this issue:

Adam Silver – But sometimes buttons look like links <https://adamsilver.io/blog/but-sometimes-buttons-look-like-links/> 

 

My understanding is that links are used to take users to another webpage, or a different section of the same web page. Buttons initiate some kind of function on the same web page, like submitting a form or opening a dropdown menu. Having consistency across our websites and associated web applications for link vs button behavior and styling is something that I am enforcing. 

 

 

From: Adam Cooper <cooperad@bigpond.com> 
Sent: Thursday, February 5, 2026 4:21 PM
To: 'Jim Homme' <jhomme@benderconsult.com>; 'Mark Magennis' <Mark.Magennis@skillsoft.com>; 'Wai Interest Group' <w3c-wai-ig@w3.org>
Subject: RE: [EXTERNAL] Links and Buttons: Convention Or Violation

 

Are we building websites for the convenience of developers, now? 

 

In my experience, it’s best to never leave decisions which may impact people using a digital service up to developers.

 

Wireframes, no matter how ‘accurate’ or ‘faithful’  and despite what many people believe, do not comprise  a complete specification of a user interface. 

 

Focus mapping, technical design, interaction design, information architecture design, naming conventions etc. all contribute to the final product.

 

If the developer is to implement this or that component in a specific way, then they need to be directed to do so.

 

Design, design, design is where accessibility begins … every decision left in the hands of developers is where accessibility goes to die.

 

 

 

From: Jim Homme <jhomme@benderconsult.com <mailto:jhomme@benderconsult.com> > 
Sent: Friday, February 6, 2026 2:04 AM
To: Mark Magennis <Mark.Magennis@skillsoft.com <mailto:Mark.Magennis@skillsoft.com> >; Wai Interest Group (w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> ) <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> >
Subject: RE: [EXTERNAL] Links and Buttons: Convention Or Violation

 

Hi,

Maybe, practically for developers, if it looks like a link, use an anchor, and if it looks like a button, use a button tag. I’m trying to settle on advice I can give most of the time.

 

Jim

 

Jim Homme, Senior Accessibility Consultant

Bender Consulting Services, Inc. 

#Bender30 #PaychecksNotPity #CompetitiveJobsMeanFreedom

 <mailto:|jhomme@benderconsult.com> |jhomme@benderconsult.com | <https://urldefense.com/v3/__https:/benderconsult.com/__;!!GaaboA!ubCCZ0S3jb2OopS9Z9S3aEukmW-rQxJ5a8DpKCkUCJvlLMKZSrNjrldyUd9IOT1B3IyRhuA8DttafxmItsuu$> benderconsult.com [benderconsult.com]

 



 

From: Mark Magennis <Mark.Magennis@skillsoft.com <mailto:Mark.Magennis@skillsoft.com> > 
Sent: Thursday, February 5, 2026 7:45 AM
To: Wai Interest Group (w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> ) <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> >
Subject: Re: [EXTERNAL] Links and Buttons: Convention Or Violation

 

I'm open to correction but as I see it there are different schools of thought and I've seen all of them supported by different accessibility practitioners.

 

1. The role should reflect the behaviour but it's not critical that the appearance reflects the role. So something that behaves like a link must be exposed as a link but can be visually styled to look like a button if that's what the UX designer wants. 

2. The role should reflect the visual appearance, even if the behavior doesn't match the semantics of the role. So if it looks like a button it should be exposed as a button, even if it actually behaves like a link.

3. The role and appearance should both reflect the behavior. So if it behaves like a link, it must be exposed as a link and also must look like a link and not like a button.

 

3 would be my preference and I would accept 1 but not 2. It sound like you would accept 2 but not 1.

 

Mark

 

  _____  

From: Jim Homme <jhomme@benderconsult.com <mailto:jhomme@benderconsult.com> >
Sent: Wednesday, February 04, 2026 19:17
To: Wai Interest Group (w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> ) <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> >
Subject: [EXTERNAL] Links and Buttons: Convention Or Violation 

 

Hi,

I usually think of hyperlinks as going to new pages and buttons as starting a process. For example, fill out a form and click a button, rather than a hyperlink.

 

On a page I’m looking at, the styling looks like a button, and the tag is an anchor with a button role. I know that’s symantically incorrect. If the anchor becomes a button tag, the style and tag will agree, but clicking it would go to a new page if the underlying code was changed. How should the anchor and the styling be handled if the developer wants this to look like a button and how should it be handled if they want it to look like a link. I’m assuming that if I were the developer, one choice is to let the browser do what it wants to the link.

 

Thanks.

 

Jim

Jim Homme, Senior Accessibility Consultant

Bender Consulting Services, Inc. 

#Bender30 #PaychecksNotPity #CompetitiveJobsMeanFreedom

 <mailto:|jhomme@benderconsult.com> | <mailto:|jhomme@benderconsult.com> jhomme@benderconsult.com | <https://urldefense.com/v3/__https:/benderconsult.com/__;!!GaaboA!ubCCZ0S3jb2OopS9Z9S3aEukmW-rQxJ5a8DpKCkUCJvlLMKZSrNjrldyUd9IOT1B3IyRhuA8DttafxmItsuu$> benderconsult.com [benderconsult.com]