Start scanning free

( Operable / WCAG 2.4.4 )

Link opens a file with no format or size warning

MinorLevel AWCAG 2.4.4 — Link Purpose (In Context)

What is this issue?

An <a> element’s href ends in a document or archive file extension (PDF, DOC/DOCX, XLS/XLSX, PPT/PPTX, ZIP, or CSV) and neither the link’s visible text nor its aria-label mentions the format, an equivalent word (like “Word” or “Excel”), or a size unit (like “KB” or “MB”). The link works and points somewhere real; the defect is that activating it produces a different, unwarned experience than a normal in-page navigation would.

This differs from a plain broken or generic link: the destination is perfectly valid, and the link text might even be descriptive (“Download our annual report”). What’s missing is specifically the format signal that tells a user, before they click, that they’re about to leave the normal browsing flow.

Why does this matter?

Clicking a link is normally a low-stakes, reversible action: a new page loads, and the Back button undoes it. A file link breaks that expectation: it can trigger an unfamiliar viewer, a save dialog, or a large download the user didn’t anticipate, and Back doesn’t always cleanly undo any of those outcomes. Without a warning, the user only discovers this after they’ve already committed to the click.

The stakes scale with context. A user on a slow or metered mobile connection who unknowingly starts a 40MB PDF download pays real time and possibly real money for a click they’d have made differently with advance notice. A screen reader user who expects the next thing announced to be page content instead hears their browser or operating system announce a file download, with no indication from the link itself that this was coming.

Who is affected?

  • Screen reader users: hear a link’s accessible name with no format cue, activate it expecting a page, and are met with a download notification or file-viewer interface with no forewarning of what just happened.
  • Cognitive disabilities: an unexpected format or context switch after a click can be disorienting, especially for users who rely on predictable, consistent interaction patterns to stay oriented on a task.
  • Low vision: a sudden shift to a PDF viewer’s own zoom, contrast, and navigation controls, which often behave differently from the surrounding webpage’s accessibility settings, can be jarring for someone relying on customized magnification or contrast settings.

What users experience

Tomás uses NVDA on a laptop with a capped mobile hotspot connection to review a vendor’s compliance documentation. He activates a link labeled “View our accessibility policy,” expecting a webpage. NVDA instead announces a file download beginning, and Windows starts pulling down a 15MB PDF he had no way to anticipate from the link text. He has to cancel the download, unsure whether it will count against his monthly data cap, and never finds out the policy’s actual content, because nothing in the link warned him it wasn’t a webpage at all.

How do I fix it?

Add the file format directly into the link’s visible text, in a short, consistent pattern like “(PDF)” or “(Word document).” This works because it gives every user, regardless of assistive technology or connection speed, the same advance warning at the exact point they’re deciding whether to click, rather than after the fact.

Where practical, include an approximate file size alongside the format, especially for anything over a few megabytes, since size is the detail that matters most for users on slow or metered connections deciding whether to proceed. Keep the format text inside the link itself, not in a separate caption or icon placed only nearby, since a screen reader announces the link’s own accessible name and nothing else unless that context is programmatically connected to it.

Code Examples

Before
<a href="/reports/annual-report.pdf">Download our annual report</a>
After
<!-- Method 1: format and size in the visible text (preferred) -->
<a href="/reports/annual-report.pdf">
  Download our annual report (PDF, 2.4MB)
</a>

<!-- Method 2: aria-label when the visible text must stay short -->
<a href="/reports/annual-report.pdf" aria-label="Download our annual report, PDF, 2.4 megabytes">
  Download report
</a>

Method 1 puts the format and size directly where every user reads it, sighted or not, which is why it’s preferred whenever the design allows a slightly longer link. Method 2 keeps a shorter visible label intact for design constraints, moving the same detail into aria-label so assistive technology still receives it, though sighted users scanning the page visually lose that warning, which is the tradeoff of choosing this method over the first.

Common Mistakes

Mistake: “A PDF icon next to the link already tells users what it is.” An icon placed visually beside a link communicates nothing to a screen reader unless it carries meaningful alt text that’s programmatically tied to that same link; most decorative icons are marked alt="" specifically so they’re skipped, which means the format signal a sighted user gets from the icon simply doesn’t exist for a screen reader user encountering the same link.

Mistake: “The file will open in the browser anyway, so there’s no real disruption.” Whether a file opens in-browser or downloads depends on the visitor’s own browser settings and the server’s response headers, neither of which the link’s markup can guarantee. A PDF that opens smoothly in-tab during your own testing may trigger a download for a different user with different settings; the warning needs to be present regardless of how the file happens to behave for you.

