Accessibility Statement

We target WCAG 2.1 Level AA across this website. As of September 23, 2026 we describe the site as partially conformant with WCAG 2.1 Level AA: the core flow — fill the form, preview, pay, download — is operable with a keyboard alone and the text contrast on ordinary pages is well above the AA floor, but the items listed under Known limitations are open, and we have not yet run assistive technology against our own pages. We would rather publish that split than claim a conformance level we have not measured.

The measures we point at, because European accessibility rules refer to them: EN 301 549 (the European technical standard for ICT accessibility, which incorporates the WCAG success criteria) and the European Accessibility Act (Directive (EU) 2019/882), whose requirements for e-commerce services have applied since June 2025. We are a United States–based operator that sells to anyone who finds us, including people in the EU. We have not taken legal advice on whether we are in scope of that Directive; this statement is about what we checked and what we found, which is the part we can state accurately.

Last reviewed: September 23, 2026. The review covered the four surfaces a customer or a complainant actually touches — the landing page, the pay stub builder including its checkout hand-off, the policy and legal pages, and the abuse and takedown form — against the markup, the keyboard path, the accessible-name computation implied by the markup, and the color tokens the interface is built from.

How. A line-by-line reading of the rendered markup for the checks that markup decides: every input has a label associated with it, error text is referenced by aria-describedby and paired with aria-invalid, form submission is a real submit rather than a click handler where a submit is expected, heading levels nest without skips, the document language is declared, images and icons are either decorative or named, focus is visible rather than suppressed, and no function depends on color alone. Contrast numbers in this statement were computed from the same color tokens the site ships, not sampled from a screenshot.

What this review is not. It is not an assistive-technology test and not a user test. We did not drive these pages with NVDA, JAWS, VoiceOver, Dragon or a switch, and no disabled person has been paid to try them. Where this page says a control has no accessible name, that is our reading of the markup; it is the kind of claim that needs an AT run before it becomes evidence, which is why the conformance statement above says partially.

What we can state positively from that same audit: the site loads no third-party analytics or advertising scripts, so there is no injected widget to break the accessibility tree; the document language is declared on every page; pages have a single top-level heading and a main content region; forms use native, labelable controls on the report page; the live preview area carries a polite status region; interactive components come from a Radix-based primitive set that implements the WAI-ARIA Authoring Practices keyboard patterns, which is why the widgets are keyboard-operable by construction — the gaps below are labeling and contrast, which no component library can decide for us; and motion is reduced when the operating system asks for it.

Each item is one thing we found, in the order it is likely to bite. These are open, not disputed, and each one ships as a fix this page gets updated.

