Accessible Astro Starter: a WCAG 2.2 AA template with contrast checking and preference toggles

What the template is: accessibility decisions made once, in a starter

accessible-astro-starter is described as a ready-to-use, SEO and accessibility-focused Astro starter template, built with modern web standards, WCAG 2.2 AA guidelines, and European Accessibility Act compliance in mind. The mission statement is more specific than a slogan: provide developers with accessible, easy-to-use components that make building inclusive web applications simpler and faster, without compromising on customization or performance. That last clause is the one to test. The template makes a lot of decisions for you, the colour system, the font, the component set, the navigation model, and the value of the starter is that those decisions have already been made to a standard rather than left to each project. The homepage is starter.incluud.dev, there is a live demo and a separate documentation site, and the licence is MIT.

The semantic layer: landmarks, skip links and a screen reader only class

The accessibility features list is long and it is best read as a list of specific defects the template removes. There are accessible landmarks, with header, main, footer, section and nav, so a screen reader user can jump between regions. There is a SkipLinks.astro component to skip to either the main menu or the main content, which is the single most valuable addition to a site with a persistent header. There is a .sr-only utility class for screen reader only text content that hides the text visually, so you can add a label that only assistive technology sees. Several aria attributes provide a better experience for screen reader users. There is a Navigation.astro component with keyboard accessible dropdown navigation and a highlighted menu item option, and a Header.astro component described as optimised for accessibility and design. The theme comes with a Button, a Link and a Heading component so the semantic element is chosen by the component rather than by the caller.

The three preference toggles, and the system preference fallback

Three preference toggles ship with the template: Dark Mode, High Contrast and Reduced Motion, each with system preference support. The reduced motion one is implemented with prefers-reduced-motion, which disables animations for users who have that preference turned on, and the micro-interactions and animations on hover, open and close states respect that preference too. The combination of a manual toggle and a system default is the right pattern, because the manual toggle lets a user override the system once without fighting it on every page. The High Contrast toggle is separate from Dark Mode, which is the detail that shows the thinking: dark mode is a colour scheme, high contrast is an accessibility mode, and a user who needs the second should not have to settle for the first.

The command launcher and the contrast checker

Two features go beyond the usual starter template. There is a built-in command launcher with keyboard navigation, bound to Cmd or Ctrl+K, for quick access to preferences and navigation. That is a real accessibility affordance rather than a power user flourish, since a keyboard-driven launcher gives a keyboard user a single entry point for everything instead of tabbing through a page. And there is a ColorContrast.astro component plus a Color Contrast Checker interactive page for enhanced visual clarity and WCAG compliance, alongside an Accessibility Statement template page. Both of those are documents and tools rather than styling, and they are the pieces a team usually skips and then regrets skipping, because a contrast checker makes the WCAG requirement checkable during design rather than at audit time.

Forms, which is where accessibility projects usually stop

The form components are listed with unusual emphasis: Form, Input, Textarea, Checkbox, Radio and Fieldset with WCAG 2.2 compliance, plus automatic form validation with custom patterns, error handling and screen reader support. The list of components to build is the easy part, and the hard part is what the library does with them. Error handling that reaches a screen reader means the error is programmatically associated with the field, not just coloured red next to it. Custom patterns means the format expectation is stated before submission rather than after. A Fieldset component matters for radio groups, where the group question needs to be programmatically bound to its options. There is also a contact page described as a showcase for comprehensive form validation and accessibility demonstrations, and a thank-you page for submissions with interactive feedback, which is the screen reader experience after a successful submit.

The design system: OKLCH, Atkinson Hyperlegible, SCSS utilities and Tailwind 4

The visual foundation is described with some specificity. There is a modern OKLCH colour system with automatic palette generation from primary and secondary colours, which is a perceptually uniform space and therefore a better base for generating a scale that holds contrast. The typeface is Atkinson Hyperlegible, chosen for improved readability and accessibility, which is a legibility-first face rather than a display face. The Lucide icon set comes in through astro-icon for consistent, friendly icons. The CSS uses logical properties and custom properties, so the layout follows writing direction and the theming is done through variables rather than by rewriting rules. There are comprehensive SCSS utility classes alongside the Tailwind CSS 4.1+ integration, and the font is served locally rather than from a third party CDN, which is a real performance and privacy point for a template that claims excellent Lighthouse and PageSpeed scores.

Content and pages: dynamic routes, MDX, sitemap and a 404 page

The template ships a working site rather than a blank page, and that is a deliberate choice for a starter. There are dynamic route examples, with [...page].astro and [post].astro demonstrating the use of dynamic routes and providing a basic blog with breadcrumbs and pagination, and a 404.astro custom error page you can adjust. Blog and portfolio pages come with featured images, author details, social sharing and breakout images, and there are SocialShares.astro and FeaturedPosts.astro and FeaturedProjects.astro components. Markdown and MDX are supported with comprehensive examples and components, content collections are supported through the TypeScript integration, and a comprehensive sitemap page with organised navigation and automatic XML sitemap generation via @astrojs/sitemap is included. A SiteMeta.astro SEO component sets custom metadata per page, and the .env.example shows where the blog content comes from, a BLOG_API_URL pointing at the jsonplaceholder test API.

The CLI, the presets and the tooling you inherit

There is a create CLI that scaffolds projects directly from the starter with npm create accessible-astro-starter@latest. The CLI walks you through the project directory, the site name, a preset selection of full, blog, portfolio, minimal or barebones, and whether to keep the Accessible Astro launcher. The documentation also says what generated projects do not keep: they always strip contributor-only tooling, which is workspaces, CI config and changelog config, and they generate a simplified astro.config.mjs tailored to the chosen preset. That is a sensible default, since a scaffolded project should not inherit the upstream repository's monorepo and release plumbing. The template ships Prettier with prettier-plugin-astro and prettier-plugin-tailwind, and ESLint with strict accessibility settings for eslint-plugin-jsx-a11y, and the repository has an AGENTS.md, a cliff.toml for changelog generation, a theme.config.ts and a packages/ workspace holding the CLI.

npm create accessible-astro-starter@latest

npm install
npm run dev
npm run build

Editorial conclusion

Accessible Astro Starter suits a team that needs to ship a site that meets a stated accessibility bar and wants the decisions already made, from landmark structure to focus indication to reduced motion handling, rather than rediscovering them per project. It is the wrong choice for a project with an existing design system, since a starter that decides your colour palette, typography and component set is a starter you will fight, and a poor fit if you cannot commit to the version pinning, because the feature list names a minimum Astro version. Before adopting it, confirm the Astro version on offer satisfies the stated 6.1.1 requirement, and read the Accessibility Statement template page the project ships, since it gives you a starting point for the compliance documentation you will still have to write yourself.

Frequently asked questions

Official sources

1. incluud/accessible-astro-starter on GitHub
2. License: MIT
3. Project website
4. README
5. Releases