Skip to content

Link Accessibility Checker

Paste your HTML to check links for accessibility issues including generic text, empty links, missing href attributes, and new-tab links without warnings.

FreeNo SignupNo Server UploadsZero Tracking

We fetch the page client-side. Some sites may block external access — use "Paste HTML" as a fallback.

Enter a URL or paste HTML above to analyze link accessibility.

How to Use Link Accessibility Checker

  1. 1

    Paste your HTML

    Copy the HTML source code containing links you want to check and paste it into the input area.

  2. 2

    Click Check Links

    Press the button to scan all <a> tags and evaluate their accessibility.

  3. 3

    Review link issues

    See each link's accessible name, href, and any errors or warnings flagged by the checker.

  4. 4

    Improve link text

    Replace generic text like 'click here' with descriptive link text and add warnings for new-tab links.

Frequently Asked Questions

Screen reader users often navigate by pulling up a list of all links on a page. When multiple links say 'click here' or 'read more', users cannot distinguish between them. WCAG Success Criterion 2.4.4 (Link Purpose in Context) requires that the purpose of each link can be determined from the link text alone or from the link text together with its programmatically determinable context. Descriptive link text like 'View our accessibility guide' is universally more usable.

Opening a link in a new tab changes the user's context without their expectation. For screen reader users, the back button no longer works as expected. For users with cognitive disabilities, the sudden context change can be disorienting. WCAG Success Criterion 3.2.5 (Change on Request) recommends that context changes happen only by user request. Adding an aria-label, sr-only text, or a visual icon (like an external link icon) warns users before they click.

An empty link is an <a> element that has no accessible name. This can happen when a link wraps an image without alt text, contains only whitespace, or has no content at all. Screen readers announce these as 'link' with no further information, making them unusable. Every link must have a text alternative that describes its destination or purpose.

Links (<a>) navigate to a new page or location. Buttons (<button>) trigger an action. If clicking an element submits a form, opens a modal, or toggles something, use a button. If it navigates to a URL, use a link. Using the correct element ensures proper keyboard behavior and screen reader announcements. Links with href='#' or javascript: URLs are often signs that a button should be used instead.

No. All link analysis happens entirely in your browser using client-side JavaScript. No HTML content is transmitted anywhere. Your code remains private and secure on your device.

Related Tools

Color Contrast Checker

Check color pairs against WCAG AA/AAA

Try it

Heading Analyzer

Validate heading hierarchy

Try it

Alt Text Checker

Find images missing alt text

Try it

ARIA Validator

Validate ARIA attributes

Try it

Creating Accessible Links: A Complete Guide

Links are the connective tissue of the web. They enable navigation between pages, connect related content, and provide pathways to actions and resources. Because links are so fundamental, their accessibility has an outsized impact on the overall usability of any website. Poorly implemented links create barriers for screen reader users, keyboard navigators, and anyone who relies on assistive technology to browse the web.

What Makes a Link Accessible

An accessible link communicates its purpose clearly, works with all input methods, and behaves predictably. WCAG 2.2 defines several success criteria related to links. SC 2.4.4 (Link Purpose in Context) at Level A requires that the purpose of each link can be determined from the link text alone or from the text combined with its programmatically determinable context. SC 2.4.9 (Link Purpose - Link Only) at Level AAA requires that every link's purpose be identifiable from the link text alone, without relying on surrounding context. SC 1.3.1 (Info and Relationships) requires that the link's role and state be programmatically determinable.

The Problem with Generic Link Text

Screen readers provide a feature that lists all links on a page, allowing users to quickly scan available navigation options. When this list contains multiple entries saying "click here," "read more," or "learn more," it becomes useless for navigation. Each link should make sense in isolation. Instead of "To learn about accessibility, click here," write "Learn about web accessibility." The link text should describe where the link goes, not instruct the user to click.

This problem extends beyond screen readers. Users who scan pages visually tend to focus on links, reading them as navigation landmarks. Descriptive link text benefits everyone by clearly indicating what content or action is available at the link destination.

New Tab Links and Context Changes

Opening a link in a new browser tab or window is a context change that can disorient users, particularly those using screen readers or with cognitive disabilities. The browser's back button stops working as expected, and keyboard focus may shift unpredictably. When you must open links in new tabs (for external resources, documents, or to preserve form state), always provide a warning. This can be done through an aria-label that includes "opens in new tab," visually hidden text with the sr-only class, a visual icon with appropriate alt text, or the link's title attribute.

Empty Links and Missing Href

An empty link is one with no discernible text for assistive technology. This happens when a link wraps an image without alt text, contains only whitespace or decorative elements, or has been stripped of its content through JavaScript. Screen readers will announce these as "link" without any indication of where they lead. Similarly, links without an href attribute are not focusable by keyboard, cannot be activated by pressing Enter, and are not announced as links by screen readers, making them completely inaccessible.

Links vs. Buttons: Choosing the Right Element

A common accessibility mistake is using links for actions and buttons for navigation. Links and buttons have different keyboard behaviors and are announced differently by screen readers. Links are activated with the Enter key and navigate to URLs. Buttons are activated with both Enter and Space and trigger actions. When a clickable element opens a modal, submits data, toggles a menu, or performs any action that does not navigate to a new URL, it should be a <button> element. Using the correct semantic element ensures proper behavior for keyboard and assistive technology users without requiring additional ARIA attributes.

Best Practices Summary

Write descriptive link text that makes sense out of context. Ensure every link has an accessible name through visible text, aria-label, or an image with alt text. Warn users when links open in new tabs. Use links for navigation and buttons for actions. Avoid javascript: URLs and empty href values. Test your links with this tool regularly to catch issues before they affect your users.