This entire product site is authored, validated, and rendered with Sights.See how it works
Menu

Quality gates

The reusable system should absorb the hard lessons once.

Sights makes responsive behavior, semantic markup, accessibility, browser compatibility, capability boundaries, and static output part of the component and consumer contract—not optional cleanup after a page looks finished.

See how builds are delivered
A Sights quality dashboard showing checks for the content graph, accessibility, browsers, output, foundations, and production builds

Release policy

Quality has named targets and visible limits.

A generic promise to be responsive or accessible is not a gate. Sights specifies what runs automatically and what still needs editorial or real-device judgment.

Accessibility target
AA
WCAG 2.2 AA guides the system; automated checks do not replace manual and editorial review.
Browser engines
3
Chrome, Firefox, and WebKit run the same component and consumer behavior tests.
Zoom and reflow
200%
Representative routes must remain readable and free of page-level horizontal overflow.
Silent invalid sections
0
Validation stops unknown names and props before a renderer could skip them.

One complete check

Different failures belong at different layers.

The fastest feedback runs first. Broader build and browser checks then verify the behavior that schemas and types cannot see.

  • Schema validation

    Reject invalid page shapes, component props, themes, collections, templates, images, links, anchors, and metadata before rendering.

  • Type checking

    Verify trusted TypeScript and Astro implementation code, including site-owned component schemas and renderers.

  • Foundation audit

    Reject drifting literal typography and routine spacing in shared or site-owned CSS unless a narrow documented exception applies.

  • Production build audit

    Inspect generated routes, scripts, metadata, internal page boundaries, anchors, redirects, images, and capability isolation.

  • Accessibility scan

    Run axe for serious and critical violations while separate checks cover semantics, keyboard focus, disclosures, and target behavior.

  • Cross-browser behavior

    Exercise representative phone and desktop layouts plus interactive states in Chrome, Firefox, and WebKit.

Interaction contract

Progressive enhancement must keep the document intact.

  1. Render useful content first

    The server output contains the complete information and native semantics before a browser runtime loads.

  2. Declare the enhancement

    A component or shell states which shared or custom runtime it needs and why.

  3. Load it once

    The build deduplicates shared behavior and keeps custom modules isolated to the routes that use them.

  4. Preserve native controls

    Use links, buttons, details, summaries, forms, tables, landmarks, and ordered lists for the jobs they already do well.

  5. Respect user settings

    Reduced-motion preferences disable nonessential motion while content remains visible and navigable.

  6. Test the failure mode

    No-JavaScript and narrow-layout checks prove that enhancement is not a hidden dependency.

Honest quality claims

What the automated gate does not certify.

Does a passing axe scan make a site accessible?

No. Automated checks catch important classes of failures. Alt-text quality, reading clarity, cognitive load, content order, and many assistive-technology experiences still require editorial and manual review.

Does browser automation replace real-device testing?

No. It provides repeatable engine and viewport coverage. Stable releases still need a documented smoke test on representative touch devices and actual Safari environments.

Can page authors bypass a failing contract to ship faster?

Not through declarative content. A genuine new requirement becomes a named semantic variant or a trusted custom component with its own documented contract.

What protects performance?

Static rendering, local dimensioned assets, declared runtimes, route-scoped custom modules, deduplicated shared behavior, and a generated output audit make unexpected client code visible.

Unique needs, same standard

Custom capabilities should join the quality system, not route around it.

See how site-owned components keep strict props, examples, generated docs, review routes, and isolated runtimes while supplying genuinely custom behavior.

Explore extensibility