Accessibility at WeSearch.

The honest version: WeSearch is a single-developer project and our accessibility coverage isn't perfect. Some things work well; some things have gaps we know about and are working on; and some things are probably broken in ways we haven't caught yet. This page is the inventory and how to tell us when something's wrong.

What we've done

Semantic HTML

Every page uses semantic landmarks (<header>, <main>, <article>, <footer>, <nav>). Headings follow document order (one H1 per page; H2 for major sections; H3 for sub-sections). Article bodies use <p>, <ul>, <ol> rather than visual fakes.

Keyboard navigation

All interactive elements are reachable by Tab. Buttons are real <button> elements, links are <a> elements with proper href values. The mobile category dropdown is a real <select> so it picks up the OS picker.

Screen-reader labels

Icon-only buttons have aria-label values describing the action. The reaction icons have aria-label matching their meaning ("Like", "Love", "Fire", "Laugh", "Think"). The bell badge announces the unread count.

Color contrast

Body text contrast against the dark editorial background meets WCAG AA at 4.5:1 or better. The accent red (#C8302C) on the dark background also passes AA for normal text. The muted utility text (#9CA0AB) is large-text only — we use it for monospace metadata where contrast at small size is less critical.

Motion and reduced-motion

Animations (the bell shake on a new notification, the chevron rotate on the editor's note) are short and don't block reading. We don't yet honor prefers-reduced-motion across the entire site; that's on the todo list.

Focus indicators

Default browser focus indicators are preserved on most elements. Some buttons have custom focus rings. We've avoided outline:none without replacement.

What we know is imperfect

• Reaction emoji-style buttons. The new SVG-based reactions have aria-labels, but the touch target on mobile is tighter than ideal (around 32px). We're widening to a 40px min for the next pass.
• Editor's note expand/collapse. Works with keyboard, but the chevron's rotation isn't announced to screen readers as a state change. We're adding aria-expanded announcements.
• Comment thread depth visualization. Indentation is purely visual; screen readers don't get a clear sense of nesting beyond the comment ordering. We're considering a role="tree" approach but the trade-offs aren't clean.
• Reduced-motion. Site-wide prefers-reduced-motion support is partial. The bell-shake and editor's-note expand animations should respect it; some others don't yet.
• Form validation. Comment-post errors don't yet move focus to the error message in all cases.

What we'd like to add

• Skip-to-content link at the top of each page.
• Comprehensive prefers-reduced-motion coverage.
• High-contrast theme option (the dark editorial palette is fine for most users; we know some need higher contrast).
• Better keyboard shortcuts documentation in the FAQ.

How to report an issue

If you hit something that doesn't work for you, please send /support a description with:

• The page URL where the issue happened
• What assistive tech you were using (screen reader name + version, keyboard-only, voice control, switch, etc.)
• What you expected to happen
• What actually happened

We treat accessibility bugs as priority. Most should ship a fix within a working week. We'll reply confirming the fix is live or explaining why it's harder than expected.

Our standard

We aim for WCAG 2.1 AA across the site. We don't claim full compliance because audit-and-claim is a high bar and a single-developer project hasn't been third-party audited. Reader reports are the closest thing we have to an audit, and we treat them seriously.

Why accessibility on a news aggregator matters

News is one of the categories where accessibility shortfalls fall hardest. Readers using screen readers, switch controls, voice navigation, or magnification rely on news in the same way everyone else does — to follow current events, participate in discussion, and stay informed. A news site that fails accessibility silently excludes a meaningful fraction of readers from the basic civic activity of staying informed. That's a worse failure mode than a poorly accessible game site or a niche e-commerce store, and it deserves more attention than it usually gets.

The structural fact is also that accessibility usually pays for itself. Semantic HTML, keyboard navigation, and clean focus indicators are the same things that make a site fast, low-bandwidth, and resilient against bad CSS. A site that works well with a screen reader usually also works well with a slow phone, a flaky connection, and a printed page.

What works particularly well

• Reading on a screen reader. Article bodies are clean prose with proper heading structure. The chronological feed has clear story-card boundaries.
• Keyboard-only navigation. Tab through every interactive element; Enter activates; Escape dismisses overlays. No mouse required for any feature.
• High-magnification reading. The editorial layout reflows cleanly to 400% zoom without horizontal scrolling.
• Slow-connection reading. Pages typically under 60 KB on first load; under 5 KB on warm cache. The site loads on 2G.
• Print stylesheet. Article pages have a print stylesheet that strips chrome and renders cleanly.

Common assistive-tech walkthroughs

Screen reader (NVDA / VoiceOver / Orca). Land on a story page; press H to skim headings; press D to land on the article landmark. Comments are a separate landmark below the article. Most readers report the experience as legible.

Keyboard only. Tab through the top nav; Tab into the story grid; Enter on a card opens the story. Tab into the comment composer; Enter submits. No keyboard traps known.

Voice control. Buttons have descriptive labels for "click [name]"-style commands. The comment composer accepts dictation via the OS microphone.

Bottom line

• WeSearch isn't third-party audited but tries to honor WCAG 2.1 AA across the site.
• Reader reports of accessibility issues are treated as priority bugs; we usually fix within a week.
• If you can't use the site for any reason, email support and we'll fix it or explain why it's harder than expected.
• Accessibility is also a privacy and performance feature: the same simplifications that help screen readers also help slow phones and low-bandwidth connections.

Frequently asked