Skip to content
zHezarFoundation / Public release

Accessibility / current approach

Access belongs in the build.

The public release is designed to remain understandable, navigable, and usable across input methods and narrow screens. That is current engineering evidence—not a claim of complete conformance.

Current scope / July 2026

Public routes reviewed

Evidence covers this release—not every future experience.

The current public pages are reviewed for responsive structure, keyboard behavior, target size, reduced motion, and browser errors. Account providers, commerce, uploads, voting, ownership, NFC, and protected support are not active.

Built into the shared foundation

Four ways the interface must keep working.

These are release requirements applied across the shared shell, not optional treatments added to one page.

  1. 01

    Navigate

    A skip link, visible keyboard focus, logical landmarks, and keyboard-operated mobile navigation are part of the shared shell.

  2. 02

    Read

    Clear typography, restrained line lengths, semantic headings, and layouts that reflow protect the reading experience.

  3. 03

    Act

    Enabled links and controls meet the current 44 CSS px target and do not depend on hover, color, or fine pointer movement.

  4. 04

    Pause

    Reduced-motion preferences remove smooth scrolling and compress transitions without removing content or meaning.

Equal path

An alternative must preserve the same opportunity.

Future accommodations cannot reduce eligibility, rights, deadlines, vote weight, allocation treatment, price, privacy, security, Claim authority, or appeal access. A separate path is useful only when it remains equivalent.

Not yet proven

A polished route is not an accessibility audit.

No formal standard, perfect-access claim, universal device promise, or active accommodation process is represented.

  • 01

    A formal conformance target and independent accessibility audit

  • 02

    A published browser, device, and assistive-technology support matrix

  • 03

    Staffed accessibility intake, response, escalation, and accommodation operations

  • 04

    Equivalent routes for future timed, provider, payment, scan-tag, and media workflows

When a barrier appears

Describe the task, not a diagnosis.

A useful first note can name the page, intended action, what happened, and optional browser or assistive-technology context. Medical records, proof of disability, credentials, and private evidence are not needed in ordinary correspondence.

No accessibility request, accommodation, case, response target, or escalation is created by this page.