Could your inaccessible links be making it harder for screen reader and magnifier users, including those with blindness or low vision, to navigate your website?
Globally, over 2.2 billion people live with vision impairment or blindness, and a significant percentage rely on assistive technologies to navigate websites.
It’s easy to think that HTML links (or “hyperlinks”) are accessible by default, but that’s not always the case when leading users to content.
While browser scrolling to the correct section or tabbing after clicking a link might seem functional, these methods don’t verify accessibility for users relying on assistive technologies. They can leave gaps in navigation and usability unnoticed.
When Links Become Barriers
Anchors, or links that point directly to specific content, are often the primary offenders. These can be identified by the hash symbol followed by a letter or word, such as #About:
<a href="#About"> Learn about us </a>The hash symbol corresponds to the id attribute of the content it references, such as id="About":
<h2 id="About"> About Us </h2>At this stage, many people assume the link is complete. When clicked, the browser scrolls to the correct section, giving the impression that it works as intended. You might even test it using a keyboard, verifying that the TAB key moves to the desired content.
However, there’s one crucial step that often gets overlooked—adding the tabindex="-1" attribute to the content:
<h2 id="About" tabindex="-1"> About Us </h2>Why tabindex Matters for Accessibility
When linking to non-interactive content like headings, paragraphs, or other static text, assistive technologies may need extra guidance to help users navigate. To make this possible, we can add a special type of anchor using the tabindex="-1" attribute that allows assistive tools to focus onto that content.
The tabindex="-1" attribute makes an element focusable so that users who rely on assistive technology can reach the information easily. This improves accessibility without changing the experience for others.
Technical note: this is known as making an element programmatically focusable while preserving the natural flow of sequential navigation.
Without it, certain screen readers and magnifiers fail to identify the correct destination. When clicking the link, some examples include:
- Screen readers unexpectedly announcing the page title, as if the user has been redirected to the top of the page.
- Other screen readers being unable to navigate to the intended content in a predictable manner.
- Screen magnifiers shifting to the top-left corner of the view, instead of focusing on the desired content.
Watch Inaccessible Links Unfold
To understand the challenges assistive technology users face, it’s helpful to see how these tools interact with links that aren’t set up correctly. In this demonstration, I’ll show how iOS VoiceOver (a mobile screen reader) and Windows Screen Magnifier navigate these situations and where issues arise.
iOS VoiceOver Links Don’t Work
In Safari on iOS with VoiceOver enabled, activating a link without tabindex="-1" prevents VoiceOver users from navigating to it using the RIGHT SWIPE gesture. This is the usual method for moving to the next item on a page.
Let’s look an example of The Guardian news website and the comments section.
The following video shows an opinion piece titled “The Unwritten Code of Healthcare…” with a speech bubble icon link, indicating 18 comments. The article content appears immediately after the icon, followed by the comments section.
Steps in the video:
- VoiceOver is turned on.
- The “18 comment” link is activated.
- The screen scrolls to the comments section.
- Using the RIGHT SWIPE gesture, VoiceOver attempts to navigate to the comments but is directed to the article content located at the top of the page instead.
- These steps are repeated.
Expected Behavior for iOS VoiceOver Users
When an iOS VoiceOver user activates a link, they should be able to reach the right section of content with a SWIPE RIGHT gesture.
Links may feel broken if they don’t lead to the right section of content. Without proper navigation, they aren’t functional.
Windows Screen Magnifier Becomes Lost
In Windows Screen Magnifier with Keyboard Focus turned on, activating a link without the tabindex="-1" attribute similarly scrolls the correct section into view, but moves the magnified area to the top-left corner instead of the content.
Let’s look an example of Wikipedia and the table of contents section.
The following video shows the Wiki page on Accessibility containing a table of contents with links and the main content side by side.
Steps in the video:
- Windows Screen Magnifier is turned on with the START + PLUS key.
- The magnifier setting “Have magnifier follow… Keyboard Focus” is turned on.
- The magnifier increased to 400%.
- The “Legislation” link is activated in the table of contents.
- The magnified view unexpectedly resets to the top-left corner.
- This is repeated with the “Assistive technology…” link in the table of contents.
Expected Behavior for Windows Screen Magnifier Users
When a Windows Screen Magnifier user activates a link, their view should move directly to the content without requiring manual panning.
The Solution for Inaccessible Links
As stated above, the way to resolve this issue is technically straightforward by introducing the tabindex="-1" HTML attribute on the target content.
<a href="#About"> Learn about us </a>
...
<h2 id="About" tabindex="-1"> About Us </h2>However, manual fixes aren’t always practical. You might not have access to the code, errors can occur, or changes might be overwritten. Applying fixes also takes extra effort.
Reminder: The solution is only necessary when linking to non-interactive content such as headings or paragraphs.
Tab-able Has Got You Covered For Inaccessible Links
No matter if you’re working with a JavaScript framework or a content management system, Tab-able offers the solution to accessible links designed to fit your environment.
- WordPress Plugin: Accessible Links from Tab-able
- Node Package Manager: @tabable/accessible-links
- GitHub: for directly embedding the script
The solutions we’ve made available are free and open source because we believe no one should have to struggle with these barriers. We’re pushing accessibility as far as possible, ensuring we reach every corner of the industry so everyone can navigate the web without unnecessary challenges.
Watch How Our Solution Works
Our WordPress plugin is now installed and activated on our website, ensuring that the fixes integrate smoothly with our content and any theme.
The following video shows the Homepage of tab-able.co.uk on an iPhone 13 Pro with (iOS) VoiceOver turned on.
Steps in the video:
- VoiceOver is turned on.
- The “Accessibility Quick Check” link is activated.
- The screen scrolls to the correct section.
- VoiceOver instantly locates and moves to the first heading in the “Accessibility Quick Check” section, marked by a black and white rounded border.
From this point forward, users can navigate to the content using the right swipe gesture.
Why Overlooking Inaccessible Links Affects Inclusion
Some may argue that inaccessible links are too minor to fix. After all, websites have used them this way for years, and people with disabilities must have found workarounds. They might ask, “Why not just use the TAB key to reach the content?”
But the TAB key doesn’t always work. On mobile devices without a Bluetooth keyboard, it’s not an option. Even when it is, it doesn’t take users directly to the content, it skips to the next interactive element, often bypassing important information.
Now, imagine if clicking a link within a page consistently scrolled you past the intended section, forcing you to manually scroll back up every time. Users would be frustrated, calling these links broken because they don’t lead to the right content. This is the reality for many people using assistive technology, making even simple navigation a frustrating challenge.
People with disabilities already face challenges using assistive technologies. Why make it even harder?
Technical Insights
Do you remember hearing about the tabindex attribute being no longer being necessary but can’t remember where?
It might trace back to Google’s 2016 article, which highlighted a Chrome update addressing a bug that prevented keyboard and switch users from accessing content after link activation.
Google introduced something called the sequential focus navigation ‘starting point’, a major improvement for keyboard and switch users seeking to reach content after interacting with a link. However, this solution overlooked the expected interaction model of a link. When all users activate a link, they should be taken directly to the content.
Because of this approach, Google implied tabindex was no longer needed for newer browser versions. However, the attribute is still very much needed as a mechanism to make non-interactive content focusable. That’s the key to making sure assistive technologies can access that content effectively.
Warning: do not use any value other than "-1" in the tabindex attribute for the following reasons:
tabindex="0"allows the content to be navigable via the TAB key, but it imposes an additional step on users with disabilities, complicating their navigation.tabindex="1"or any positive value not only creates the same issue astabindex="0", but it also prioritises the content as one of the first elements navigated on the page, potentially disrupting the logical flow for users.
Assistive Technologies Impacted By Inaccessible Links
We have identified several assistive technologies that encounter accessibility barriers when links lack the tabindex attribute.
Note: This list is not exhaustive, and we encourage further testing to ensure broader coverage.
- Windows Screen Magnifier with Keyboard Focus tracking turned on: Viewport resets to the top-left corner.
- iOS 18.3.2/ 17.4 VoiceOver & Safari: Focus is reset to the top of the page.
- iOS 17.4 Full Keyboard Access turned on, external keyboard & Safari: Focus is reset to the top of the page.
- JAWS 2023 & Chrome 124: The page structure is unexpectedly announced starting with the page title. Virtual cursor is then set on the correct content navigated.
- Windows 11 Narrator on Edge 136: Focus is reset to prior landmark and TAB key does not resolve the issue.
A Note on Disabilities Discussed in This Article
While this article connects specific disabilities with particular assistive technologies, these tools are not limited to their primary intended users. Others may find them beneficial as well.
For instance, a person with learning disabilities might use features of ZoomText, a magnification tool designed for individuals with low vision, to easily adjust text properties. They may also use a screen reader to read text aloud as they navigate, helping to validate what they are reading and reinforcing comprehension.
Further Reading
- Check out more examples of the issue on our CodePen.
