Accessibility Statement

1. The standard we are working to

We target the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. That is the standard the U.S. Department of Justice looks to for public accommodations under the Americans with Disabilities Act, and it is the standard we hold this site to whether or not the ADA reaches us.

We are not claiming a perfect conformance score, and we have not bought a certificate from an overlay vendor. We are telling you what is true, and then telling you what is not.

2. What the codebase actually enforces

Each of these is a property of the shipped site, not an ambition. You can check every one of them yourself.

• A skip link is the first focusable element on every page. Press Tab on any page of this site, before touching anything else, and the first thing you will focus is a link that jumps you straight to the main content, past the header.
• Focus rings are never removed without a designed replacement. A rule in our lint pass (C11) fails the build if any stylesheet suppresses the focus outline without supplying a :focus-visible style in its place. Keyboard users can always see where they are. This is enforced mechanically because it is the single most common way a beautiful site becomes an unusable one.
• Every tap target is at least 44 by 44 pixels. That is the size at which a person with a tremor, or a person holding a baby with one arm, can reliably hit a button. WCAG 2.2 asks for 24 pixels at Level AA. We use 44.
• Every text input is at least 16 pixels. Below that, iOS Safari zooms the viewport when the field takes focus, throwing the layout sideways under the user. It is a small thing that makes a form feel hostile, and it is entirely avoidable.
• No meaning is carried by colour alone. The verdict of a screening is a word — RECALL MATCHED, POSSIBLE MATCH, or NO MATCH FOUND — set in type, and readable in a grayscale screenshot, by a colourblind reader, and by a screen reader. It is not a red dot. The palette holds seven colours and not one of them signifies a clean result, so a verdict has no colour it could be rendered in even if we wanted one.
• Nothing rotates, auto-plays, or moves on its own. There are no rotating panels, no animated banners, no autoplaying video, no content that changes under you while you read it. Motion respects prefers-reduced-motion.
• There are no modal traps. No dialog appears uninvited, no newsletter box interrupts you, and nothing on this site can capture your focus and refuse to give it back. You have already noticed that no dialog asked you about cookies.
• Tables are real tables. A screen reader announces the row and column headers of every data table on this site, because they are marked up as headers rather than styled to look like them.
• The core screening works without JavaScript. Type a brand and a model number, submit the form, and you get a result page, served from the server, with scripting disabled entirely. The screening is the product, and the product does not depend on a client-side framework loading successfully on your device.

3. How we test

Keyboard-only navigation on every screen in the primary flow. Screen-reader passes with VoiceOver on macOS and iOS. Automated axe checks in continuous integration. Contrast checked against the token palette rather than sampled by eye, because eyes are optimistic.

Automated testing catches perhaps a third of real accessibility defects. We know that. It is why the section below exists and why the contact address at the bottom of this page is not decorative.

4. Known limitations

Two places where this site is harder to use than it should be. Both are real.

• The camera capture flow requires a device camera. Photographing a tracking label is inherently a visual, physical task, and for some people it will be difficult or impossible. It is not the only route: every screening can be run by typing the brand and model number instead, and that path produces exactly the same result and exactly the same certificate. But if you cannot read the label in order to type it in either, we do not have an answer for you yet, and we are not going to dress that up.
• The certificate verification detail is dense. The page that explains how a signature is checked contains long hexadecimal strings, a hash, and a cryptographic explanation. It is correct, it is marked up properly, and it is still hard going — visually, cognitively, and read aloud. The verdict and the date at the top are the part that matters, and they are stated plainly. The proof underneath is for the sceptic. We are working on a plain-language summary of it.

5. Third-party content

Where we link out to a recall notice on a government website, that page is not ours and we do not control its accessibility. We link to the primary source anyway, because the alternative is asking you to take our word for it.

6. Tell us when we get it wrong

Write to support@shelfstamp.com with the word accessibility in the subject line. Tell us the page, what you were trying to do, and what happened. If you use assistive technology, telling us which one helps enormously.

We will reply within 5 business days, and the reply will come from a person who has read what you sent, not from a ticketing system. If a fix is going to take longer than that, the reply will say so and give you a date.

If you cannot use the screening tool, that is a defect in our software. Not a limitation of yours, not an edge case, and not a feature request. A parent trying to find out whether a secondhand crib has been recalled should be able to find out. If our site is what stopped you, we have failed at the one thing this site exists to do, and we want to know.