You ship interfaces; users need clarity. Here’s the short version: don’t stuff phone numbers or instructions into aria-* or title. Give links visible, specific text that matches their accessible name. Use ARIA only to fill genuine gaps, not to override what users can already see. These practices map directly to WCAG requirements on link purpose and “label in name,” and they cut cognitive load for everyone. I assume you aim for at least WCAG 2.1/2.2 Level AA compliance in modern browsers and AT (assistive technologies).
What goes wrong (and why it matters)
When you hide contact instructions inside aria-label/aria-labelledby or title, assistive tech announces bloated, off-purpose names for links like “Contact” or “Login.” That violates the intent of Link Purpose (SC 2.4.4), which requires that the link’s text—or its programmatic context—describe the destination, not unrelated info. It also risks failing Label in Name (SC 2.5.3) if the visible text says “Login” while the accessible name says something else. Users of voice control and screen readers rely on that alignment to operate quickly and accurately.
ARIA is not a content dumpster
The Accessible Name and Description Computation (AccName) spec defines how names are derived and warns against using aria-label/aria-labelledby to name elements when the element already has a proper text alternative. In plain terms: don’t override visible labels with ARIA unless there’s truly no visible label. When a visible label exists, prefer aria-labelledby pointing to that text—or better, let native HTML provide the name. This keeps what users see and what AT exposes in sync.
The title attribute is not your accessibility plan
Tooltips from title are inconsistently exposed: many touch, keyboard, and AT users never get them. Relying on title for essential information (like a phone number) is therefore unreliable and fails users. If the information is important, put it in visible text or in an obvious, dedicated accessibility statement or contact page. Keep title for genuinely supplemental hints you can afford to be ignored.
Redundant links create noise
Duplicate or adjacent links that go to the same URL (e.g., an icon link and a text link side-by-side) force keyboard users through extra tab stops and clutter link lists in screen readers. Combine the clickable region into one <a> element and (if there’s an icon) give the icon alt="" so it doesn’t double the text. This pattern is a documented WCAG technique and reduces cognitive load without losing affordances.
Write link text that does the job
Make link text specific to the destination. Avoid generic labels like “Click here” or overloaded strings that include instructions or phone numbers. Links should make sense out of context, work when listed by a screen reader, and be easy to speak for voice control. This is exactly what WCAG’s Link Purpose requires and what long-standing guidance from WebAIM and others describes.
Put accessibility contact info where users expect it
If you provide an accessibility help line or instructions, surface them on your Accessibility Statement and Contact pages, and link to those pages with clear text like “Accessibility support” or “Contact us.” Do not bury the phone number inside aria-label or title on unrelated controls. This keeps navigation predictable and auditable against your policy.
Bad vs. good: concrete patterns
1) Misusing aria-label on links
Bad
<a href="/contact"
aria-label="If you need help using this site, call 1-800-555-1234">
Contact
</a>
<a href="/login"
aria-label="If you need help using this site, call 1-800-555-1234">
Login
</a>Why it’s bad: The accessible name becomes a phone script, not “Contact” or “Login,” violating link purpose and label-in-name expectations.
Good
<a href="/contact">Contact</a>
<a href="/login">Login</a>
<!-- Accessibility help lives on dedicated pages -->
<a href="/accessibility">Accessibility statement</a>
<a href="/contact#accessibility-support">Accessibility support</a>2) Combining icon + text into one link
Bad
<a href="/shop"><img src="cart.svg" alt="Shop"></a>
<a href="/shop">Shop</a>Good
<a href="/shop">
<img src="cart.svg" alt="">
Shop
</a>Why it’s good: One tab stop; no duplicate link announcements. Documented as WCAG Technique H2.
3) Label in Name for controls
Bad
<button aria-label="Search the site">Go</button>Good
<button>
<span id="search-label">Search</span>
</button>
<!-- If you must name programmatically, mirror the visible text -->
<button aria-labelledby="search-label">
<span id="search-label">Search</span>
</button>Why it’s good: The words users see (“Search”) are the words AT exposes; voice users can say the visible label.
4) Don’t rely on title for essentials
Bad
<a href="/contact" title="Accessibility help: 1-800-555-1234">Contact</a>Good
<p>Accessibility support: <a href="tel:+18005551234">1-800-555-1234</a></p>
<a href="/contact">Contact</a>Why it’s good: Essential info is visible and operable; title can be missed by many users.
Practical checklist you can run in code review
- Does link text describe the destination? Rewrite vague labels and remove instructions/phone numbers from link text. Map to WCAG 2.4.4.
- Does the accessible name contain the visible words? If not, refactor with native labels or
aria-labelledby. Map to WCAG 2.5.3. - Are adjacent links consolidated? Merge icon/text pairs into one
<a>; set iconalt="". Use Technique H2. - Is
titlecarrying essential info? Move it into visible content; keeptitlenon-critical. - Is ARIA used to add, not replace, meaning? Avoid
aria-labelwhen a visible label exists; prefer native HTML. Follow AccName rules. - Do global “Accessibility” links exist? Provide a statement and clear support paths; link from footer and help areas.
Migration plan for existing sites
First, audit link text: export all anchors and their accessible names; flag any that don’t match visible words or that include instructions or phone numbers. Next, remove title from essential paths, moving its content into visible copy or dedicated pages. Then, consolidate redundant links by wrapping icon and text in one anchor and nulling icon alt. Finally, codify patterns in your design system: authoring rules for link text, a token for accessibility support links, and lint rules to block aria-label on anchors with visible text. This closes the loop from code review to CI and keeps regressions out. (Use the references above as acceptance criteria.)
Copy-paste templates
Accessibility statement footer link
<footer>
<nav aria-label="Legal and support">
<a href="/accessibility">Accessibility statement</a>
<a href="/contact">Contact</a>
</nav>
</footer>“Skip to main content” (good navigation affordance)
<a class="skip-link" href="#main">Skip to main content</a>
<main id="main">...</main>Voice-friendly control (Label in Name honored)
<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email">Bottom line
Name things the way users see them, and keep link text about destinations—not instructions. Use native HTML first, ARIA sparingly, and never rely on title for critical information. If you implement only three changes—rewrite vague link text, align accessible names with visible labels, and merge redundant links—you’ll fix the majority of real-world issues in minutes and align with WCAG.
Assumptions: You target WCAG 2.1/2.2 AA; support current evergreen browsers; and can update markup/CMS templates. If your environment differs, adapt the migration plan accordingly.
