Accessibility

A website is accessible when everyone can use it: people who navigate with a keyboard, people who rely on a screen reader or magnification, people with low vision or color blindness, and people on a slow connection or a small screen. Nausikaä is built to make that the default outcome rather than extra work.

A stylesheet can only do part of the job, though. This page describes what Nausikaä takes care of, what remains up to you, and where Nausikaä still falls short. The guidelines referred to are the Web Content Accessibility Guidelines (WCAG) 2.2, level AA.

Standards and law

In the European Union, the European Accessibility Act (Directive 2019/882) applies since 28 June 2025. It covers services for consumers such as web shops, e-books, banking and the sale of tickets for transport, and asks that their websites and apps can be used by people with disabilities. Microenterprises, with fewer than ten people and a turnover of at most €2 million, are exempt for the services they provide. A business that is covered also has to explain how its service meets the requirements, usually in an accessibility statement.

The act doesn’t list technical rules itself. A website that meets the European standard EN 301 549 is presumed to meet the act. The version cited today, 3.2.1, asks for WCAG 2.1 level AA; version 4.1.1, published in September 2026, asks for WCAG 2.2 level AA and is expected to take its place. Nausikaä aims at WCAG 2.2, so a site built with it is ready for both.

Nausikaä is not a certificate: whether a site meets the act depends on all of it, the HTML, the content and the scripts included. Nausikaä takes care of the parts a stylesheet can; the rest is described under Your part.

What Nausikaä does

What the stylesheet takes care of
Native elements Nausikaä styles the HTML elements themselves instead of replacing them with look-alikes. A styled <button>, <select> or <dialog> keeps all the keyboard behavior and screen reader support the browser gives it. Dropdowns, the navbar menu, the sidebar and subnavs that open and close are <details> elements, which work with the keyboard and announce whether they are open, without a script.
Readable contrast Every text color reaches a contrast ratio of at least 4.5:1 against its background, in the light and the dark theme, the WCAG AA level for normal text. That includes every color of buttons, tags, knobs, notifications and panels, also while hovered or pressed. The borders of form fields, the focus outline and the filled part of meters reach 3:1, the level for the parts of a control. The e-ink theme goes further: black on white, and no text on a mid-grey. Every page of this documentation is checked for text contrast automatically, in all five themes.
Visible focus Everything that can get the focus shows the same clear outline, 2px wide and 2px away from the element, so it stands out on every component color. It appears for keyboard use and stays hidden after a mouse click. Set its color with --nausikaa-focus-outline.
High contrast In the forced colors of a high contrast theme, such as those of Windows, the browser replaces every color and drops shadows. Nausikaä then marks pressed, checked and current items with the highlight color of the theme, shows errors in fields with a dashed border, and keeps icons, progress bars and meters visible.
Light, dark and high contrast The theme follows the visitor’s system setting, and built-in controls such as scrollbars and checkboxes follow the theme. When the visitor has asked their system for more contrast, a high contrast version of the light or dark theme applies, with text at 7:1, the AAA level. A fifth theme, for e-ink displays, has to be chosen: such a display doesn’t tell the browser what it is. See Theming.
Reduced motion When the visitor has asked their system to reduce motion, animations and transitions finish at once, and the page doesn’t scroll smoothly. Only spinners and loading buttons keep turning, slowly, because a spinner that stands still says nothing. In the e-ink theme nothing moves at all.
Reduced transparency When the visitor has asked their system to reduce transparency, the page behind a dialog is darkened almost completely and isn’t blurred, and layers over the page become solid.
Text size and zoom The text size is set in rem, so it grows with the default font size a visitor chooses in the browser. Layouts adapt to the available width, so pages stay usable when zoomed in. Buttons grow when their text wraps, code breaks on narrow screens, and dialogs scroll when they are taller than the screen. See Responsive design.
Where a link lands After following a link to a part of the page, such as #your-part, the heading of that part gets a thick underline in the color of the focus outline, and it stops a little below the top of the window. People who zoom in, or who move through the page with the keyboard, see where they landed. The line stands still, so it doesn’t count as motion.
Media Images, video, audio, iframes and canvases never get wider than their container, so they don’t make a page scroll sideways on a small screen or when zoomed in. Captions, transcripts and titles are up to you; see Video, audio and embeds.
Text spacing Some people read more easily with more space between lines, letters and words, and set it in their browser. Nausikaä keeps all text visible with the spacing WCAG asks to support: lines 1.5 times the text size, 2 times the text size after a paragraph, letters 0.12 and words 0.16 times apart. Labels wrap instead of being cut off. Text that ends in an ellipsis, such as a long title in a list, is shortened on purpose; make sure the full text is one click away, as a link to the item.
Target size Buttons, knobs and form fields are well over 24 by 24 pixels, the WCAG 2.2 minimum. Smaller controls, such as the day numbers of the calendar and the remove buttons of a file list, have a larger area to click than they show.
ARIA states Where a component has a state, the ARIA attribute for it gives the same look as the class: aria-current for the current page or step, aria-pressed, aria-expanded, aria-disabled and aria-busy on buttons, and aria-invalid on fields. Write the state once, and it is both seen and heard.