Mistake: “Users can always tell it’s a PDF from the URL before clicking.” Very few users read the destination URL of a link before clicking it, and even fewer assistive technology workflows surface the raw URL as part of normal link interaction. The link’s own accessible name is the only information most users reliably encounter before activating it.

How RedFlag Detects This

Custom automated: RedFlag’s own DOM detector, runs on every scan. RedFlag scans every <a> element whose href ends in a document or archive extension (pdf, doc, docx, xls, xlsx, ppt, pptx, zip, or csv) and flags it unless the link’s text or aria-label already contains a format or size cue, matched with a regex covering words like “pdf,” “doc,” “word,” “excel,” “zip,” “csv,” “kb,” or “mb.”

False negative: the extension check only looks at the URL’s file extension; a download link served from a route with no file extension in its path, like /download/annual-report, is invisible to this detector even though it produces the exact same unwarned-download experience. False positive: a link whose text legitimately contains one of the matched words for an unrelated reason (for example, linking to a page titled “Understanding CSV Exports” that isn’t itself a CSV file) can be treated as already-warned and skipped, when in fact the destination isn’t a file at all and needed no warning to begin with. Manual step: for every link the detector doesn’t flag, confirm the format words present are actually describing that link’s destination, not a coincidental match in unrelated text.

Manual Testing

  1. Open the page in Chrome or Firefox with NVDA or VoiceOver running.
  2. Tab to each link that points at a document or archive file (check the href in DevTools if unsure).
  3. Listen to the accessible name announced for the link.
  4. Confirm the announcement includes the file format, such as “Annual report PDF link,” not just a generic description like “Annual report, link.”
  5. For larger files, confirm a size indication is present as well, and flag any file link over a few megabytes with no size warning at all.

2.4.4 Link Purpose (In Context): The purpose of a link must be determinable from its text alone or combined with its surrounding context. A file link with no format warning technically may still describe its subject matter, but it fails to convey a key part of its purpose: that activating it produces a file download or viewer switch rather than a normal page navigation.

Link text is generic and gives no context shares this rule’s underlying “predict what happens before you click” principle, applied to vague wording instead of missing format warnings.

Link opens in a new tab without warning text covers the same context-warning gap for a different kind of unexpected behavior: a new browser tab instead of a file download.

Links with the same accessible name go to different places is worth checking on pages with several file links, since a set of undifferentiated “Download” links compounds both problems at once.

Button or link has no accessible name is the more severe version of a related failure: a file link with no accessible name at all, rather than one with a name that’s simply missing a format warning.

Skip link target is missing or not focusable is unrelated in mechanism but shares this rule’s theme of a link’s real behavior silently diverging from what a user expects when they activate it.

References

Frequently asked questions

Does every file link need to include the file size, or just the format?

Format matters more and is the minimum expectation: "Annual report (PDF)" is a meaningful improvement even with no size stated. Adding the size, like "PDF, 2.4MB," is a further courtesy that matters most for larger files or in contexts where users might be on a slow or metered connection, but it is not strictly required to pass this check.

Does this rule apply to links that open in the browser instead of downloading, like a PDF that renders in a browser tab?

Yes. Whether the file opens in-browser or triggers a download depends on the user's browser settings and the server's response headers, not on anything the link's markup controls reliably. Since you cannot guarantee which behavior a given visitor will get, every file-type link should carry a format warning regardless of how it happens to behave in your own testing.

Do image files like JPG or PNG count as files that need a warning under this rule?

No. This check is scoped to document and archive-type files (PDF, Word, Excel, PowerPoint, ZIP, and CSV) since those are the formats that meaningfully disrupt a user's expected "click a link, see a webpage" flow. An image opening in a new view is a much smaller context shift and is not covered by this specific rule.

Is aria-label a valid way to add the format warning instead of visible text?

Yes, with a tradeoff. An aria-label carrying the format information satisfies assistive technology users, but it leaves the format invisible to sighted users scanning the page, who benefit from the same warning just as much. Visible text is the more complete fix; use aria-label as a fallback only when the visible design genuinely cannot accommodate it.

Does mentioning the format in a nearby caption or icon instead of the link text itself satisfy this rule?

It depends entirely on whether that context is programmatically associated with the link, not just visually nearby. A PDF icon placed next to a link communicates nothing to a screen reader unless it has meaningful alt text linked to the same link, or the format text sits inside the link's own accessible name; visual proximity alone does not transfer to assistive technology.

( Related rules )

( Related articles )