Accessibility

Built to be used by everyone.

Job seekers can't afford a tool that locks them out. This page is our honest report on where ResumeDesignr stands against the Web Content Accessibility Guidelines (WCAG) 2.1, what we've actively tested, and where we know we still have work to do.

Last reviewed: March 2026 · Conformance target: WCAG 2.1 Level AA · Current status: Substantially conformant

Conformance statement

ResumeDesignr is substantially conformant with WCAG 2.1 Level AA. "Substantially" means most success criteria are met across the application, with documented partial conformance on a small number of items listed below. We have not yet completed a formal third-party VPAT (Voluntary Product Accessibility Template) audit — we'll publish one when we do, and we'd rather over-disclose than mislead.

We treat accessibility as a continuous responsibility, not a one-time checkbox. Every new feature is reviewed against this list before shipping, and the criteria table on this page is updated after each audit pass.

What's already in place.

Full keyboard control

Build, share, and download a resume without ever touching a mouse. Tab order matches the visual flow on every page.

Visible focus states

Every focusable element renders a brand-coloured focus ring so you always know where you are.

Screen-reader friendly

Tested with VoiceOver (macOS / iOS) and NVDA (Windows) on the core flows: signup, building a resume, exporting, and sharing.

Generous touch targets

All buttons and form controls meet or exceed the 44×44 px touch target size on mobile.

Resizable type

Browser zoom to 200% (and beyond) works without content overlap or horizontal scrolling.

WCAG 2.1 status report.

Per-criterion conformance. Where we say partial, the specific gap is named.

Perceivable

1.1.1

Non-text content

Conformant

All site imagery is either an SVG logo or user-uploaded photos rendered with descriptive `alt` text. We have no decorative imagery without accessible alternatives.

1.3.1

Info & relationships (semantic HTML)

Conformant

Built on Radix UI primitives via shadcn/ui, which uses correct semantic elements (`<button>`, `<nav>`, `<header>`, `<main>`, `<dialog>`) and ARIA attributes by default.

1.3.5

Identify input purpose (autocomplete)

Partial

Login, signup, billing, and contact forms include `autocomplete` attributes. Some longer profile fields (e.g. headline, project descriptions) do not — these are bespoke and don't map to standard autocomplete tokens.

1.4.3

Contrast (minimum) — text

Conformant

Brand palette uses dark ink (#0f172a) on canvas (#fbfaf8) — contrast ratio 14.5:1, well above the 4.5:1 AA minimum. Accent violet (#26215C) on canvas also exceeds AA.

1.4.4

Resize text to 200%

Conformant

Layout uses rem-based sizing and fluid containers. Verified manually at 200% zoom in Chrome and Firefox.

1.4.10

Reflow (responsive)

Conformant

Fully responsive down to 320px wide. No horizontal scrolling at common breakpoints.

1.4.12

Text spacing

Conformant

Line-height, letter-spacing, paragraph spacing all settable without breaking layout.

Operable

2.1.1

Keyboard accessibility

Conformant

Every interactive element is reachable and operable by keyboard. Includes the resume builder, ATS panel, and the dashboard activity modal.

2.1.2

No keyboard trap

Conformant

Modals (Radix Dialog) properly trap focus inside open dialogs and restore focus on close.

2.4.3

Focus order

Conformant

Tab order follows visual reading order on all primary pages.

2.4.4

Link purpose (in context)

Conformant

Navigation, CTAs, and inline links have descriptive text. No raw "click here".

2.4.6

Headings & labels

Conformant

Pages use a single `<h1>` followed by structured `<h2>`/`<h3>` hierarchy. Form fields have visible labels associated via `htmlFor` / `id`.

2.4.7

Focus visible

Conformant

Brand-coloured `focus-visible:ring-2 focus-visible:ring-violet-deep/40` applied across buttons, inputs, links, and the testimonial carousel dots.

2.5.3

Label in name

Conformant

Visible button text matches the accessible name for screen readers.

Understandable

3.1.1

Language of page

Conformant

`<html lang="en">` set globally.

3.2.1

On focus (no surprise navigation)

Conformant

Focus never triggers navigation or modal popups without explicit user action.

3.3.1

Error identification

Partial

Form errors are shown adjacent to fields with text. We don't yet announce errors via `aria-live` on every form — work in progress.

3.3.2

Labels & instructions

Conformant

All form inputs have associated labels and, where relevant, helper text or placeholder examples.

Robust

4.1.2

Name, role, value

Conformant

Radix UI primitives expose correct ARIA roles. Custom interactive components (sparkline dots, view-tracking badge, GCC photo upload) carry explicit `aria-label`s.

4.1.3

Status messages

Partial

Toast notifications use the Sonner library with the `status` role. Some asynchronous loading states (e.g. autosave) are visible but not yet wired to `aria-live` regions.

Compatibility

We actively test ResumeDesignr against:

Browsers: latest two stable versions of Chrome, Firefox, Safari, and Edge.
Screen readers: VoiceOver (macOS & iOS), NVDA (Windows). JAWS is on our roadmap.
Operating systems: macOS 13+, Windows 10+, iOS 16+, Android 11+.
Touch & pointer: mouse, trackpad, touch screens, stylus.

We don't formally test against Internet Explorer or browsers older than two major versions. Some experiences may degrade there.

Known limitations.

Live regions on async actions

Autosave indicators, ATS score recalculation, and tailoring-progress states are visible but not yet announced through ARIA live regions. Sighted users see the state change; screen reader users may need to re-focus the area.

Formal third-party VPAT

We haven't yet engaged an external accessibility firm to produce a VPAT. Planned for Q3 2026.

High-contrast / forced-colours mode

The brand palette renders well in default and dark schemes, but we haven't exhaustively audited Windows High Contrast Mode. If you rely on it, please email us — we'll prioritise specific feedback.

Generated content (your resume)

The PDFs and DOCX files you export contain a real text layer (good for assistive tech) and we automatically tag headings. However, accessibility of the final document also depends on the content you write. We don't enforce alt text on imported photos, for example.

Found an accessibility issue?

Email us with as much detail as you can share (browser, assistive technology, the page you were on, what didn't work). We aim to acknowledge accessibility reports within 2 business days and prioritise them ahead of feature work.

Mail goes to the same inbox as info@resumedesignr.com; an actual person reads it.