Accessibility Statement

1. The standard we build to

We use WCAG 2.1 Level AA as the working target for the marketing site, subcontractor upload portal and signed-in application. This statement describes our current process and limitations; it is not a third-party accessibility certification.

Automated tools alone cannot determine whether a site conforms to accessibility standards. Knowledgeable human evaluation is also required, which is why the automated coverage below should be read as one part of the assessment rather than proof of conformance.

2. What is checked automatically

The push and pull-request workflow runs type checking, linting, the dependency audit, unit tests and the production builds. A separate workflow runs nightly and can also be started manually; that workflow runs integration, smoke and end-to-end suites when its required test environment is available.

The end-to-end suite includes an axe scan of 16 URLs: the homepage, the pricing page, the data processing addendum, the product overview, the demo and certificate reader, the FAQ, the resource hub, the Field notes index, a Field note article, the comparison index, the guides index, the help center, a subcontractor upload page, the dashboard, the subcontractor list and the review queue. It runs with the Chromium browser engine. Serious and critical axe findings fail that suite, and no rule identifiers are currently excluded from that serious/critical gate. Lower-impact findings are not part of that blocking assertion.

Separately, the push and pull-request build includes a source and prerendered-output check that rejects text below 15px on the marketing pages, including sizes expressed in rem, em or an inline style. That build-time check does not cover the upload portal or every signed-in screen.

Inside the signed-in application the floor applies on screens 767px wide and below — a phone, where the tables have already stacked and nothing is competing for the width. Above that the application does use smaller type in dense chrome such as table metadata, down to 12px, and that is a deliberate trade for the number of columns a compliance table can show at once. If you work at a desk and want the larger type anyway, your browser’s zoom applies to every screen here; nothing in the layout is pinned to a pixel width.

3. How this is assessed

Self-evaluation. Nobody outside Sealinn has audited this, and that is worth stating plainly rather than leaving to be inferred from the absence of a certificate. What follows is what we do, not what somebody else has verified about us.

Section 2 describes the automated part. We do not currently publish a comprehensive manual test cadence or a completed screen-by-screen keyboard and assistive-technology matrix. Keyboard order, focus behavior, labels and dialog behavior therefore still need human evaluation beyond what the scanner can establish.

What this deliberately does not claim: no screen-reader testing program, no testing with disabled users, and no formal audit against the WCAG 2.1 Level AA checklist screen by screen. Those are the three things that would let us say “conforms” instead of “builds to”, and until they exist the weaker word is the true one.

4. What it relies on, and where it works

Sealinn is a website. It relies on HTML, CSS, JavaScript, WAI-ARIA and SVG, and it depends on the browser and any assistive technology supporting those together — the standard combination, but worth naming, because “accessible” always means accessible with something.

Current automated browser coverage uses Playwright’s Chromium engine with desktop and Pixel 5 device profiles. It does not currently include automated Firefox or WebKit projects, branded Edge or Safari runs, or a specific screen-reader-plus-browser pairing. We therefore do not claim verified compatibility with JAWS, NVDA or VoiceOver.

Two things genuinely need JavaScript: the signed-in application, and the interactive product tour on the marketing site. Everything else — every legal page, every guide, the pricing table, the whole content library — is plain server-rendered HTML that works with scripting turned off entirely.

5. Decisions built into the design system

• Status is never carried by color alone. Every compliance state renders an icon and a word alongside the color, so a certificate that is expiring reads as expiring in grayscale.
• Controls have a visible keyboard focus ring, and it is part of the button component rather than something each screen remembers to add.
• Touch targets are sized for a phone on a jobsite: controls that only appear on hover are made permanently visible on touch devices, because there is no hover to reveal them with.
• Form errors are announced, not just colored — each field links its message and marks itself invalid for assistive technology.
• Motion respects the operating system’s reduced-motion preference, and the interactive product tour does not auto-play when it is set.

6. What is not covered yet

The automated scan covers 16 URLs. The application has considerably more screens than that, and several of the densest — the certificate review screen, the file grid, the settings forms — are not among them.

We have not commissioned an independent audit and do not publish a VPAT. Some content is inherently difficult: a certificate of insurance is a scanned document, and where the original is an image its text cannot be read by a screen reader. The review values your team records are presented as real text, which is the part we can control. Automated certificate reading is currently unavailable.

Exports provide another access route. Your subcontractor roster, the compliance reports and the full audit log all export as PDF, Excel or CSV, and the file ledger as Excel or CSV — a spreadsheet is navigable by tools a densely-packed screen may not be. If a screen is unusable and the export does not solve the barrier, use the address below and describe the information or action you need.

7. Tell us about a barrier

If something on this site or in the product is unusable for you, write to hello@sealinn.com and say what you were trying to do, which page, and what happened. A description in your own words is more useful than a WCAG reference — though if you have one, include it.

Say whether an export or another format would help while the barrier exists. Use the same address for a follow-up and include the original message where possible so the two can be matched.

There is no separate accessibility complaint form. The published email address is the route for the initial report and any follow-up.

We update this statement when a material accessibility practice or known limitation changes. The date at the top moves when the published statement changes. General questions go to hello@sealinn.com; how we handle personal data is on the privacy page, and how the platform is secured is on the security page.