Accessibility Statement

1. The standard we build to

WCAG 2.1 Level AA. That is the benchmark the ADA Title II rule adopts. Section 508 is a version behind it — the Revised 508 Standards incorporate WCAG 2.0 Level A and AA — but 2.1 adds to 2.0 without changing any of it, so anything built to 2.1 AA clears the 508 baseline as well. We treat it as the working target for the marketing site, the subcontractor upload portal, and the signed-in application.

No automated tool can establish conformance — the industry estimate is that automated checks catch roughly a third of WCAG issues, and manual review is what finds the rest. So the honest formulation is the one above: this is what we build to and test against.

2. What is checked automatically, on every change

An axe accessibility scan runs in continuous integration against 14 URLs: the homepage, the pricing page, the data processing addendum, the product overview, the demo and certificate reader, the FAQ, the resource hub, the comparison index, the guides index, the help center, a subcontractor upload page, the dashboard, the subcontractor list and the review queue. It scans the whole page, including the navigation, the header and any open dialog — not just the main content region.

No rules are excused. That is worth saying because for a period two were: color contrast and accessible button names were tracked as a backlog rather than enforced. Both were driven to zero and the exemptions removed, so either one reappearing now fails the build rather than being logged.

Separately, a build-time check rejects any text below 15px on the marketing site — including sizes expressed in rem, em or an inline style, which an earlier version of the same check could not see. That floor covers the marketing pages and the upload portal. The signed-in application deliberately uses smaller type in dense chrome such as table metadata, and is not covered by it.

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.

The automated half runs on every change and is described in section 2. The manual half is keyboard-first: a screen is built by tabbing through it before it is called finished — because the failures that matter most here are the ones a scanner structurally cannot see. A control that is reachable but unlabeled, a focus order that jumps around a form, a dialog that traps you: each of those passes an automated check and stops a person cold.

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.

It is built for current versions of Chrome, Edge, Firefox and Safari, on desktop and phone, and it is tested there. It is not tested against a specific screen reader or a specific screen-reader-plus-browser pairing, so we cannot tell you it is known to work with JAWS, NVDA or VoiceOver — only that it is built on the standards those tools read. That is a real limitation and it belongs in this section rather than buried.

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 14 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 values we extract from it are presented as real text, which is the part we can control.

Where something is inaccessible, there is another way to get it done. 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 for you and the export does not solve it, write to us: we will get the information to you another way while the screen is being fixed, and that is an ordinary request rather than a favor.

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.

We read every report and answer it — we will tell you what we can fix and when. If something cannot be fixed quickly we will say so and offer another way to get it done, rather than leaving you waiting on a fix with no date.

If that response does not resolve it — or you do not get one — say so in a reply and it goes to the person who can make the call. There is no separate complaints process and no form: this is a small operation, and adding a queue between you and a decision would make it slower, not fairer.

This page is reviewed whenever the accessibility work changes and at least once a year, and the date at the top moves when it does. Where a limitation above is fixed, it comes off this page rather than being quietly left to look like an ongoing gap. 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.