Using anchor tags vs button tags - HTML, screen readers and accessibility

(No idea if this is the right category. Mods: feel free to move this.)

Hi folks!

This is a thing I’ve been wondering for quite some time, so let’s settle the question once and for all! :slight_smile:

Whenever I write a game that runs in the browser and I have links inside a sentence, I wonder what to use: the HTML anchor tag or the button tag? The anchor tag seems obvious because websites do it all the time, but then I wonder if a button tag isn’t the better choice.

First off the anchor tag gives me a dreadful status bar hover text in the bottom left
corner. I truly despise it and feel like it breaks my immersion when hovering over a link, especially if the game is styled in a way that clashes with its look. (It normally shows the site the link leads to, but in this case it shows some useless text anyway because we are not actually navigating.)

Secondly the anchor tag is not even semantically correct because we are not navigating to another site, we are just performing an action in the game.

So using a button always seemed like the better option to me. But then I realized that I don’t know jack about screen-readers and how that affects them. Is there anything that trips up screen readers when there is a button tag in the middle of a sentence? Or do interactive elements in the middle of a sentence just suck in general for screen readers and it would be better to have a dedicated screen-reader mode where all choices are given separately below?

Thanks!

2 Likes

Screen readers are fine with interactive elements mid-sentence, as long as it’s semantic HTML, they can figure it out. Use <button> if you want, just remember to give them labels. Off the top of my head, it also should be possible to suppress that hover behavior of anchors with a little JS and some CSS to generalize. If you’re still interested in using anchors, I can knock something together.

4 Likes

When you’re worried about what screen readers will do, the best thing to do is to try one. iOS VoiceOver is a great one to try, if you have an iPhone or iPad. On Windows, you can try NVDA.

5 Likes

I’ve also struggled with this question when trying to make Poink-and-Clink work with screen readers. One difference I’ve noticed is that in the case where the choices appear after the text (i.e. Ink-style, not inline Twine-style links) then the choice of links vs. buttons makes a difference in terms of whether they get read out as part of the text or not. (Buttons don’t get read out as text, at least with the screen reader I was using, although they still appear in the tab order).

Related: One issue I have with the “just try it” advice is that, as someone who doesn’t use a screen reader regularly, I don’t know what’s idiomatic in terms of how screen reader users expect to be able to navigate. Sometimes the screen reader behaviour seems very strange to me, but I don’t know whether that’s a sign I’ve screwed up, or whether it’s just me failing to understand screen reader navigation.

4 Likes

I checked Stack Overflow and it really seems like the status bar when you hover a link cannot be removed at all. It’s a security thing. Which is kind of silly when the link does not actually take you to another page, but, oh well.

I will try using a screen reader this weekend. :slight_smile:
But like Avery said, if you are not a regular user of these things you might miss something, that’s why I asked.

This is a really good point. A screen reader is a complex piece of software, and while ultimately its purpose is to allow the user to interact with the same systems as someone sighted, it does a lot of behind-the-scenes work to adapt a representation of those systems to its navigational paradigm. You can get pretty far pointing at things with the mouse and scrolling with the cursor keys, but to really test something with a screen reader, you need to know how it reads the screen, and as Avery says, how the users expect things to work. A lot of the time the users can’t even tell you, because their understanding of the system is the screen reader’s representation of it. It’s why I’m still most comfortable writing console apps. I’m completely rubbish at laying out a GUI, since I don’t have any understanding of how they mechanically work. The screen reader understands those things for me.

I still really encourage people to try it, but it’s a learning curve, and a fair investment of time and energy that not everyone will have.

(edited for grammar and emphasis)

2 Likes

Could you just conditionally blank the status bar? I don’t know how that would appear visually.

Not tested:

