Download Links Without Context Are a Dead End for Screen Reader Users

In the early days of the web, a link was just a link. You clicked it, something happened, and you figured it out from there. Thirty years later, we've built extraordinarily complex digital experiences — and somehow, we're still shipping download links that tell users absolutely nothing about what they're about to receive.

The WCAG 2.1 test page for Bug 58 (opens in new window) demonstrates three distinct failure patterns around download link indicators. The automated analysis also identified two structural landmark violations. Together, these issues paint a familiar picture: a page that looks functional to sighted users and becomes a navigation maze for everyone else.

The Finding

The automated analysis of this test page (opens in new window) identified the following violations:

Structural failures (2 issues):

• No <nav> landmark found
• No <header>/banner landmark found

Content-level failures (3 patterns demonstrated):

• Download links with no indication of file type or size
• File size omitted from linked resources
• File type icons used without accessible text alternatives

The structural issues violate WCAG 1.3.1 Info and Relationships (opens in new window) and WCAG 2.4.1 Bypass Blocks (opens in new window) — both Level A requirements. When a page has no <header> or <nav> landmark, screen reader users lose the ability to orient themselves and jump directly to navigation. They're forced to read through every element on the page sequentially.

The download indicator failures hit WCAG 4.1.2 Name, Role, Value (opens in new window) — the requirement that all UI components expose their name and purpose to assistive technology. A link that reads only "Get your report" or displays a 📄 icon with no text fails this criterion because it provides no programmatic information about what the link does or what it delivers.

Here's what the problematic patterns look like in code:

<!-- Bug: No download indication -->
<a href="report.pdf">Get your report.</a>

<!-- Bug: File size not mentioned -->
<a href="handbook.pdf">PDF Handbook</a>
<a href="data.zip">Compressed Data</a>
<a href="tutorial.mp4">Tutorial Video</a>

<!-- Bug: Icon without text -->
<a href="guide.pdf">Installation Guide 📄</a>

Why This Matters

Once again, we're seeing failures that seem trivial in isolation but compound into genuine exclusion for real people.

For a screen reader user navigating by links — a common strategy where JAWS or NVDA reads out all links on a page in a list — "Get your report" is meaningless. There's no way to know before clicking whether this link opens a 500KB PDF, a 50MB video file, or a ZIP archive that will trigger a download. On a slow connection or mobile data plan, that uncertainty has real consequences.

The emoji icon pattern (📄) is particularly problematic. Some screen readers will announce the emoji as "page facing up" or similar — technically present, but useless as a file type indicator. Others may skip it entirely. Neither outcome serves the user.

For keyboard-only users navigating a page without <nav> landmarks, there's no skip link target to jump past repeated content. Every page load means tabbing through every element before reaching the main content — a friction cost that accumulates across every visit.

Switch users and people with motor disabilities face the same landmark problem with compounded effort. The cognitive load of navigating an unlandmarked page is not abstract — it's minutes of extra work on tasks that should take seconds.

This connects to a broader pattern our research has examined: automated testing catches structural issues like missing landmarks reliably, but the contextual failures — the download link that lacks file size — require human judgment to fully evaluate. Beyond Detection: Why Context Separates Automated Testing from Manual Audits documents why no automated tool alone can surface the full scope of what users experience.

Best Practices

The fixes here are straightforward. The ARIA Authoring Practices and HTML spec both provide clear guidance.

Fix structural landmarks:

<header role="banner">
  <nav aria-label="Main navigation">
    <!-- navigation links -->
  </nav>
</header>

<main>
  <!-- page content -->
</main>

Fix download links — provide file type and size:

<!-- Option 1: aria-label with full context -->
<a href="report.pdf" aria-label="Download report (PDF, 2.5 MB)">
  Get your report
</a>

<!-- Option 2: Visible text with type and size -->
<a href="handbook.pdf">
  PDF Handbook <span class="file-meta">(PDF, 1.2 MB)</span>
</a>

<!-- Option 3: download attribute with descriptive aria-label -->
<a href="data.zip" download aria-label="Download compressed data archive (ZIP, 8.4 MB)">
  Compressed Data
</a>

<!-- Fix: Icon with accessible text -->
<a href="guide.pdf" aria-label="Download Installation Guide (PDF, 3.1 MB)">
  Installation Guide
  <span aria-hidden="true">📄</span>
</a>

The WCAG Understanding document for 4.1.2 (opens in new window) is clear: the accessible name of a control must communicate its purpose. For download links, that purpose includes what you're downloading and what it will cost you in bandwidth and time.

For landmark structure, WCAG 1.3.1 (opens in new window) requires that structural relationships conveyed visually — like "this is the site header, this is navigation" — be programmatically determinable. HTML5 landmark elements (<header>, <nav>, <main>, <footer>) are the simplest implementation path.

Applying This

In code review: Add a checklist item — any link whose href ends in .pdf, .zip, .docx, .mp4, or similar, or that carries a download attribute, must have file type and size in its accessible name. Make this a hard rule, not a suggestion.

In automated testing: Tools like axe-core (opens in new window) will catch missing landmarks reliably. They will not catch a download link that has text but lacks file metadata — that requires a human reviewer or a specialized rule. Build both into your pipeline.

Quick wins: Auditing existing download links across a site is a high-ROI task. It requires no design changes, no backend work — just updated link text or aria-label attributes. This is exactly the kind of item that belongs on a "chop list" for an accessibility sprint: low skill required, direct user impact, completable in hours not weeks.

Longer-term fix: If your CMS or component library generates download links, build the file type and size disclosure into the component itself. Pull file metadata at upload time and inject it into the accessible name automatically. Solve it once at the system level.

CORS Perspective

From a community impact lens, download link failures disproportionately affect blind and low-vision users who rely on screen readers, users with cognitive disabilities who need clear context before acting, and anyone on assistive technology navigating a page without structural landmarks. Operationally, the remediation cost here is genuinely low — this is a training and process gap, not a technology gap. Organizations that struggle with multi-standard compliance frameworks sometimes overlook these "small" fixes while chasing larger structural overhauls, but the cumulative impact of unaddressed download link barriers across a document-heavy site is significant. Strategically, building file metadata disclosure into component libraries converts a recurring manual fix into a solved problem — that's the kind of sustainable accessibility investment that moves organizations toward genuine maturity rather than perpetual remediation.