renar v0.1.0
accessibility

A design constraint,
not a compliance page.

Renar's interface is plain, server-rendered HTML that leans on your browser's native semantics — which is the most assistive- technology-friendly substrate there is. This page states what is built and how it is tested; we do not claim a formal conformance audit we have not had.

01

In the product

the substrate does the work
Works without scripts

Browsing, editing, uploading, renaming, deleting, restoring from trash — every core flow is a native HTML form. The inline scripts only enhance: theme persistence, copy buttons, live refresh over SSE. Without them, everything still works.

Native controls only

Real buttons, real inputs, real selects — no widget library re-implementing keyboard behavior half as well as the platform. Focus order follows document order, which follows meaning.

The page says what it is

<html lang> stamped, landmark structure, tables with header rows, ARIA where semantics need help — filenames are bidi-isolated so a name in an RTL script cannot reorder your listing.

Themes that stay legible

Thirteen themes — nine dark, four light — applied before first paint, so there is no flash of the wrong contrast. High-contrast light and dark pairs among them; text resizes with your browser settings because the layout is text-first.

Names are bytes, honestly shown

A filename that is not valid UTF-8 displays as its escaped raw form with the bytes one click away — never silently mangled into a name it is not.

No motion traps

Live refresh is opt-in per page; nothing auto-scrolls, nothing animates on its own, and the terminal is the only surface that moves — because you asked it to.

02

On this site

the same rule, applied to ourselves
Keyboard-complete

A skip link is the first tab stop; the menu is a native <details> element; every interactive control is reachable and operable by keyboard, with a visible focus ring on the site's own accent wherever you land.

Contrast-checked, both themes

The dark and light palettes were built as token pairs and checked so body text, muted text, and controls clear WCAG AA contrast in both — the theme toggle is a preference, never a legibility gamble.

Reading mode is a switch, not a verdict

This site is designed to look like something, and that design uses motion and a decorative layer. Reading mode in the top bar turns all of it off: no animation, no gradients behind the type, higher contrast, underlined links, and a louder focus ring. It persists across pages, and it switches itself on if your OS already asks for prefers-reduced-motion. You decide — we do not decide on your behalf, in either direction.

Why a toggle rather than a floor. A page that designs for the strictest possible reading of every guideline up front usually ends up plain for everyone and still not actually tested with assistive technology. We would rather ship a site that is good to look at, keep the substrate honest underneath it — real headings, real landmarks, real buttons, keyboard order that follows meaning, alt text on every screenshot — and hand the reader one control that strips the decoration away completely. Both readings of the page are first-class; only one of them is the default.
Targets, stated as targets. We build to WCAG 2.2 AA as the design target and test with keyboard walks, contrast measurement, and reduced-motion passes. We have not commissioned a formal third-party conformance audit; when we do, this page will carry its verdict — either way it says so the day it is true.
03

Something in the way?

tell us and it gets fixed

If any surface of Renar or this site blocks you — a focus trap, an unlabeled control, a contrast pair that fails your tools — that is a bug, and accessibility bugs fix with the same priority as security ones: immediately, with a test that keeps it fixed.

The reporting channel publishes with the domain. The issue tracker and contact address stand here at launch.