Accessibility at Letterbench

Letterbench is designed to be usable by everyone, including people who navigate with screen readers, keyboards only, reduced motion preferences, or higher-contrast display settings. This page describes what we do, what we don't do yet, and how to tell us when we get it wrong.

Our commitment

Every page on letterbench.com is designed to conform to WCAG 2.2 Level AA, the success-criteria standard most commonly used as the practical benchmark for ADA-aligned accessibility on the web. We use WCAG 2.2 AA as our target because:

• It is the most current published version of the W3C accessibility standard
• It is the standard cited by the US Department of Justice in its April 2024 final rule for state and local government websites
• It is the de facto benchmark plaintiffs' counsel use when reviewing public-accommodation websites under ADA Title III

We do not claim to be "ADA compliant." Accessibility is not a binary state, and no automated tool, internal audit, or even third-party audit can guarantee universal access to every user across every assistive technology configuration. We do claim to design, test, and refine the site toward the WCAG 2.2 AA standard, and to fix issues we learn about within a defined timeline.

What we currently do

• Automated testing on every commit + daily. All pages are scanned against WCAG 2.2 AA using two complementary tools: pa11y (HTML_CodeSniffer engine) and axe-core 4.x (Deque) via Playwright. axe-core typically catches 3-5× more issues than pa11y alone because it covers ARIA, color-contrast, focus management, and WCAG 2.2 success criteria more comprehensively. As of 2026-06-10, all 15 published pages pass with zero critical and zero serious axe violations. Moderate-impact issues (landmark structure refinements) are tracked and resolved as they arise.
• Daily mobile-UX regression check. A Playwright-driven scan runs across all sitemap URLs at three mobile viewports (iPhone SE 375px, iPhone 11 Pro Max 414px, Android 360px). Catches horizontal-scroll, tap-target-size-under-24px, font-size-under-12px, text-clipping, missing-hamburger-fallback, iOS-form-zoom-on-focus, and viewport-meta issues. As of 2026-06-10, all pages pass with zero hard failures.
• Color contrast at the AA level. Body text is set against a warm off-white background at a contrast ratio above 5:1 (AA requires 4.5:1 for normal text). Headings, metadata, and decorative elements use color values vetted against the same standard.
• Keyboard-first navigation. Every interactive element on the site — links, buttons, form inputs, sliders — is reachable via keyboard alone. A skip-to-main-content link appears as the first tab stop on every page.
• Programmatic labels on all form controls. Email signup fields and interactive calculators use <label for> association plus aria-valuetext on range sliders so screen readers announce both the control name and the current value.
• Semantic HTML and landmark structure. Pages use <main>, <section>, <article>, <figure>, and a single <h1> followed by ordered heading hierarchy.
• Reduced-motion preference respect. Users who set prefers-reduced-motion: reduce at the operating-system level receive a version of the site with animations and smooth scrolling disabled.
• Visible focus indicators. A branded outline replaces the default browser focus ring on every interactive element.

What we don't do yet

In the spirit of editorial honesty, here is what is genuinely unverified or in-progress:

• No third-party audit has been conducted. Our scanning is internal and automated. A formal third-party accessibility audit (by a firm such as Deque, Level Access, or AudioEye) has not been commissioned as of this writing.
• Manual screen-reader testing is intermittent. We test with VoiceOver on macOS prior to major design changes, but we do not currently run full regression passes with NVDA on Windows, JAWS, or TalkBack on Android.
• Embedded third-party content (Beehiiv subscribe forms, Vercel Analytics scripts) may not meet our internal standard. We have minimal control over the rendered output of these embeds.
• The Beehiiv-hosted newsletter web archive (letterbench.beehiiv.com/p/...) is rendered by Beehiiv's templates and falls outside our direct control. As of our most recent axe-core scan (2026-06-10), Beehiiv's post page template has one critical violation (button-name — social-share icons without discernible text), one moderate violation (landmark-one-main — no <main> element on the page), and a region violation (multiple elements outside landmarks). Our editorial content within the body is structured semantically (proper heading order, descriptive link text, no images without alt text), but the surrounding platform chrome is a known limitation of using Beehiiv as our publishing platform.
• Email newsletter rendering is governed by the email service provider (Beehiiv) and the recipient's email client. Our drafts use semantic markdown structure and descriptive link text, but rendered output varies. Critical email client variations: Microsoft Outlook (Windows desktop) handles modern HTML/CSS poorly; Apple Mail on iOS/macOS renders well with VoiceOver; Gmail on web is generally accessible; Gmail mobile apps vary.
• Mobile touch targets are sized at our component level toward the 44×44 px guideline, but a comprehensive mobile-tap audit has not been completed.

How to report an issue

If you encounter a barrier on letterbench.com that prevents you from accessing content, please tell us. We respond to accessibility reports within 5 business days, and we prioritize accessibility fixes ahead of other product work.

• Email: accessibility@letterbench.com (caught by the same inbox as corrections@ and hello@)
• What to include: The page URL, a brief description of what you tried to do, what happened instead, and any assistive technology you were using (e.g. "VoiceOver on macOS 15, Safari 17")
• Expected response: Acknowledgment within 5 business days, status update on the fix timeline within 10 business days, and notification when the fix ships

If your report involves a barrier you encountered while attempting to do something time-sensitive (a sign-up, a purchase, a contact request), please note that — we'll prioritize accordingly.

Standards we reference

• WCAG 2.2 — Web Content Accessibility Guidelines, Level AA target
• WAI-ARIA Authoring Practices — pattern reference for interactive components
• US DOJ April 2024 rule on web accessibility — the regulatory framework most directly applicable to public-accommodation websites in the United States

Versioning

This page is reviewed quarterly alongside the rest of the site's content standards. Material changes to our accessibility approach, tooling, or testing cadence will be reflected here within 14 days of the change.

Last reviewed: 2026-06-01. Next scheduled review: 2026-09-01.