/ACCESSIBILITY
Designed to be navigable by anyone, in any access condition.
The K-Worldwide site adopts the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA as a design reference. Accessibility is a structural property of the code: semantic landmarks, heading hierarchy, keyboard support, handling of user preferences for motion and contrast, native multilingual.
/COMMITMENT
Not added at the end of the project: a structural property of the design and the code. The visual system, the semantic architecture and the interactive behaviors are designed so that those navigating with a screen reader, keyboard, voice command or high-contrast display receive the same content, the same flow, the same possibilities for action as those using a pointer and a standard screen.
/WCAG STANDARD
WCAG 2.1 is organized into four principles. They aren't design opinions: they're the technical pillars of web accessibility recognized internationally by the W3C.
Everything the site shows must be able to be perceived. Alternative text on images, sufficient contrast, captions on multimedia content, clear semantic structure.
Those navigating with a screen reader, Braille reader or high-contrast display must receive the same meaning as those who see.
The interface must work with any input method. Full keyboard, visible focus, links and buttons reachable without a mouse. No keyboard traps, no forced time limits.
Those navigating with a switch device, voice command or assistive keyboard must be able to complete every action.
The information and the operation of the interface must be clear. Readable language, predictable component behavior, explicit error messages.
No useless jargon, no surprises: the user always knows what's happening and what to do next.
The code must be interpretable by a wide range of user agents and assistive technologies. Semantic markup, ARIA attributes when needed, compatibility with screen readers and future parsers.
Accessibility isn't a visual trick: it's a structural property of the code.
Source: W3C Web Content Accessibility Guidelines (WCAG) 2.1 · w3.org/TR/WCAG21
/FROM PRINCIPLES TO ARCHITECTURE
The four WCAG principles translate into concrete code choices. Semantic markup, keyboard support, selective ARIA, measurable contrast, controlled motion: the technical translation of the protocol.
/LAYER · TECHNICAL ARCHITECTURE
The technical choices that run through every component of the site.
semantic markup
HTML5 tags with native roles (header, nav, main, article, section, footer). Heading hierarchy without skips. Lists, forms and tables marked with the appropriate tags. No generic div where a semantic element exists. The document declares the language at the root level (html lang) and adapts the declaration to the current locale.
keyboard support
Every interactive element is reachable from the tab flow and follows the logical order of the DOM. The skip link allows skipping navigation and going directly to the main content. No keyboard traps, no forced time limits.
selective ARIA
ARIA attributes used only where semantic HTML isn't enough — custom components, dynamic states, live regions. The first rule of ARIA is don't use ARIA: native elements are preferred whenever they exist. Decorative patterns (grids, constellations, topographies) are marked aria-hidden so as not to disturb assistive technologies.
measurable contrast
The system's dynamic palette adopts five semantic roles (background, primary text, secondary text, muted text, accent) that vary with the phase of day. The reference is the contrast ratio ≥ 4.5:1 for normal text and ≥ 3:1 for large text, per the WCAG AA threshold. Continuous calibration across the five adaptive phases.
controlled motion
Animations, transitions and glitch effects respect the prefers-reduced-motion media query. Those who disable operating-system animations receive a still experience — no parallax, no pulse, no animated page entrance. Windows forced-colors mode is natively supported. Motion is a user choice, not a system imposition.
/FEEDBACK CHANNEL
Accessible sites evolve through their users' reports. If you encounter a barrier, confusing behavior or a component that doesn't respond correctly to your assistive technology: your report is welcome. Every piece of feedback is taken on board.