Public working standard

A website should be clear, usable, fast, responsible, and maintainable.

The Spondra Website Standard describes how those qualities are considered, tested, and handed off. It is a working baseline—not a certification or a guarantee of business outcomes.

01

Accessibility is part of the layout

The core experience should remain understandable and operable without a mouse, animation, transparency, or a wide screen.

  • Semantic landmarks and a logical heading order
  • Complete keyboard access and visible focus
  • Readable reflow at narrow widths and 200% zoom
  • Reduced-motion and reduced-transparency fallbacks
02

Performance has a budget

Speed is treated as interaction quality. Visual effects are kept only when they improve hierarchy without making the page fragile.

  • Server-rendered core content
  • Reserved image dimensions and stable typography
  • Limited client JavaScript and delayed third-party features
  • Automated Lighthouse budgets plus browser review
03

Content has to earn its place

Every sentence should help a visitor understand, decide, or act. Vague promotional language and unsupported claims do not belong in the public experience.

  • Customer-facing language and descriptive links
  • No fabricated proof, guarantees, or artificial urgency
  • Clear labels for Spondra-owned demonstrations
  • A direct path to a person and a practical next step
04

Search follows clarity

Search visibility starts with useful pages that say clearly what Spondra does, who it helps, and how the work begins.

  • Unique titles, descriptions, and canonical URLs
  • Crawlable service definitions and accurate structured data
  • Maintained sitemap, robots rules, redirects, and internal links
  • Original guidance written for a real decision
05

Security and privacy are defaults

The smallest responsible data footprint is the default. Security controls are tested against the real site instead of treated as a checklist alone.

  • Server-side input validation and generic public errors
  • Strict response headers and a practical content security policy
  • No production secrets in public configuration
  • No data collection or third-party tracking without an approved purpose
06

AI needs a boundary

AI may prepare, organize, retrieve, or suggest. People remain accountable for the decisions and promises that matter.

  • A defined role for AI in the workflow
  • Visible sources, limits, and uncertainty where relevant
  • A named human checkpoint for consequential or customer-facing work
  • No implied autonomy beyond what has been built and tested
07

Handoff is part of delivery

A finished interface is not a finished engagement. The people responsible for the result should understand what exists, what it touches, and what happens next.

  • Scope, dependencies, and review points made visible
  • A tested handoff and understandable documentation
  • Ongoing costs and ownership discussed before launch
  • Maintenance based on evidence instead of expansion by default

Release gates for this site

A passing build is the beginning of verification.

The production candidate is checked in a preview environment, reviewed across screen sizes and interaction states, and then checked again on the live domain.

  1. 01

    Lint and TypeScript

  2. 02

    Production build

  3. 03

    Browser interaction tests

  4. 04

    Automated accessibility checks

  5. 05

    Broken-link and crawl checks

  6. 06

    Content policy checks

  7. 07

    Lighthouse performance budgets

  8. 08

    Preview review before production

Apply the standard to a real need

Good technology fits the work and the people responsible for it.

Bring Spondra the idea, existing site, repeated task, or uncertain AI use case. We will help identify the smallest useful path.

Tell us what you need