Accessibility and Inspectable Evidence

Accessibility commitment

Consequential evidence should remain inspectable across interaction modes

Evulgare treats accessibility as part of technical answerability. An evidence record is not meaningfully public or reviewable when its structure, controls, or consequential meaning can be reached only through one visual, motor, or sensory mode.

Public interfaces target WCAG 2.2 Level AA. This is an engineering target, not a certification or a claim that every current route fully conforms. Advanced simulations and dense assurance workbenches require continued manual review, assistive-technology testing, and alternative-representation work.

Keyboard operation

Public interactions should work without pointer precision

The repository uses native links, buttons, form controls, disclosure elements, and tab patterns where applicable. Custom interactions require explicit keyboard behavior and visible state.

01

Navigation

A skip link moves to main content. Primary and footer links follow document order. Mobile navigation exposes a labeled toggle with an expanded state.

02

Visible focus

Interactive elements receive a visible focus indicator. Focus treatment is designed to remain visible on light, dark, high-contrast, and forced-color surfaces.

03

Disclosure controls

Expandable regions use controls that expose their state. Collapsed content should not remain an invisible keyboard destination.

04

Logical order

Focus order should follow the reading and task sequence rather than visual placement alone. Sticky panels must not cover focused controls.

05

No keyboard traps

Public interfaces should allow movement into and out of controls, dialogs, rails, and workbench regions using ordinary keyboard commands.

06

Shortcut boundaries

Simulation shortcuts are modifier-based or locally disableable so unmodified character keys do not silently override speech or assistive-technology input.

Semantic structure

Meaning should be available in the document, not only in the visual layout

Public pages use one primary heading, logical section headings, landmarks, lists, links with meaningful text, labeled form controls, and native tables for genuinely tabular information. Breadcrumbs are exposed as navigation with an ordered list.

Native HTML is preferred where it provides the needed behavior. ARIA is used to name landmarks, expose state, connect controls and panels, or supplement a custom pattern where native elements alone are insufficient. ARIA does not repair missing keyboard behavior or incorrect document order.

Heading hierarchy: TARGETEDPages use one H1 and ordered H2/H3 sections that reflect content structure.
Landmarks: IMPLEMENTEDHeader, primary navigation, main content, contextual navigation, and footer regions are present in shared templates.
Forms: IMPLEMENTEDThe public contact form uses explicit labels, validation messages, and native fields.
Tables: BOUNDEDTables are used for comparisons and inventories, with headings and scrollable containers at narrow widths.
ARIA: SUPPLEMENTALARIA names and states custom regions but is not treated as a substitute for native semantics.

Visual accessibility

Readable text, strong contrast, and bounded density

The shared design system uses explicit foreground and background ownership so text does not disappear through accidental theme inheritance. Text size, line height, reading width, section spacing, and card density are constrained to avoid oversized display type and large empty fields replacing information hierarchy.

Controls target at least 44 pixels in the relevant interactive surfaces. Color is not intended to be the only indicator of status: labels, symbols, text, and structural placement accompany status colors. Layouts are designed to reflow at narrow widths and increased zoom without forcing page-level horizontal scrolling.

Visual review targets

Normal text contrast of at least 4.5:1 and large text contrast of at least 3:1
Meaningful control boundaries and state indicators distinguishable at 3:1 where applicable
Readable line lengths and text that scales without clipping or overlap
200% zoom and 400% reflow review for representative public routes
Forced-color and increased-contrast behavior that preserves control identity
No meaning communicated through color alone

Motion and time

Nonessential motion should yield to user preference

The stylesheet includes reduced-motion handling, and interactive systems are expected to avoid requiring animation to understand a result. Automated camera motion, transitions, pulsing indicators, and decorative effects should stop or simplify when reduced motion is requested.

Where a simulation uses time as part of the evidence, the interface should provide explicit pause, playback, event navigation, or textual sequence controls. Reduced graphics cadence must not erase the underlying event state.

Graphs and technical visualizations

Consequential graphical information needs another representation

Evulgare workbenches often express relationships, sequences, uncertainty, and proof state visually. The design target is not a decorative alt label; it is an inspectable representation of the consequential information.

Structured text

Names the selected scenario, entities, authority, state, result, limitation, and current evidence in a reading order.

Tables

Expose rows, columns, labeled values, comparisons, and statuses for reviewers who need direct data access.

Narrative

Explains the event sequence and why a transition occurred without replacing the underlying evidence.

Ordered sequences

Represent timeline and causal order using event lists, step controls, or append-oriented logs.

Labeled metrics

Pair values with names, units, scope, and status rather than relying on position, shape, or color.

Raw evidence

Provides bounded machine-readable records where exposure is safe and useful, with the same truth boundary as the visual view.

Known limitation: advanced 3D scenes, dense relationship graphs, and synchronized workbenches may not yet expose every spatial or relational nuance equally through every assistive technology. Alternative views reduce that gap but do not justify a claim of complete equivalence.

Media and progressive enhancement

Core truth should not disappear when a richer layer is unavailable

Meaningful recorded media should provide captions and, where content warrants it, a transcript or description. Autoplay should not be required to obtain the information. Decorative media should be identified as decorative rather than burdening assistive output.

Repository-owned Institutional pages and many public information routes remain readable without JavaScript. Interactive simulations necessarily lose some behavior when scripting is unavailable, but their pages should retain a no-JavaScript explanation of purpose, scope, evidence boundary, and available non-graphical information.

Progressive-enhancement target

Page title, direct answer, limitations, and primary links remain in server-rendered HTML.
Native navigation and contact information do not depend on client-side rendering.
Interactive controls expose a clear disabled or unavailable state when their runtime cannot start.
No-JavaScript content does not claim that an unexecuted simulation has run.

Assessment approach

Multiple checks, with manual acceptance still required

Repository release work includes semantic source inspection, keyboard review, pointer hit testing, contrast measurement, responsive viewport checks, zoom and reflow checks, reduced-motion and forced-color checks, browser-console review, and automated tests for selected routes and components.

Automated tooling can find missing names, contrast failures, overflow, unreachable controls, or invalid structure. It cannot establish whether a task is understandable, whether a screen-reader experience is coherent, whether a complex graph communicates equivalent meaning, or whether disabled and error states are usable. Manual review and qualified assistive-technology acceptance remain necessary.

Keyboard review: PERFORMED ON SELECTED ROUTESRepresentative public workbenches and page controls have browser-based keyboard checks.
Responsive and zoom review: PERFORMED ON SELECTED ROUTESRelease evidence includes mobile, desktop, 200%, and 400% representative cases.
Contrast and theme review: PERFORMED ON SELECTED ROUTESLight, dark, forced-color, and increased-contrast states are checked for representative content.
Screen-reader assessment: INCOMPLETENo blanket qualified assistive-technology acceptance is claimed for the full site.
Certification: NOT ESTABLISHEDNo third-party accessibility certification is claimed.

Report a barrier

Describe the task that became unavailable

Use the public contact form and select “Accessibility barriers.” Include the page or feature, the task you were attempting, the browser and assistive technology if relevant, the observed barrier, and the result you expected.

Do not include unnecessary medical information, account credentials, protected data, or sensitive personal details. The public form does not establish a response-time guarantee or a confidential channel.

Report an accessibility barrier Open contact routing

Evidence and change history

Inspect the claims behind Accessibility

Review claim class, support status, source identity, observation environment, scope, limitations, known defeaters, and append-oriented change events. The ledger does not convert a repository statement or target into deployment, certification, compliance, or external validation.

Open Accessibility evidence