1. Every pageThere is no “skip to main content” link, so a keyboard user tabs through the header links again on every page before reaching the form or the article.Who it affects: Keyboard and switch users; anyone navigating by Tab rather than by mouse.WCAG 2.4.1 Bypass Blocks (Level A)
2. The pay stub builder formThe five sections of the form — Employer, Employee, Pay period, Earnings, Deductions — are styled headings rendered as plain container elements, not real headings. The page therefore has exactly one heading, and there is nothing to jump between.Who it affects: Screen reader users who navigate by heading; anyone orienting in a long form.WCAG 1.3.1 Info and Relationships (Level A), 2.4.6 Headings and Labels (Level AA)
3. “Pay type” (Hourly / Salary) and “Pay frequency” on the builderThe visible label for these two controls is attached with a plain label element pointing at a widget that is not a native form control, so the group and the combo box have no accessible name. A screen reader announces the current value (“Hourly”, “Biweekly”) without saying which field it belongs to, and the “Pay type” radio group is announced as an unnamed group.Who it affects: Screen reader users (NVDA, JAWS, VoiceOver) on the two controls most likely to be filled in wrong.WCAG 4.1.2 Name, Role, Value (Level A), 1.3.1 Info and Relationships (Level A)
4. Deduction lines on the builderEvery deduction row labels its two inputs the same way (“Deduction name”, “Deduction amount”) with no row number, and its remove button says only “Remove deduction”. With four rows added, a screen reader user cannot tell which row is about to be removed.Who it affects: Screen reader users editing more than one deduction.WCAG 1.3.1 Info and Relationships (Level A), 2.4.6 Headings and Labels (Level AA)
5. The “Total deductions exceed gross pay” message on the builderThis whole-form error appears as visible text but is not tied to any control and is not in a status region, so it can appear while a screen reader user is focused elsewhere and never be announced.Who it affects: Screen reader users; magnification users whose viewport does not include the message.WCAG 3.3.1 Error Identification (Level A), 4.1.3 Status Messages (Level AA)
6. Pressing Enter in the optional email box at checkoutThe pay button is a separate button outside the form’s implicit submission path, so pressing Enter in the email field runs a validation-only submit that has no visible or announced effect. It looks frozen; it is not.Who it affects: Keyboard users who submit with Enter instead of Tab-then-Space.WCAG 3.2.2 On Input (Level A), 2.1.3 Keyboard (Level AAA — noted, not claimed)
7. The focus ring on inputs, buttons and dropdownsThe native outline is removed and replaced with a 3px ring drawn at 50% opacity of the brand blue. Computed against the white page background that is about 2.1:1, under the 3:1 floor for a focus indicator.Who it affects: Low-vision keyboard users; anyone who loses their place in a form.WCAG 1.4.11 Non-text Contrast (Level AA)
8. Error text on its pale tint (validation messages, the report form’s error summary)Destructive red text on the 10% red tint computes to roughly 4:1 in light mode — legible, but under the 4.5:1 floor for body-sized text. On a plain white background the same red is about 4.8:1 and passes.Who it affects: Low-vision users reading error messages on a colored panel.WCAG 1.4.3 Contrast Minimum (Level AA)
9. The header and footer link listsPages that carry both a header link list and a footer link list expose two “navigation” regions with no names, so the landmark list reads “navigation, navigation”.Who it affects: Screen reader users who jump between landmarks.WCAG 1.3.6 Identify Purpose (Level AAA — noted, not claimed)
10. The PDF you downloadA generated pay stub is laid out for print. We have not tested it with a PDF reader’s reflow or read-aloud features, and we make no accessibility claim about the file itself — only about this website.Who it affects: Anyone who receives a downloaded pay stub rather than using the site.Outside the scope of this statement; recorded because a document service should not imply otherwise.
11. Everything on this pageThis review was a source-code audit plus hand-computed contrast from our own color tokens. No assistive technology was run against these pages, no user testing with disabled people, and no third-party audit. A finding of “no accessible name” inferred from markup can be wrong once a real screen reader disagrees with our reading.Who it affects: Everyone relying on this statement as evidence.Method limitation, not a success-criterion finding.

The order we intend to fix them in, most blocking first: a skip-to-content link site wide; real headings for the builder sections; an accessible name on the pay-type group and the frequency combo box; per-row labels on deduction lines; the whole-form over-deduction message moved into a status region; the focus indicator raised to at least the 3:1 floor; the error-text-on-tint pair darkened; and named navigation regions. Then the step that makes this statement evidence rather than inference: a pass through the same four surfaces with a screen reader and keyboard only, written up here with the date it was done.

We are a small operation, so this page states a direction rather than a deadline. When one of these ships, the item comes off the list above and the Last reviewed date moves.

If something here is hard to use, tell us and we will treat it as a bug report: which page, what you were trying to do, which browser and assistive technology you were using, and what happened instead. We read this address ourselves — support@paystubs.shop — and we aim to acknowledge an accessibility report within 2 business days and reply substantively within 10. If you report something that is genuinely broken, the useful thing to include is the exact control, not a general description; the faster we can reproduce it, the faster it leaves the list above.

Reports about a document generated with someone else's name go to the same place through a different door — the abuse and takedown page — and they are handled as compliance reports rather than feedback.

If you are not satisfied with how we handle an accessibility complaint, and you are in an EU member state, you can escalate to that state's market-surveillance authority under the national framework implementing Directive (EU) 2019/882. We did not name a specific authority here because we are not established in the EU; your national authority's contact details are published by your government.

Prepared by the operator of this site. Last reviewed September 23, 2026. Method: static audit of the shipped markup and design tokens across the surfaces listed above; no assistive-technology testing and no third-party audit in this revision. The next revision is the assistive-technology pass described under What we are doing about it.