Oh shit, my app is successful and I didn't think about accessibility

Original Article ↗ Hacker News Discussion ↗

Separate Accessible Versions vs Inclusive Design

  • Some propose distinct “low-vision” / “low-touch-accuracy” versions or data-only frontends.
  • Others argue this is unrealistic: organizations won’t maintain feature parity, so secondary apps rot.
  • Analogy to responsive design: better to have one UI that adapts than multiple sites.
  • Legal and ethical objection: “separate but equal” rarely is; parity over time is hard to guarantee.

Legal Liability and Regulation

  • In the US, ADA lawsuits against websites and apps are rising; often small settlements but expensive remediation.
  • Certain sectors (universities, hiring sites, government) face stronger pressure because inaccessibility blocks protected activities.
  • EU Accessibility Act (from 2025) will require many products/services to be accessible; micro‑enterprises may be exempt but encouraged.
  • Some see enforcement as necessary due to otherwise weak incentives; others see it as tort abuse and regulatory burden.

Prioritization, Cost, and Startups

  • Common view: early-stage products focus on survival and product–market fit, adding a11y later.
  • Counterpoint: like security or scalability, basic a11y is cheaper if considered from the start (alt text fields, non-drag alternatives, semantic HTML).
  • Disagreement over impact: some treat affected users as a tiny edge case; others note stats suggesting a significant market share.

Moral and Lived-Experience Arguments

  • Multiple personal stories (blindness, low vision, wheelchairs, amputation, parenting with strollers) show how design choices materially enable or block daily life.
  • Many stress that nearly everyone becomes disabled eventually, or faces temporary impairments.
  • Several disabled readers describe hostility or dismissal when raising a11y concerns, and fatigue from repeatedly justifying their needs.

Technical Approaches and Tooling

  • Strong recommendations to:
    • Use native UI components and OS accessibility APIs (iOS, Android, modern toolkits like Flutter, SwiftUI, Compose, GTK).
    • Rely on semantic HTML, proper roles, labels, and ARIA only when needed.
    • Avoid “overlay” widgets that try to bolt on a11y and often worsen UX and legal risk.
    • Test with screen readers, large text, high contrast modes, and accessibility trees.
  • Some note that browsers and assistive tech could do more (ML transformations, better primitives), but others argue you can’t fix bad custom widgets at the browser level without “taking away all the toys.”

Accessibility Benefits Everyone

  • Examples: ramps and curb cuts, subtitles, larger targets, high-contrast text, reduced motion, keyboard navigation, screen readers for multitasking.
  • Framing suggestion: think of a11y as flexibility and user control, not only disability accommodation.

Controversies and Pushback

  • A minority argue a11y mainly serves a very small population, is too costly, or should be the user’s problem via “special browsers.”
  • Others push back strongly, calling this unethical and noting that much work is modest (labels, contrast, semantics).
  • Disagreement over how far mandates should go and how to balance costs vs inclusivity; some want strict regulation, others fear it entrenches large incumbents.

Terminology and Communication

  • Debate over the numeronym “a11y”: some like its discoverability and “ally” pun; others note it’s less screen‑reader‑friendly and arguably ironic for accessibility.