Your part

Most of accessibility is in the HTML itself. The examples in this documentation follow these practices; use them as a starting point.

  • Set the language of the page with <html lang="en">, so screen readers pronounce the text correctly.
  • Use headings in order. One <h1> per page, and no skipped levels: many screen reader users navigate by headings. Choose a heading for its level, not for its size.
  • Label every form field with a <label>. A placeholder is not a label: it disappears as soon as someone starts typing. Group related radio buttons and checkboxes in a fieldset with a legend.
  • Describe images with an alt text, or use an empty alt="" for decorative images. See Images.
  • Name your tables with a <caption>, and give header cells a scope. See Tables.
  • Write link texts that make sense on their own. “Read the installation guide” helps; “click here” doesn’t, especially in a list of links.
  • Choose elements for their meaning. <del> and <ins> mark changes, <q> a quotation, <dfn> the term being defined, and <hgroup> a heading with a subtitle. See Typography.
  • Don’t rely on color alone. A red border on a field isn’t enough to explain an error: add a text that says what is wrong and how to fix it, and set aria-invalid="true" on the field. The e-ink theme is a good test: there a red and a blue tag look the same.
  • Use buttons for actions and links for navigation. A <button> works with the keyboard out of the box; a clickable <div>, or an <a> without an href, does not. Give a button that only shows an icon a name with aria-label.
  • Add ARIA only where HTML falls short. Native elements already tell assistive technology what they are. ARIA is for custom widgets, for example aria-expanded on a button that a script uses to open a menu.
  • Add a skip link as described above.
  • Publish an accessibility statement if the European Accessibility Act applies to you: what you have tested, what doesn’t work yet, and how people can reach you when something is in their way.

Test it yourself: put the mouse aside and use the page with only the keyboard (Tab, Shift+Tab, Enter, Space, Esc), zoom in to 200% and further, turn on a high contrast theme, and try a screen reader such as NVDA on Windows or VoiceOver on macOS and iOS. Automated checkers like WAVE catch many common problems, but not all of them.

Known limitations

Nausikaä doesn’t get everything right yet. These are the known issues; keep them in mind when you use the affected parts.

Known issues
Closing dropdowns A dropdown written as <details> closes when its summary is used again, but not with Esc or a click elsewhere. Add a few lines of script where that matters, or use a popover in browsers that support it.
Older forms Dropdowns that open on focus, and the navbar, sidebar and subnav toggles built with a hidden checkbox, still work for sites written for Nausikaä 1.0. They don’t announce their state, and focus dropdowns can’t be closed without moving the focus away. The expandable panel still uses a hidden checkbox. Use the <details> forms for new work.
Charts in high contrast In forced colors mode, charts keep their own colors so the series can still be told apart, but those colors don’t follow the high contrast theme. Label the series in text as well, and give the numbers in the HTML, as the chart examples do.
Text colors in the editor A text color chosen in the editor is stored with the text, as a fixed color. No color reads well on both the light and the dark background, so such text may be hard to read in one of the themes. Highlights don’t have this problem: they get black or white text to match.
Editor menus The menus in the toolbar of the editor open while they have the focus, like the older dropdowns. The buttons in them work with the keyboard.