Methodology
ShipSafe is a transparent tool. Here is every check it runs, the specific WCAG success criterion each maps to, why that criterion matters for demand-letter risk, and what the tool genuinely cannot see.
What ShipSafe is — and isn't. It reads your page's HTML source and runs heuristic checks against WCAG 2.2 and common privacy rules. It flags real, documented risk patterns. It is not legal advice, not a certified WCAG conformance audit, and not a guarantee of compliance. Treat a clean result as "no obvious red flags in the source," not "certified accessible."
Accessibility checks (ADA / WCAG)
These eight checks map to the Web Content Accessibility Guidelines (WCAG) 2.2 — the technical standard U.S. courts apply when evaluating ADA website claims. They are weighted highest in the overall score because they are the issues automated ADA filers scan for directly.
| Check | WCAG criterion | Why it matters for legal risk |
|---|---|---|
| Page language declared |
3.1.1 Language of Page Level A |
Screen readers (JAWS, NVDA, VoiceOver) pick a pronunciation engine based on the lang attribute on the <html> element. Without it, an English page may be read with a French or Spanish voice — making it effectively unintelligible. WCAG 3.1.1 is a Level A requirement, the floor for ADA compliance. Its absence is a quick, defensible strike in a demand letter because it requires a single attribute to fix. |
| Images have alt text |
1.1.1 Non-text Content Level A |
WCAG 1.1.1 requires every meaningful image to have a text alternative. It is the single most-cited issue in ADA demand letters — often the sole basis for a filing. A missing alt attribute is machine-detectable in seconds, which is why serial filers automate it. Decorative images should carry alt="" to explicitly mark them as presentational; ShipSafe flags any <img> with no alt attribute at all. |
| Form fields are labeled |
1.3.1 Info and Relationships 4.1.2 Name, Role, Value Level A |
A form input without a programmatic label is unusable by screen readers: the user hears "edit text" with no indication of what to type. Placeholder text does not satisfy this requirement — it disappears on focus and is frequently skipped by assistive technology. ShipSafe checks for a <label for> pointing to the field, an aria-label, an aria-labelledby, or a title attribute. It flags fields that have none of these. |
| Links & buttons have names |
4.1.2 Name, Role, Value Level A |
WCAG 4.1.2 requires every interactive control to have a name that assistive technology can announce. Icon-only buttons — a close icon with no text, an arrow link with no label — are dead ends for screen-reader users: they hear "button" or "link" with nothing else. ShipSafe checks accessible name computation: visible text, aria-label, aria-labelledby, image alt text, or an SVG <title>. If none is found, it flags the control. |
| Page has a title |
2.4.2 Page Titled Level A |
The <title> element is announced first when a screen reader loads the page and shown in the browser tab and bookmark. WCAG 2.4.2 requires pages to have descriptive titles — "Untitled" or a missing title leaves users without orientation. It also hurts search visibility, so fixing it serves both accessibility and SEO. |
| Heading structure |
1.3.1 Info and Relationships Level A |
Screen-reader users navigate pages primarily by headings — they jump from <h1> to <h2> to <h3> to build a mental outline of the page. WCAG 1.3.1 requires that structure conveyed visually be present in the programmatic structure too. ShipSafe checks that exactly one <h1> exists. Multiple <h1> elements (a common AI-builder output) break that outline; zero means there is no navigational anchor at all. |
| Mobile viewport |
1.4.10 Reflow Level AA |
WCAG 1.4.10 requires content to reflow to a single column at 320px without requiring horizontal scrolling. Without a viewport meta tag, browsers render the page at desktop width on mobile and users must scroll horizontally — making the site practically unusable on a phone. Low-vision users who zoom heavily are particularly affected. The fix is one meta tag. |
| Main landmark |
1.3.1 Info and Relationships Level A |
A <main> element (or role="main") is an ARIA landmark that lets screen-reader users skip directly to the primary content, bypassing repeated navigation. Without it, keyboard and screen-reader users must tab through every nav link on every page load. It is a one-element fix, and its absence in an otherwise simple page is difficult to justify in a legal context. |
Privacy & legal checks
Privacy claims are frequently filed alongside accessibility complaints — they share the same plaintiff's bar and the same demand-letter economics. These checks are also weighted high in the score.
| Check | Standard / law | Why it matters |
|---|---|---|
| Privacy policy linked | CCPA / GDPR | California's CCPA and the EU's GDPR both require a privacy policy if you collect personal data — and "personal data" includes IP addresses and analytics identifiers, not just form submissions. ShipSafe checks for a link whose text or URL contains "privacy." Its absence is a recurring item in demand letters, particularly when bundled with accessibility claims. |
| Cookie / consent notice | GDPR / ePrivacy Directive | Loading tracking scripts (Google Analytics, Meta Pixel, Hotjar, Clarity, Mixpanel, Segment) before a user consents is a direct GDPR violation for EU visitors and a CCPA exposure for California users. ShipSafe checks the source HTML for known tracker signatures and for the presence of a consent management platform or cookie-acceptance banner. If it finds trackers without a consent mechanism, it flags the combination as a fail. |
| Terms of service linked | General legal best practice | A Terms of Service link is expected wherever users can register, purchase, or submit content. Its absence is a warn rather than a fail — many simple informational sites have no need for one — but it is a gap worth noting for any site with interactive features. |
| Contact path | General legal / accessibility best practice | A reachable contact path — a mailto: link or a page linked as "contact" — matters for both accessibility and legal purposes. Accessibility statements and legal processes require a way for users to report problems. Several state laws and WCAG supplementary guidance specifically encourage providing contact information for accessibility feedback. Its absence is a warn. |
| Accessibility statement | WCAG 2 supplementary / ADA best practice | An accessibility statement (a page or section documenting your commitment, known limitations, and a contact for reporting issues) is not a WCAG success criterion, but it is a documented factor in reducing demand-letter risk. Courts and plaintiffs' attorneys look for evidence of good-faith effort. A statement signals awareness and ongoing commitment; its absence signals the opposite. ShipSafe checks for a link whose text or URL contains "accessib." |
Schema & SEO checks
These checks carry lower legal risk weight, but they are cheap wins — most are single-line fixes with direct visibility impact.
| Check | Standard | What ShipSafe looks for |
|---|---|---|
| Structured data (schema.org) | SEO / Google Rich Results | ShipSafe looks for <script type="application/ld+json"> blocks and attempts to parse each as JSON. A missing block is a warn — Google cannot show rich results without structured data. A block that fails JSON.parse is a fail — it is silently ignored by search engines, so it provides no benefit while looking like it does. |
| Meta description | SEO | A <meta name="description"> content attribute with at least some text. It doesn't affect ranking directly but is your pitch in the search results snippet. Missing it means Google writes one for you, which is usually worse. |
| Open Graph tags | SEO / Social sharing | ShipSafe checks for og:title and og:image. Without them, shared links on LinkedIn, Slack, iMessage, and most social platforms show a blank card — a trust signal problem, especially for a business site. |
| Canonical URL | SEO | A <link rel="canonical"> tells search engines which version of a URL is authoritative. Its absence is informational on a single-page site — not a problem — but worth noting for sites with URL parameters or multiple paths. |
Trust signal checks
These are baseline checks that affect whether a site looks legitimate to browsers and users.
| Check | Standard | What ShipSafe looks for |
|---|---|---|
| HTTPS | Security / browser policy | Checks whether the scanned URL uses the https: protocol. HTTP sites are marked "Not secure" by all major browsers — a visible warning that undermines trust, and a hard barrier to some browser features. Every major hosting platform provides free TLS certificates. |
| Favicon | Browser UI convention | A <link rel="icon"> (or shortcut icon) declaration. Its absence is informational — browsers will show a fallback — but a missing favicon is a detail that reads as unfinished, particularly to business users who pin tabs. |
| No mixed content | Security / browser policy | On an HTTPS page, any resource loaded over http:// — an image, script, or stylesheet — is "mixed content." Modern browsers block active mixed content (scripts, iframes) silently and warn on passive mixed content (images). ShipSafe scans src and href attributes in the source HTML for insecure http:// references. |
How the score is calculated
Each check returns one of four statuses:
Pass
1.0
Requirement is met.
Warn
0.5
Partially met or a best-practice gap with no direct legal exposure.
Fail
0.0
Requirement is not met. Legal or UX risk.
Info / N/A
—
Not applicable or informational. Excluded from scoring.
A category score is the mean of its applicable checks, multiplied by 100. Health is the mean of the four category scores. The letter grade maps as: A ≥ 90, B ≥ 80, C ≥ 70, D ≥ 55, F below that.
Demand-letter risk is determined by the two legal categories (Accessibility + Privacy), not the overall health:
- High risk — three or more legal-category fails, or Accessibility score below 50, or Privacy score below 40.
- Some risk — at least one legal-category fail, or Accessibility score below 85.
- Low risk — no legal fails and Accessibility score at 85 or above.
Honest limitations
The free ShipSafe check reads the static HTML your server returns. That imposes real constraints:
- Color contrast is not checked. WCAG 1.4.3 (minimum contrast, Level AA) and 1.4.6 (enhanced contrast, Level AAA) require measuring rendered text against its background. That requires a live rendering environment, not source HTML. Contrast is one of the more common real-world accessibility failures and ShipSafe does not currently catch it.
- JavaScript-rendered content is invisible. If your site builds its DOM after page load — single-page app frameworks, React, Vue, Svelte — the source HTML may be nearly empty. ShipSafe will analyze what is in the source and flag issues there, but it cannot see the final rendered output. A rendered-DOM scan (using a headless browser) is in development as a planned Pro tier feature.
- Heuristic matching has false positives and negatives. ShipSafe detects a "privacy policy link" by matching link text or URL against a pattern. A site might have a privacy policy that passes heuristically but is legally inadequate, or might fail the check while having a real policy under an unusual label. The check is a signal, not a certification.
- One page only. ShipSafe scans the URL you provide. It does not crawl other pages on your site. The homepage scan is a representative sample — your blog posts, product pages, or contact forms may have different issues.
- Source-HTML accessibility differs from rendered-DOM accessibility. The
<main>element, labels, and ARIA roles ShipSafe looks for may differ from what a browser actually constructs if JavaScript moves or replaces elements. Automated testing on the rendered DOM (with tools like axe-core or Lighthouse) will surface issues a source scan cannot.
The right place for ShipSafe in a compliance workflow: use it as a fast first pass — a 10-second smoke test before you tackle accessibility properly. A clean result means no obvious red flags in your source. It does not mean certified compliant. If you need a binding determination, talk to a qualified accessibility professional.