document.addEventListener("mouseover", function (event) {
    if (event.target.tagName === "A") {
        window.status = "";
        return true;
    }
};

At a minimum, “just try it” can allow you to confirm whether your thing can work at all in a screen reader. Beyond that, we’re talking about usability in a screen reader.

Like all usability questions, opinions differ about what’s more or less usable. Some things are more usable for experts and less usable for newbies, or vice versa. As a screen-reader newbie, you have a valuable viewpoint. Some of your screen-reader users aren’t experts, either.

Overall, the most important advice for delivering a usable app is to use your app, regardless of whether it’s a web app or native app, for sighted users or visually impaired users.

People sometimes say “I can’t deliver a usable app for a platform I don’t normally use; I need other users to tell me what’s usable, to match the idioms of the target platform.” It is wise to do stuff that’s idiomatic to your platform, and you will do your best work on platforms you use regularly, but when you’re publishing on the web, you inherently have to support multiple platforms: Windows, Mac, iOS, Android.

For example, on Windows, dialogs tend to put the “OK” button to the left of the “Cancel” button, and on macOS, the “OK” button usually appears to the right of the “Cancel” button. If your web site has a dialog in it, you’ll just have to pick one.

Just like operating systems, screen readers don’t all have the same idioms. iOS VoiceOver is surprisingly different from macOS VoiceOver, which is different from NVDA, which is different from Android Talkback, etc.

Doing usability testing in all of the major screen readers is usually impractical and unnecessary, but you’re already miles ahead of most sites/apps if you do any usability testing at all in any screen reader.

“Just try it” isn’t the last word in screen-reader usability, but it should be your Plan A, the first thing to do. In particular, in my experience, trying a screen reader is more valuable than reading written advice on how to deliver a usable experience on a screen reader. (It’s hard to even understand and apply most of the written advice about screen-reader usability without trying it out yourself.)

2 Likes

Well said. I certainly don’t want to discourage the just trying of it. I just get that it might be daunting for some and I’m sympathetic. Visual interfaces are a real programming bugbear for me (web or otherwise); I too have often wondered “can I just do a button?”

No shade on the idea or your perspective, which is one I’m glad to see in a discussion about accessibility. :smiley:

Screen Reader Links

Here’s some links to some screen readers to make up for my pessimism :slight_smile:

Apple

VoiceOver is built-in to all Apple devices running iOS, iPad OS, MacOS, and TVOS (for completeness). You can Turn it on in Accessibility settings, or press ⌘+F5 to turn it on and off on a Mac. Note that (as mentioned by @dfabulich) MacOS VoiceOver is a little different to its mobile counterparts, although its rare among screen readers for starting in a tutorial.

Android

Many Android devices come with screen readers built in these days. Samsung’s Screen Reader (sometimes called Voice Assistant) and Google’s TalkBack are common.

Windows

For Windows, there’s the built-in Narrator, which, according to the last WebAIM Screen Reader User Survey is used more than previously. You can start and stop narrator with CTRL+WIN+enter on any system running Windows 8 or later.

NVDA is a very popular windows screen reader. It’s free and open source and you can download it on this page.

Linux

For Linux, some options are Orca for the graphical desktop, and Speakup for the console. If you don’t have an external synthesizer for Speakup, you’ll need eSpeak NG and the espeakup connecter too.

ChromeOS has ChromeVox.

1 Like

For Windows, there’s also JAWS, but that’s in “So damn expensive it feels morally wrong to recommend it over NVDA” territory, but some Blind Windows users lucky enough to have an employer who will buy it for them or who are just rich in their own right swear by it and some schools still push blind students to use it to the point they’re afraid to try the Free alternatives. For the Linux command-line, there’s also Fenrir and I believe the speechdup package allows speakup to use any speech synth with a speech-dispatcher module.

Also, as I understand it, Voiceover for OSX and Voiceover for iOS are completely different pieces of software with little in common beyond a shared name and both being made by Apple.

And the reason every OS has it’s own screen reader is because a GUI screen reader has to hook so deeply into the host OS to function that porting a screen reader to an unrelated OS is basically impossible short of a full rewrite.

That said, as a full-time blind Linux User, I use Orca for GUI stuff, but the last time I was on a Windows machine for any appreciable amount of time, I couldn’t really tell a difference using NVDA or JAWS(it was at a vocational rehab center for the blind) compared to Orca.

And sorry, but I can’t really give much of an opinion on the links versus buttons for choice IF as I don’t have much experience with web-based choice IF, being more comfortable with running parser IF from the command line. I will say, my own intuition would be to use links in-line and for moving to the next passage at the end of the current one and would use buttons primarily in forms.

3 Likes

For those wondering, since I had to go through several web pages to find an actual price: currently $1,200 USD for a personal license. Ouch.

2 Likes

There is only a link preview if the <a> element has a href attribute, which it should not in the case of an internal link. If it doesn’t have one, no hover text.

1 Like

I think I tried just removing the href once, but then the screen reader didn’t treat the link as clickable. (EDIT: Also, internal links do still traditionally have an href. I think technically an <a> is not supposed to be considered a link unless it has an href).

1 Like

One subtle consideration with embedding these elements inside running text is, so far as I’ve been able to find, <button>s can’t word wrap. e.g. if you have long text in a button that would wrap across lines in an <a> tag, the <button> will instead move to the next line. It’s kind of ugly in my opinion.

For what it’s worth, I approached this in Chapbook using a custom element that sets its ARIA role to button and implements the keyboard functionality native buttons have.

Also FWIW, window.status is deprecated and I think modern browsers ignore it, because you can do stuff like <a href="bad site" onmouseover="window.status ='https://google.com'">trust me, click here</a>.

2 Likes

Thanks, good to know.

The approach SugarCube takes is <a role="link"> so that screen readers still announce it.

2 Likes

Thanks for all the great answers! There is a lot to go through here for me and I also learned some new tricks. :slight_smile:

1 Like