Accessibility Statement
Last updated
This statement covers scrapmetalpickup.com. It sets out what we have verified, what we have not, and the problems we already know about. We would rather list a known failing than let you find it yourself.
1.Conformance status
We aim to meet WCAG 2.1 Level AA.
Status: partially conformant. Partially conformant means most of the standard is met, but some parts are not, or have not yet been verified. The specifics are in Known problems below rather than left for you to discover.
We have deliberately not claimed full conformance. No independent audit has taken place, and an unaudited claim of full conformance would mislead the people who most need the information to be accurate.
2.What has been verified
Colour contrast, mechanically. Every colour pair the interface actually renders is measured against WCAG 2.1 AA by an automated check that reads the design tokens directly, so it cannot drift from the code. It covers 24 pairs across both light and dark themes, and it fails the build if any drops below threshold — 4.5:1 for text, 3:1 for interface boundaries.
That check has already caught three real failures during development: the primary call-to-action orange at 3.56:1, the verified badge at 3.77:1, and the star rating at 2.15:1. All three were corrected rather than waived.
3.What has been built to the guideline
These were implemented deliberately and reviewed by hand, but have not been through formal testing — so they are listed as built, not as proven:
- A skip to content link as the first item in the tab order on every page.
- Semantic landmarks — header, nav, main, footer — one
h1per page, and no skipped heading levels. - A visible focus ring on every interactive element. Focus outlines are never removed.
- Touch targets of at least 44×44 pixels on controls, with spacing between them.
- Visible labels on every form field. Placeholder text is never used as a label.
- Errors placed next to the field that caused them, announced with
role="alert", and marked with an icon as well as colour so they do not rely on colour alone. - Star ratings carry a text equivalent — "Rated 4.7 out of 5 from 128 reviews" — rather than conveying the value only as shapes.
- Multi-step forms move focus to the new step heading and announce progress through a live region.
prefers-reduced-motionis honoured: every animation and transition collapses when the system setting is on.- Icon-only buttons have accessible names, and decorative icons are hidden from assistive technology.
- The layout reflows to 320px without horizontal scrolling, and zoom is never disabled.
4.Known problems
These are the accessibility issues we currently know about. If you hit something not on this list, please tell us — see Reporting a problem.
- No assistive technology testing has been done. The site has not been walked through with a screen reader, voice control, or a switch device. Markup was written to the guideline, but written-to-standard and works-in-practice are different claims and we are only making the first one.
- No independent audit. All review so far has been internal.
- The sign-in area of the header is briefly empty on first paint. It resolves in the browser rather than on the server, so for one frame there is nothing there. The space is reserved so nothing moves, and a signed-in visitor is never shown a "Sign in" button — but a screen reader reaching the header very early may not announce the control. This is a deliberate trade to keep the directory pages statically rendered; the fix is Partial Prerendering.
- Maps on listing pages are a placeholder. They currently render as a labelled region with a text description of the address. When a real map is embedded it will need its own accessibility work, and the address will remain available as text regardless.
- Third-party sign-in screens. The sign-in and sign-up forms are rendered by our authentication provider. We do not control their markup, and have not independently verified their conformance.
- Photos submitted by contributors. The submission form does not yet ask for alternative text, so user-supplied images may lack a useful description. Adding that field is the fix and it is planned.
5.How we assessed this
Self-assessment, carried out by the team building the site. Methods used:
- Automated colour-contrast measurement against the design tokens, run on every build.
- Manual keyboard traversal of the main flows.
- Code review against the WCAG 2.1 AA success criteria.
- Static analysis for common markup problems.
Not yet used: screen reader testing, voice control testing, testing with disabled users, and independent audit. Those are the gap between "partially" and "fully" conformant.
6.Reporting a problem
If any part of this site is difficult or impossible for you to use, we want to hear about it — including things not listed above. It is the fastest way for us to find what internal review missed.
Use the contact form and mention accessibility. Telling us the page, what you were trying to do, and what you use to browse helps us reproduce it, but do not let a missing detail stop you from writing.
Our commitment: we acknowledge accessibility reports within five business days and will tell you what we intend to do and when. If something blocks you from completing a task, we will offer another way to get it done in the meantime.
If a form on this site is the barrier, that is obviously a problem — in that case anything you can use to reach us is fine, and the contact page lists the alternatives.
7.Ongoing work
Accessibility is treated as part of the definition of done rather than a later pass. The contrast check runs in the build, and the design system records the accessibility floor every component is expected to meet.
Next, in order:
- A screen reader pass over the search, submit and listing flows.
- An alternative-text field on photo uploads.
- An independent audit before public launch.
This statement will be updated as those complete, and the date at the top will change with it.
