For Everyone

Accessibility

Last updated June 2026

Verdict is designed to be usable by as many people as possible — including those using screen readers, keyboard-only navigation, voice control, and assistive technologies. This page explains what we’ve done, what we’re still working on, and how to ask for help.

Our Target

We aim to meet or exceed the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. WCAG is the industry standard referenced by the Americans with Disabilities Act (ADA) Title III and most international accessibility laws.

What We’ve Done

  • Landmark structure — a single top-level<main>, a site-wide header, and the search form marked as a role="search" landmark so screen readers can skip directly to it.
  • Keyboard navigation — every interactive element (buttons, links, search, cropper handles, form fields) is reachable with the Tab key and activatable with Enter or Space.
  • Visible focus rings on every focusable control, plus a global fallback so even controls without custom styles show a clear focus indicator.
  • Sticky-header offset — when Tab moves focus to an element that would otherwise land under the sticky site header, the browser scrolls with a 96-pixel top margin so the focused element is always visible.
  • Modal dismissal — any modal dialog (card cropper, quick import, photo picker) closes on Escape in addition to the visible close button.
  • ARIA state announcements — toggle chips (e.g. Variants & Parallels, Insert Sets) expose their pressed state viaaria-pressed; the active image in a carousel usesaria-current; loading and search status updates announce through polite live regions.
  • Descriptive labels — icon-only buttons (remove, close, carousel arrows, AI Snap) carry a spoken label; decorative icons are hidden from screen readers so they’re never read twice.
  • Form input labels — every visible input on the Collection, Watchlist, and Lot Calculator add-forms is labelled, even when only a placeholder is shown visually.
  • Semantic HTML — headings, lists, navigation, form elements, and long-form prose all follow proper structure so screen readers announce content in the correct order.
  • Color contrast — text meets WCAG AA contrast ratios against its background; critical verdict signals (green-up / red-down trend arrows, signal-red warnings) are always paired with text so color is never the only way meaning is conveyed.
  • Touch targets — primary interactive elements on mobile are sized at 36×36 CSS pixels or larger, with ≥40×40 on critical controls (modal close, carousel arrows, Take Photo / Upload, remove buttons). Comfortable for thumbs at a card show.
  • Alt text on images — card thumbnails, listing photos, and feature illustrations include descriptive alt attributes; decorative images and icons are marked so screen readers skip them.
  • Reduced motion — animations respect the OS-level “prefers-reduced-motion” setting where feasible.
  • Zoom and text resizing — the viewport is unlocked; users may pinch-to-zoom up to 500% on mobile or scale up text in the browser without breaking layout on primary pages.

Known Limitations

We’re being candid about areas where the experience isn’t perfect yet:

  • The card cropper (used in the Grade Tool) supports pointer drag and tap-to-place corner adjustment, and offers a one-tap Re-run with AI fallback when the auto-crop is off. Fine keyboard-only corner adjustment is still limited — if you need to crop a card without a pointer or touch input, contact us for an alternate workflow.
  • The price trend chart conveys data visually. The headline numbers (fair market value, weighted recent, low, high, sales volume) are all available as plain text above and around the chart, but pure chart exploration by screen reader is limited. A tabular data view is planned.
  • Some third-party embeds (eBay outbound links, listing thumbnails) inherit the accessibility profile of the upstream service, which we can’t directly control.

Assistive Technology Compatibility

Verdict is built to be compatible with the following assistive technologies. We run automated accessibility tooling against every deploy; full manual screen-reader verification for every feature is an ongoing effort.

  • Screen readers — VoiceOver (macOS, iOS), TalkBack (Android), NVDA (Windows), JAWS (Windows).
  • Browsers — current versions of Chrome, Safari, Firefox, and Edge.
  • Voice control — Voice Control (macOS, iOS) and Voice Access (Android) for navigating and invoking features.

Feedback and Accommodations

If you encounter a barrier, have a suggestion, or need a specific accommodation, please reach out through the Contact page. We’ll respond within 5 business days and work with you to provide the requested information or service in an accessible way.

When reporting an issue, it helps to include:

  • The page URL where you ran into the barrier.
  • The browser and assistive technology you’re using (e.g., “Safari with VoiceOver on iPhone”).
  • A description of what you expected vs. what happened.

Ongoing Work

Accessibility isn’t a box we check once. As the tool evolves we run new features through the same accessibility tests and update this page when standards or capabilities change. Material updates will bump the “Last updated” date at the top.

Formal Complaints

If you believe a barrier on this site constitutes discrimination under the Americans with Disabilities Act (ADA), you may file a complaint with the U.S. Department of Justice at ada.gov. We’d much rather hear from you first so we can fix the issue directly — get in touch.