Deep linking accessibility is rarely discussed, but it affects millions of users. When a screen reader user taps a deep link from an email, they need the app to announce where they landed and what actions are available. When a user with motor impairments opens a deep link landing page, the "Open in App" button needs to be large enough to tap accurately. When a user with cognitive disabilities follows a deep link, the transition from web to app should not be confusing.
This guide covers how to make your deep linking flows accessible. For banner design that converts, see app banner design best practices. For first-time user experience, see designing the first-time user experience.
Web Fallback Page Accessibility
Semantic HTML
Deep link landing pages must use semantic HTML for screen readers:
<!-- Accessible deep link landing page -->
<main role="main" aria-label="App content">
<h1>Product Name</h1>
<p>Description of the product the user was trying to view.</p>
<nav aria-label="App actions">
<a href="https://links.yourapp.com/products/shoes"
role="button"
aria-label="Open Product Name in YourApp"
class="cta-button">
Open in App
</a>
<a href="https://apps.apple.com/app/yourapp/id123"
aria-label="Download YourApp from the App Store">
Download on the App Store
</a>
<a href="https://play.google.com/store/apps/details?id=com.yourapp"
aria-label="Get YourApp on Google Play">
Get it on Google Play
</a>
</nav>
</main>
WCAG Compliance
Deep link landing pages should meet WCAG 2.1 AA standards:
| Criterion | Requirement | Deep Link Application |
|---|---|---|
| 1.1.1 Non-text content | Alt text for images | App icons, screenshots need alt text |
| 1.4.3 Contrast | 4.5:1 minimum | CTA buttons must have sufficient contrast |
| 2.4.4 Link purpose | Clear from context | "Open in App" not just "Open" |
| 2.5.5 Target size | 44×44 CSS pixels minimum | All touch targets on mobile |
| 3.2.5 Change on request | No unexpected context changes | Auto-redirect must be user-initiated |
Auto-Redirect Accessibility
Many deep link pages auto-redirect to the app store or the app. This is problematic for accessibility:
// BAD: immediate redirect with no user control
window.location.href = appStoreUrl;
// GOOD: give users control
function handleDeepLink() {
// Show the content page first
showContent();
// Offer a clear, accessible button for the redirect
const button = document.getElementById('openInApp');
button.focus(); // Move focus to the CTA
// Announce to screen readers
const liveRegion = document.getElementById('status');
liveRegion.textContent = 'You can open this content in the app or continue viewing on the web.';
}
<div id="status" role="status" aria-live="polite"></div>
<button id="openInApp"
aria-label="Open this product in the YourApp mobile application">
Open in App
</button>
<p>Or continue viewing below</p>
Smart Banner Accessibility
Native Smart Banners
Apple's native Smart App Banner is accessible by default. It appears at the top of the page, is announced by VoiceOver, and can be dismissed with standard gestures.
Custom Smart Banners
Custom banners must be manually made accessible:
<div role="complementary"
aria-label="App promotion banner"
class="smart-banner"
id="smartBanner">
<img src="/icon.png" alt="YourApp icon" width="40" height="40">
<div>
<strong>YourApp</strong>
<span>Free on the App Store</span>
</div>
<a href="https://links.yourapp.com/current-page"
role="button"
aria-label="Open this page in the YourApp mobile app">
Open
</a>
<button aria-label="Dismiss app promotion banner"
onclick="dismissBanner()">
<span aria-hidden="true">×</span>
</button>
</div>
Key accessibility requirements for custom banners:
- Dismissible: Users must be able to close the banner (not just with a tiny X).
- Not blocking content: The banner should not cover page content.
- Keyboard navigable: Users can tab to the banner actions.
- Screen reader announced: The banner's purpose is clear from ARIA labels.
In-App Accessibility After Deep Link
Focus Management
When a deep link opens the app to a specific screen, set the accessibility focus correctly:
// iOS: Set VoiceOver focus after deep link navigation
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
if isDeepLinkNavigation {
// Announce the destination
UIAccessibility.post(
notification: .screenChanged,
argument: "Viewing \(product.name). \(product.price)"
)
// Focus on the main content
DispatchQueue.main.asyncAfter(deadline: .now() + 0.5) {
UIAccessibility.post(notification: .layoutChanged, argument: self.titleLabel)
}
}
}
// Android: Set TalkBack focus after deep link navigation
override fun onResume() {
super.onResume()
if (isFromDeepLink) {
// Announce the destination
titleView.announceForAccessibility(
"Viewing ${product.name}. Price: ${product.price}"
)
// Focus on the main content
titleView.sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_FOCUSED)
}
}
Error State Accessibility
When a deep link fails (content not found, access denied, expired), the error must be accessible:
func showDeepLinkError(_ error: DeepLinkError) {
let message: String
switch error {
case .notFound:
message = "The content you're looking for is no longer available."
case .accessDenied:
message = "You don't have permission to view this content."
case .expired:
message = "This link has expired."
}
// Display visually
errorLabel.text = message
// Announce to screen readers
UIAccessibility.post(notification: .announcement, argument: message)
// Provide an accessible action to recover
let homeButton = UIButton()
homeButton.setTitle("Go to Home", for: .normal)
homeButton.accessibilityLabel = "Go to the app home screen"
homeButton.accessibilityHint = "The content from your link was not available"
}
Inclusive Link Design
Link Text
Deep link text (in emails, messages, notifications) should be descriptive:
BAD: "Click here: https://yourapp.com/dl/abc123"
BAD: "Open link"
GOOD: "View your order details"
GOOD: "Join the team project"
Screen readers often list all links on a page. "Click here" repeated five times is unusable.
QR Code Accessibility
QR codes are visual and inaccessible to blind and low-vision users. Always provide an alternative:
<div class="qr-section">
<img src="/qr-code.png"
alt="QR code linking to yourapp.com/menu/summer-2026"
width="200" height="200">
<p>Scan the QR code or visit:
<a href="https://yourapp.com/menu/summer-2026">yourapp.com/menu/summer-2026</a>
</p>
</div>
Reduced Motion
Deep link transitions (web to app, screen animations) should respect the user's reduced motion preference:
func animateDeepLinkTransition() {
if UIAccessibility.isReduceMotionEnabled {
// Skip animation, show content immediately
contentView.alpha = 1
} else {
UIView.animate(withDuration: 0.3) {
self.contentView.alpha = 1
}
}
}
/* Web fallback page: respect prefers-reduced-motion */
@media (prefers-reduced-motion: reduce) {
.deep-link-transition {
animation: none;
transition: none;
}
}
Testing Deep Link Accessibility
Manual Testing Checklist
- VoiceOver (iOS) / TalkBack (Android): Navigate through the deep link flow entirely with a screen reader.
- Keyboard navigation: Tab through the web fallback page. Can you reach and activate all actions?
- Large text: Enable large text settings. Does the landing page remain usable?
- High contrast: Enable high contrast mode. Are CTA buttons still visible?
- Switch control: Navigate with switch control. Is the flow completable?
Automated Testing
// Use axe-core to test web fallback pages
const axe = require('axe-core');
describe('Deep link landing page accessibility', () => {
it('has no critical violations', async () => {
const results = await axe.run(document);
const critical = results.violations.filter(v => v.impact === 'critical');
expect(critical).toHaveLength(0);
});
});
Tolinku and Accessibility
Tolinku generates web fallback pages and smart banners that follow accessibility best practices. Smart banners include proper ARIA labels, dismissible controls, and sufficient contrast ratios. Configure your deep links in the Tolinku dashboard.
For banner design that converts while remaining accessible, see app banner design best practices.
Get deep linking tips in your inbox
One email per week. No spam.
