Access is a design practice, not a badge.

The site is built around its content, with pre-rendered static HTML, meaningful page structure, restrained motion, and a clear visual hierarchy. Interactive features enhance a document that remains readable before they start.

Primary links, language switching, mobile navigation, filters, Consultation controls, FAQ questions, reset confirmations, and copy actions are intended to work by keyboard. Standard browser controls are preferred where they provide reliable interaction without custom scripting.

A skip link moves directly to main content. Visible focus rings are retained, Consultation errors link to the relevant fields, step changes move focus to the new heading, and modal-like confirmations return focus when dismissed.

The cinematic introduction is bypassed or simplified when reduced motion is requested. Editorial reveals become immediate, smooth scrolling is disabled, and Consultation state remains understandable without animated transitions.

English pages use the main address and Polish pages use /pl. Each static document has the correct lang attribute. Pages use one h1, ordered h2 and h3 headings, clear page regions, lists, definitions, and meaningful link labels.

Consultation uses standard single-choice fields, text inputs, email and telephone fields, a multi-line text field, and a checkbox, all with visible labels. Error summaries receive focus, invalid fields expose aria-invalid and descriptions, and entered values are retained when a correction is needed.

The abstract body maps are paired with synchronised single-choice lists, text descriptions, region and side labels, and a complete summary. The visual map is not the only way to choose or understand a placement plan.

The ink, paper, ivory, silver, and wine colours are used with visible boundaries and cues that do not rely on colour alone. Layouts are designed to adapt from a 320-pixel-wide screen to large displays and to remain readable at 200% zoom or an equivalent narrow width.

Development checks include code quality and type checks, production builds, content validation, keyboard paths, reduced-motion behaviour, reviews at different screen widths, focus behaviour, no-JavaScript alternatives, and console inspection. These checks reduce risk but do not replace an external accessibility audit.

Before a production launch, VEIL should commission testing with assistive-technology users, verify the physical venue, review final imagery and alt text, document a real support route, test browser and device combinations, and resolve findings through a published improvement cycle.