Our commitment

The Umami Post is designed to meet WCAG 2.2 Level AA standards. We aim to make every page readable, navigable, and usable for people with visual, auditory, motor, and cognitive disabilities. This is not a compliance checkbox, it is part of how we think about publishing.

What we have built

Visual accessibility

  • Colour contrast: All text meets or exceeds 4.5:1 contrast ratio against its background. Large text meets 3:1. Both light and dark modes are tested.
  • Dark mode: A full dark theme is available via the toggle in the header. It respects your system preference on first visit.
  • Font sizing: Global display settings and per-page reading settings allow you to increase text size from 14px to 24px.
  • Font choice: 27 fonts available across system serif, sans-serif, monospace, and web fonts (loaded on demand from Bunny Fonts), including high-legibility options like Atkinson Hyperlegible.
  • Highlight colours: 6 highlight colour options so users can categorise and distinguish annotations visually; colours adapt across all themes (light, dark, sepia, cream).
  • Reading ruler: Customisable guide line to help track reading position, adjustable thickness, colour, and style; fixed position on mobile devices.
  • No motion by default: Animations respect prefers-reduced-motion. Transitions are disabled for users who prefer reduced motion.

Keyboard navigation

  • Skip-to-main link: The first element on every page is a "Skip to main content" link, visible on keyboard focus.
  • Focus indicators: All interactive elements have visible focus rings when navigated by keyboard.
  • Keyboard-accessible dropdowns: Navigation dropdowns open on focus as well as hover.
  • Calendar navigation: The events calendar supports arrow keys, Enter, Escape, PageUp/PageDown.
  • Search shortcuts: Press / to open search, arrow keys to navigate results, Enter to open, Escape to close.

Screen readers

  • Semantic HTML: We use proper heading hierarchy (h1-h3), landmark regions (nav, main, footer), and list markup.
  • ARIA labels: All icon-only buttons have aria-label attributes. Interactive toggles use aria-expanded.
  • Form labels: Every form input has an associated label element. Required fields use aria-required. Hints are connected via aria-describedby.
  • Live regions: Form status messages and search results use aria-live for screen reader announcements.
  • Image alt text: All meaningful images have descriptive alt text. Decorative images use aria-hidden="true".

Reading and recipe tools

  • Reading settings: Font, size, line spacing, text width, word spacing, reading ruler, and auto-scroll, available on every article and recipe page.
  • Rich-text notes: WYSIWYG editor for cook's notes, no markdown syntax required.
  • Ingredient checklist: Each ingredient row is a labeled checkbox; state persists across reloads via localStorage.
  • Serving scaler: 0.5x / 1x / 2x buttons re-render ingredient amounts in place; readable for screen readers.
  • Cooking mode: A hands-free recipe view with larger type and a screen wake-lock so the page stays open while you cook.

Touch and mobile

  • Touch targets: All buttons and interactive elements meet 44x44px minimum touch target size -- important for greasy fingers in a working kitchen.
  • Responsive design: Every page adapts to screen sizes from 320px to ultrawide.
  • No hover-only interactions: Everything accessible by hover is also accessible by tap or keyboard.

SPA navigation

  • Instant transitions: Most page navigations swap content without a full reload, reducing wait times and avoiding blank-screen flashes.
  • Graceful fallback: Pages with complex interactive features (articles, library entries) use full reloads to ensure all reader tools initialise correctly.

Performance as accessibility

  • Fast loading: Pages are pre-built static HTML served from a global CDN. No waiting for server-side rendering.
  • Offline support: Previously visited pages work without an internet connection.
  • Low bandwidth: No tracking scripts, no advertising payloads. The site works on slow connections.

Known limitations

  • The GTranslate machine translation widget has its own accessibility characteristics that we cannot fully control.
  • The Cusdis comment system renders in an iframe with its own styling.
  • Cooking mode's screen wake-lock requires HTTPS and is not available in every browser. The recipe still functions without it.
  • The hCaptcha widget on forms has its own accessibility trade-offs.

Reporting issues

If you encounter an accessibility barrier on this site, please let us know. We take every report seriously and fix issues as quickly as we can.

When reporting, please include: the page URL, what you were trying to do, what assistive technology you are using (if any), and what happened.

Last updated: 2026