Accessibility

What was tested, and what is not fixed

No law requires this site to be accessible. It aims at WCAG 2.2 AA anyway, and the parts that can be checked automatically are checked on every build rather than at launch.

Enforced by the build

These fail the build rather than appearing on a checklist: the page reflows at 320px without horizontal scrolling, no focus indicator ends up underneath the sticky navigation, every page keeps one h1 and a working skip link, every route stays readable with JavaScript switched off, and no request leaves this origin.

Decisions rather than defaults

Nothing is signalled by colour alone; where something needs flagging it gets a shape and a word as well. The one animation on the site is decorative, respectsprefers-reduced-motion, and every element it touches is fully visible before it runs, so a blocked animation costs a reader nothing.

Known to fall short

The technical drawings on the case studies keep their size on a phone and scroll inside their own container rather than shrinking to unreadable. Each carries a text description of what it shows, and the container takes keyboard focus so it can be scrolled without a mouse — but a horizontal scroll is still a worse experience than a diagram that reflowed, and I have not solved that.

The product screenshots are pictures of other software. Their alt text describes what the screenshot shows and why it is on the page, which is what the figure is for. It does not transcribe every label inside the interface.

This is a self-assessment. It has not been tested with a screen reader by anyone who uses one daily, and that is the gap most likely to be hiding something.

If something does not work

Email takalashna@outlook.com and say what you were trying to do. That is a more useful report than a conformance level, and it will get a reply.