Accessibility of this site

What has been implemented

These are verified rather than assumed, and most are covered by an automated test.

• Semantic landmarks on every page, with one H1 and a logical heading order
• A skip link to the main content as the first focusable element
• Full keyboard operability, including navigation menus, accordions and every interactive tool
• A visible focus indicator with a 3px outline that meets contrast requirements against every background
• Text and interface contrast meeting AA in both light and dark themes
• Form labels bound to their controls, required fields marked in text as well as colour, and an error summary that receives focus
• Status messages announced through live regions rather than only visually
• Touch targets of at least 44 by 44 CSS pixels
• Reduced-motion support: all animation and smooth scrolling is disabled when the system preference is set
• Meaningful alternative text on every image, and a title and description on every diagram
• Tables with caption and scope, so structure is conveyed to assistive technology
• No information conveyed by colour alone — states carry a text label as well

How it is tested

Automated axe-core checks run against every route in the build. Playwright covers keyboard navigation, focus management and the mobile menu across Chromium, Firefox and WebKit, at viewport widths from 320 to 1920 pixels.

Automated testing catches a useful fraction of accessibility defects but not all of them. Manual keyboard and screen-reader passes are part of the release process.

Known limitations

Stating these is more useful than claiming none exist.

• The architecture and workflow diagrams carry a title and description, and their content is also expressed as text on the same page. A complex diagram remains harder to consume non-visually than the equivalent prose, and the prose is the authoritative version.
• Code samples showing JSON schemas on the WebMCP page are presented in a scrollable region. They are supplementary to the prose description of each tool.
• Third-party components, where any are introduced, are assessed before use but are not under Ayonix control.

Reporting a barrier

Email infojp@ayonix.com describing what you were trying to do, what happened, and the browser and assistive technology you were using. Accessibility barriers are handled as defects with the same priority as any other functional defect, not as enhancement requests.