Skip to main content

Designed for different ways of interacting

Accessibility is part of the architecture.

Accessibility is treated as an engineering constraint on how this portfolio is navigated, operated and presented — carried by shared components and checked as they change, not applied as a final compliance pass. This page describes what that covers, how it is tested and where it still falls short.

Last reviewed: September 2026

Target

A reference, not a certificate

WCAG 2.1 Level AA is the standard new interface work is designed and reviewed against. Stating a target is different from claiming to meet it, so both sides are spelled out here.

WCAG 2.1Level AAEngineering target

What this means

  • Interface work is designed and reviewed against the WCAG 2.1 Level AA success criteria.
  • Shared components carry those decisions, so a new surface inherits keyboard, focus and dialog behaviour instead of rebuilding it.
  • When an automated check finds a violation, it is recorded as a defect with an owner — not quietly excluded from the check.

What it does not mean

  • It is not a claim of WCAG conformance. No complete, independent conformance evaluation has been carried out.
  • It is not a certification, and not a statutory accessibility declaration.
  • It does not mean every combination of browser, assistive technology and setting has been tested.

Interaction

More than one way to operate the same interface

Each mode below corresponds to a specific implementation in the portfolio, not a general intention.

Keyboard

The first Tab stop on every page is a link that skips past the header to the main content. Controls are native buttons, links and form fields. Dialogs and menus close with Escape, and Focus View pages through photographs with the arrow keys.

Touch

Gestures are shortcuts, never the only route. Swiping pages through photographs beside the previous and next buttons; the mobile menu that closes with a swipe also closes with its button, Escape or a tap outside. Buttons use KERN's 48-pixel minimum height; custom touch controls are at least 44 pixels.

Pointer

Hover is never required. The actions that appear when you hover over a gallery photograph also appear when it receives keyboard focus.

Screen readers

Pages use header, main and footer landmarks and headed sections. Conversations with the assistants are exposed as a log, and progress and errors are announced through status regions.

Reduced motion

When your system asks for less motion, shared animation timings collapse, smooth scrolling is turned off and entrances are skipped. Swipe gestures keep working without their animated follow-through.

Zoom and reflow

Pinch-zoom is never disabled. Layouts reflow down to 320-pixel-wide screens without sideways scrolling.

Voice

The assistants accept spoken questions, transcribed by a speech model that runs in your browser. Narration of an answer only plays after you choose Listen or switch on automatic narration.

In the interface

Where it shows up

Concrete examples of how those modes are built into the components the whole portfolio uses.

Navigation

Below desktop widths, navigation opens as a native modal dialog: the page behind it becomes inert, focus stays inside it, and closing it returns focus to the menu button. The current page is announced, not only highlighted.

Dialogs

Modal surfaces are built on the native dialog element through KERN's dialog components, so focus containment and Escape come from the platform rather than from custom code.

Photography Focus View

The full-screen photograph view is a native modal dialog with named previous, next and close controls. The current position is announced, and each photograph is described by curated alternative text, falling back to its caption and title.

AI conversations

The Engineering and Photography conversations share one shell. Settled questions and answers form a conversation log; the answer being prepared is announced through a single polite status region instead of a second copy.

Motion

Entrances are progressive: content is in the page before any animation runs, so nothing depends on JavaScript or motion to become visible.

Safe areas

Fixed controls — the navigation island, the mobile menu, Focus View's controls and the conversation window — are written to stay clear of rounded corners and the home indicator on devices that report safe areas. Edge-to-edge layout on those devices is not switched on yet; it is waiting for testing on physical devices.

Evidence

What has been tested — and what hasn’t

An accessibility statement is only as credible as the checks behind it. This is the current state, including the gaps.

  • Static analysis

    In place

    Biome's recommended rules, including its accessibility rules, and TypeScript's strict checks run before every commit and on every pull request.

  • Rendered axe-core audits

    Partial

    A rendered-state verifier runs axe-core's WCAG 2 A and AA rules against a fixed set of pages and states — the homepage, the photography gallery and an engineering route — at mobile and desktop sizes, and allows no violations on any of them. It covers those surfaces, not the whole site, and runs on demand rather than on every change.

  • Repository tests

    In place

    Unit tests pin interaction contracts: dialog semantics, live-region placement, focus behaviour and reduced-motion branches. They test the logic behind the interface, not the rendered accessibility tree.

  • Browser and emulation

    Partial

    Layout, overflow, keyboard and reduced-motion behaviour are checked in Chromium at phone, tablet and desktop sizes while features are built. Emulation cannot reproduce everything a real device does.

  • Screen readers and physical devices

    Not yet

    There is no recorded test matrix for screen readers such as VoiceOver, NVDA or TalkBack, and no documented testing on physical phones and tablets.

  • Independent audit

    Not yet

    No independent WCAG conformance audit has been performed.

Known limitations

  • The photo constellation and the map are visual, canvas-based ways of exploring. The same photographs are reachable through the gallery, search and Focus View, but those visualizations themselves are not fully described to assistive technology.
  • Photograph descriptions come from curated metadata and can describe visual detail less completely than the image itself.
  • AI answers can be incomplete or wrong. Their structure is accessible; their content is only as good as the evidence behind them.

Contact

Found a barrier?

If something in this portfolio is hard or impossible to use, please tell me. Include the page, what you were trying to do and, if useful, the browser or assistive technology you were using.

Report an accessibility barrier by email

Legal context

This is a personal and professional portfolio. It contains no shop, checkout, payment flow or consumer-contract service, so it does not appear to provide an electronic-commerce service as defined by the German Accessibility Strengthening Act (BFSG). This is an engineering assessment, not legal advice.

This page voluntarily documents the portfolio's accessibility approach and known limitations. It is not a statutory accessibility declaration, a certification or a statement of legal conformity.

Official text of the German BFSG

Read next