✦ Conformance report
naxatar Accessibility Conformance Report
WCAG Edition
(Based on VPAT® Version 2.5Rev)
Name of Product/Version: naxatar.com — public website, build 415f899 (19 August 2026)
Report Date: August 2026
Product Description: naxatar.com is the public marketing and documentation website for naxatar, a one-person software studio. It is a statically generated site (Astro 5) of 17 routes comprising a homepage presented as a locked full-page slide deck over a WebGL background, two product pages with their documentation, a blog, legal pages, and a Google-OAuth sign-in flow. It contains two web forms (a contact form and a product-feedback form). It contains no audio or video content.
Contact Information: [email protected]
Notes:
- This report covers the five routes named under Scope of Evaluation below, not all 17 routes of the site. WCAG conformance is scoped to full pages, and evaluating and honestly documenting five representative pages was judged more useful than partially evaluating seventeen. The five were chosen to cover every page archetype and every technology on the site.
/blog/apollyon-jet-drones-visualized/is explicitly out of scope. It is a self-contained 750-line document with its own colour palette and eleven interactive SVG charts, and it does not use the shared site layout. It received the site-wide contrast correction and amainlandmark during remediation, but its charts were not evaluated for keyboard operation, non-text content, or non-text contrast. It should not be assumed conformant.- Table 3 (Level AAA) has been removed, as permitted by the template, because Level AAA is not the level being reported. Two AAA criteria were evaluated incidentally and are noted here rather than claimed: 2.3.3 Animation from Interactions is met (
prefers-reduced-motion: reduceis honoured completely — the WebGL library never loads, the cursor canvas is removed from the DOM, and zero animations run), and 2.4.12 Focus Not Obscured (Enhanced) is not met (one form field on the documentation page is partially overlapped by the fixed header when focused). - This report was authored by the site's sole developer. It is a self-assessment, not a third-party audit.
- Screen-reader coverage is VoiceOver on macOS only. NVDA and JAWS on Windows were not tested. Cross-engine verification in Chromium, WebKit and Gecko was performed instead and is described under Evaluation Methods Used; it is not equivalent to testing a second screen reader.
- This report is published at naxatar.com/accessibility/conformance-report/, alongside an accessibility statement and the audit record at naxatar.com/accessibility/. Those hub pages were added after the evaluated build; they are scanned by the same automated harness on every run (0 violations) but are not part of the evaluated scope above.
- Remediation history and the underlying evidence are published alongside this report in the
a11y/directory of the site's repository:before-after.html(before/after summary),manual-findings.md(defects found only by manual testing, with reproduction steps),baseline/andfinal/(raw tool output), andtools/(the test harness, so any figure here can be reproduced).
Evaluation Methods Used:
Testing was performed by the site's developer, who has full knowledge of the product's functionality.
Automated testing. axe-core 4.x driven by Playwright across all 17 routes in both the light and dark themes (34 scans), with the rule tags wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa. Google Lighthouse 12 (accessibility category) across all 17 routes. Both were run against the deployed production site as well as against local builds.
Manual testing. Keyboard-only traversal of every focusable control on the evaluated pages, recording for each stop whether the focused control was actually painted (not merely positioned on screen) by walking its ancestor chain for opacity, visibility and display. Zoom to 200% and reflow at 320 CSS pixels and 400%. Application of the text-spacing metrics required by SC 1.4.12 via an injected user stylesheet, checking for clipped content. Forced-colors / high-contrast mode. Colour ratios computed directly from the theme's CSS custom properties rather than read from a tool, because the site's translucent glass surfaces over a WebGL canvas defeat automated contrast sampling. Target sizes evaluated against SC 2.5.8's spacing and inline exceptions by computing 24-pixel circle intersection, not by size threshold alone.
Assistive technology testing. VoiceOver on macOS with Safari — used to verify reading order, landmark and heading navigation, form labelling, and the homepage deck. This pass found a defect no other method had: VoiceOver's reading cursor moves without moving DOM focus, and it caused the deck to display a blank screen while speaking the correct content. That defect has been corrected and re-verified.
Screen readers covered by this evaluation: VoiceOver on macOS only. NVDA and JAWS on Windows were not tested; no Windows environment was available for this evaluation. This is a real limitation and it is not papered over — a criterion verified with one screen reader is verified with one screen reader.
Cross-engine verification, in place of a second screen reader. Because a screen reader reads the accessibility tree the browser publishes, and because differences between those trees are precisely what makes one screen reader behave unlike another, the evaluation was repeated in all three engines a screen reader can sit on: Chromium (Chrome, Edge), WebKit (Safari, all iOS browsers) and Gecko (Firefox — the engine NVDA is most commonly paired with). In each engine, across six routes: axe-core reported 0 violations; the exposed role, accessible name, aria-pressed/aria-checked state and tab index of 21 controls were compared and the three engines agreed on every one; the same five live regions were present; and the custom radio group's keyboard behaviour was byte-for-byte identical. The same run against the deployed production site returned the same results. This establishes that the semantics a screen reader would consume are consistent across engines. It does not establish how any particular screen reader announces them.
Tools. axe-core, Google Lighthouse, Playwright driving Chromium, WebKit and Gecko, and purpose-written probes published in a11y/tools/.
Scope of Evaluation
| Route | Why it is included |
|---|---|
/ |
The homepage. The locked full-page deck, the WebGL background and its motion control, the constellation navigator, and the contact form. The most complex surface on the site. |
/products/playlist-wrangler/ |
A product page. The feedback form with its custom radio group, a horizontally scrolling screenshot strip, and an embedded frame. |
/products/playlist-wrangler/docs/ |
Documentation. The longest page, ~92 interactive controls, in-page anchor navigation, and disclosure widgets. |
/blog/where-does-the-small-text-go/ |
The blog article template, rendering Markdown prose. |
/login/ |
Authentication, via Google OAuth. |
Applicable Standards/Guidelines
This report covers the degree of conformance for the following accessibility standard/guidelines:
| Standard/Guideline | Included In Report |
|---|---|
| Web Content Accessibility Guidelines 2.0 | Level A — Yes Level AA — Yes Level AAA — No |
| Web Content Accessibility Guidelines 2.1 | Level A — Yes Level AA — Yes Level AAA — No |
| Web Content Accessibility Guidelines 2.2 | Level A — Yes Level AA — Yes Level AAA — No |
Terms
The terms used in the Conformance Level information are defined as follows:
- Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
- Partially Supports: Some functionality of the product does not meet the criterion.
- Does Not Support: The majority of product functionality does not meet the criterion.
- Not Applicable: The criterion is not relevant to the product.
- Not Evaluated: The product has not been evaluated against the criterion. This can only be used in WCAG Level AAA criteria.
WCAG 2.x Report
Note: When reporting on conformance with the WCAG 2.x Success Criteria, they are scoped for full pages, complete processes, and accessibility-supported ways of using technology as documented in the WCAG 2.x Conformance Requirements.
Table 1: Success Criteria, Level A
Notes: All 17 routes were scanned automatically; the manual evidence behind these answers comes from the five routes named under Scope of Evaluation.
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.1.1 Non-text Content (Level A) | Supports | Every img element carries an alt attribute; none is missing across all 17 routes. Product screenshots carry descriptive alternatives naming the feature shown. Decorative graphics — the SVG starfield, the WebGL canvas, the cursor canvas, icon glyphs, and the shooting-star elements — are removed from the accessibility tree with aria-hidden="true" on the element or an ancestor. The wordmark is inlined SVG inside an aria-hidden span adjacent to the text "naxatar", so the brand name is available as text. |
| 1.2.1 Audio-only and Video-only (Prerecorded) (Level A) | Not Applicable | The site contains no audio or video content. Verified programmatically: zero audio, video, embed and object elements on the evaluated routes. |
| 1.2.2 Captions (Prerecorded) (Level A) | Not Applicable | No prerecorded synchronised media. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) | Not Applicable | No prerecorded synchronised media. |
| 1.3.1 Info and Relationships (Level A) | Supports | Each page has exactly one main landmark, a nav with an accessible name, and a header. Every form control is programmatically associated with a visible label via for/id. Lists use list markup, the FAQ uses native details/summary, and the product cards use article with their own heading. Heading levels are sequential on the evaluated routes. Two defects were corrected during remediation: an h1 → h3 jump on both product pages, where a section eyebrow that visually functioned as a heading was marked up as a span and is now an h2; and a page with no heading at all. |
| 1.3.2 Meaningful Sequence (Level A) | Supports | Reading order follows DOM order on all evaluated routes. The homepage deck's five slides are sequential section elements in the order they are presented; the deck's visual paging is a CSS transform over that same sequence and does not reorder content. Verified by reading order with VoiceOver. |
| 1.3.3 Sensory Characteristics (Level A) | Supports | No instruction depends solely on shape, colour, size, visual location, orientation, or sound. The one directional cue — "Scroll for more →" beneath the screenshot strip — is accompanied by the word "Scroll", and the strip is also reachable and operable from the keyboard. |
| 1.4.1 Use of Color (Level A) | Supports | Product availability is conveyed by the words "Available" and "Public beta", not by the colour of their indicator. Form errors are conveyed as text. One defect was corrected during remediation: the site's only link sitting inside a run of prose was distinguished from its surrounding text by lightness alone — --ink on --muted body copy measures 2.92:1 in the light theme and 2.44:1 in the dark, below the 3:1 that the colour-difference technique requires — and now carries an underline. Links in blog prose were already underlined. Links standing alone on their own line have no surrounding text to be confused with. |
| 1.4.2 Audio Control (Level A) | Not Applicable | The site plays no audio. |
| 2.1.1 Keyboard (Level A) | Supports | All functionality is operable from the keyboard. Two failures were corrected during remediation, both significant. First, the homepage deck did not follow keyboard focus: because the document is overflow: hidden, the browser scrolled the pager's fixed shell to bring a focused control into view while the deck's own position variable did not change, so the slide was never activated and its content remained at opacity: 0 — 18 of 35 tab stops placed focus on unpainted content, including every field of the contact form. Second, the screenshot strip on the product page was a scroll container holding only images, with no focusable content and no tabindex, making four of its five screenshots unreachable without a pointer. After remediation, a 36-stop traversal of the homepage records zero unpainted stops and zero instances of the shell being scrolled out from under the deck. |
| 2.1.2 No Keyboard Trap (Level A) | Supports | Focus cycles through and out of every evaluated page; no component retains focus. The homepage deck, the disclosure widgets, and both forms were traversed in full in both directions. |
| 2.1.4 Character Key Shortcuts (Level A 2.1 and 2.2) | Supports | The site implements no single-character key shortcuts and no accesskey attributes. Its only keyboard handlers respond to Arrow, Page, Home, End, Space and Escape, none of which is a single printable character. |
| 2.2.1 Timing Adjustable (Level A) | Supports | No time limit is placed on reading or interaction. The OAuth callback page abandons its wait for a sign-in session after ten seconds, but this is a network timeout rather than a limit on the user: it replaces the status text with an error and presents a "Try signing in again" link, so the process can be resumed without loss. |
| 2.2.2 Pause, Stop, Hide (Level A) | Supports | The homepage runs 39 indefinitely looping animations — a twinkling starfield, two shooting stars, a wordmark cross-fade, a constellation shimmer — plus a WebGL galaxy. A failure was corrected during remediation: the header's background control switched off only the WebGL layer, leaving all 39 CSS animations running, so no mechanism existed to stop the motion. The control now freezes every looping animation as well, measured as 39 running before activation and 0 after. Users who set prefers-reduced-motion: reduce receive a still page without needing the control. |
| 2.3.1 Three Flashes or Below Threshold (Level A) | Supports | Nothing on the site flashes. The fastest repeating animation is the starfield twinkle at 2.6–7.1 seconds per cycle; the wordmark cross-fade runs over 18 seconds and the constellation shimmer over 9. No animation approaches three flashes per second, and no large-area luminance change occurs. |
| 2.4.1 Bypass Blocks (Level A) | Supports | Nine header controls preceded the content on every page and no bypass mechanism existed; a skip link was added during remediation. It is the first tab stop on every evaluated route, becomes visible on focus, is painted above the fixed header rather than beneath it, and moves focus to the main element — which carries tabindex="-1" so that focus, not merely scroll position, moves. Verified end to end on each evaluated route. The out-of-scope visual essay does not use the shared layout and therefore has no skip link, though it does have a main landmark. |
| 2.4.2 Page Titled (Level A) | Supports | Every route has a unique, descriptive title. The homepage title was the bare wordmark "naxatar" and was changed during remediation to "naxatar — fast, private apps from a one-person studio", which describes the page's topic and purpose. |
| 2.4.3 Focus Order (Level A) | Supports | Focus order follows DOM order and preserves meaning. A failure was corrected during remediation: on the homepage, focus could move into a slide the pager was not displaying, leaving the page's own position indicator reporting slide 1 of 5 while focus sat in the contact form on slide 5, and a subsequent arrow key discarded the focus position entirely. The pager now follows focus, and the position indicator, catalog readout and active slide are consistent with the focused control at every one of the 36 tab stops. |
| 2.4.4 Link Purpose (In Context) (Level A) | Supports | Link text, or link text with its programmatically determined context, identifies each link's purpose. The two product-card links read "Learn more" and "Request the beta" and take their context from the enclosing article and its heading. Because a screen reader's links list presents links out of that context, the product name was added to each as visually hidden text during remediation, so they are announced as "Learn more — Playlist Wrangler" and "Request the beta — clippal". |
| 2.5.1 Pointer Gestures (Level A 2.1 and 2.2) | Supports | No functionality requires a multipoint gesture. The homepage deck accepts a vertical swipe, but the same navigation is available through a single-tap floating button, the constellation navigator, the header links, and the keyboard. The screenshot strip scrolls by swipe, wheel, or arrow keys once focused. |
| 2.5.2 Pointer Cancellation (Level A 2.1 and 2.2) | Supports | All activation uses the default behaviour of native a and button elements, which complete on the up-event and can be aborted by moving the pointer away before release. No functionality is triggered on the down-event. |
| 2.5.3 Label in Name (Level A 2.1 and 2.2) | Supports | Controls with visible text labels expose that text in their accessible name. The icon-only controls — the theme toggle and the background-motion toggle — have no visible text label and are named by aria-label. The floating scroll button shows a hover tooltip reading "next ↓" while its accessible name is "Scroll to next section"; the visible word "next" is contained in the name in the same order. |
| 2.5.4 Motion Actuation (Level A 2.1 and 2.2) | Not Applicable | No functionality is operated by device motion or user motion. The site registers no devicemotion or deviceorientation listeners. |
| 3.1.1 Language of Page (Level A) | Supports | <html lang="en"> on all 17 routes. |
| 3.2.1 On Focus (Level A) | Supports | Receiving focus does not initiate a change of context. On the homepage, focusing a control on a slide the deck is not currently showing causes the deck to page to that slide; this is the scroll-into-view behaviour a browser would otherwise perform, is required for the control to be visible at all, and changes neither the focus, the viewport, nor the meaning of the content. The URL fragment updates to match, which is not a navigation. |
| 3.2.2 On Input (Level A) | Supports | No control submits its form or navigates on change. Verified by focusing, typing into, and changing the value of every field on the contact form: the page did not navigate or submit in any case. Both forms submit only on explicit activation of their submit button. |
| 3.2.6 Consistent Help (Level A 2.2 only) | Supports | The Support link occupies the same relative position in the header on all 17 routes, and a direct contact address is available on the homepage and via that link. |
| 3.3.1 Error Identification (Level A) | Supports | Required fields use the native required attribute and typed fields use type="email", so input errors are identified in text by the user agent, which names the field and describes the problem. Submission failures are described in text ("Something went wrong. Please try again in a moment.") inside a live region so they are announced without focus moving. Dependency: field-level error identification is delivered by the browser rather than by custom scripting, so it relies on a user agent that implements HTML constraint validation. All current major browsers do. |
| 3.3.2 Labels or Instructions (Level A) | Supports | Every field on both forms has a persistent visible label, programmatically associated. Optional fields are marked "(optional)" in the label text, so required fields are identifiable without relying on the error state. Placeholders supplement labels rather than replacing them. The feedback form's type selector is a labelled radiogroup. |
| 3.3.7 Redundant Entry (Level A 2.2 only) | Supports | Neither form is multi-step and neither asks for the same information twice. Sign-in is delegated to Google OAuth and requires no re-entry of information within this site's process. |
| 4.1.1 Parsing (Level A) | Supports | For WCAG 2.0 and 2.1, the September 2023 errata update indicates this criterion is always supported. The criterion is obsolete and removed in WCAG 2.2. |
| 4.1.2 Name, Role, Value (Level A) | Supports | Interactive controls are native a, button, input, select, textarea and details/summary elements, which expose name, role and value to assistive technology without added ARIA. The two icon-only toggles carry aria-label and, for the background control, aria-pressed reflecting its state. The feedback form's type selector is the one custom widget: it uses role="radiogroup" with three role="radio" buttons whose aria-checked is updated on selection, and the selected value is mirrored into a hidden input for submission. During remediation it was brought onto the ARIA radiogroup pattern it had been declaring: the group is now a single tab stop via roving tabindex, and the arrow keys move and select in one step with Home and End jumping to the ends, with wrapping. Previously each radio was its own tab stop and the arrow keys did nothing, so the control announced itself as a radiogroup while not behaving like one. Verified: one tab stop in the group, and aria-checked, tabindex and the submitted value all following arrow-key selection — identically in Chromium, WebKit and Gecko, on both a local build and production. The exposed role, name and state of 21 controls across the evaluated routes were compared across the three engines with no disagreement. Limitation: announcement was checked with VoiceOver on macOS only; NVDA and JAWS were not tested. |
Table 2: Success Criteria, Level AA
Notes: As Table 1.
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.2.4 Captions (Live) (Level AA) | Not Applicable | No live synchronised media. |
| 1.2.5 Audio Description (Prerecorded) (Level AA) | Not Applicable | No prerecorded synchronised media. |
| 1.3.4 Orientation (Level AA 2.1 and 2.2) | Supports | Content is not restricted to a single display orientation. No CSS locks or rotates content by orientation; verified by rendering at 844×390 (landscape) on a touch viewport, where the layout adapts and content remains available. |
| 1.3.5 Identify Input Purpose (Level AA 2.1 and 2.2) | Supports | Fields collecting information about the user carry the appropriate autocomplete token: name, email, and organization on the contact form, email on the feedback form. The remaining fields — a subject selector and a free-text message — do not collect information about the user and have no corresponding Input Purpose. |
| 1.4.3 Contrast (Minimum) (Level AA) | Supports | All text meets 4.5:1 against its background in both themes. The baseline audit recorded 214 failing nodes across nine routes, driven by two colour tokens: the site's quiet grey --faint, used for every form label, section eyebrow and caption, measured 2.24:1 in light and 3.01:1 in dark and was retuned to 4.85:1 and 4.86:1; and a separate palette inside the visual essay, retuned from 3.49:1 to 4.71:1. Ratios were computed directly from the CSS custom properties because the site's translucent glass surfaces over a WebGL canvas prevent automated sampling — axe returned 14 contrast checks on the homepage as "incomplete" rather than pass or fail for this reason. After remediation, axe reports 0 contrast violations across 34 scans including against the production site. |
| 1.4.4 Resize text (Level AA) | Supports | Text scales to 200% without loss of content or functionality; verified at a 640-pixel effective viewport. Text sizes are set in relative units and no container has a fixed height that clips text. |
| 1.4.5 Images of Text (Level AA) | Supports | Prose, headings, labels and navigation are live text. Images of text occur only where the particular presentation is essential — product screenshots showing the applications' own interfaces — and in the logotype, which is exempt. |
| 1.4.10 Reflow (Level AA 2.1 and 2.2) | Supports | No two-dimensional scrolling is required at a 320 CSS pixel width, nor at 200% or 400% zoom, on any evaluated route. The screenshot strip scrolls horizontally by design, which the criterion permits for content requiring two-dimensional layout, and it is keyboard operable. |
| 1.4.11 Non-text Contrast (Level AA 2.1 and 2.2) | Supports | A failure was corrected during remediation: every text input, select and textarea was bounded only by a hairline in the decorative --line token at 1.32:1, and a field's border is the visual boundary of the control. Form fields now use a dedicated token measuring 3.22:1 in light and 3.31:1 in dark. --line itself was deliberately left unchanged, as it is used only for decorative card and section rules, which the criterion does not govern. The focus indicator is a two-pixel accent outline measuring 5.45:1 in light and 7.36:1 in dark against the page, and 5.70:1 and 7.04:1 against card surfaces. |
| 1.4.12 Text Spacing (Level AA 2.1 and 2.2) | Supports | A failure was corrected during remediation. Applying the criterion's metrics — line height 1.5, letter spacing 0.12em, word spacing 0.16em, paragraph spacing 2em — grew one homepage slide from 900 to 955 pixels inside a fixed-height container with overflow: hidden, cutting 55 pixels of content away with no means of reaching it. The deck only re-evaluated whether a slide needed internal scrolling on load and on window resize, neither of which fires when a user applies their own text styles. A ResizeObserver now re-evaluates whenever a slide's content changes height, which also covers a late-loading webfont and browser zoom. Re-verified with the same metrics: the affected slide becomes internally scrollable and all content is reachable. |
| 1.4.13 Content on Hover or Focus (Level AA 2.1 and 2.2) | Supports | The site has one instance of additional content on hover: a tooltip on the floating scroll button. A failure was corrected during remediation — it satisfied Persistent but neither Dismissable (Escape had no effect) nor Hoverable (pointer-events: none put it beyond the pointer's reach, which matters to a magnification user). It also overlapped hero text, so the "does not obscure other content" exemption did not apply. The tooltip now accepts pointer events, and because it is a descendant of the button, hovering it keeps the button hovered and the tooltip visible; Escape dismisses it without moving pointer or focus. All three requirements verified. |
| 2.4.5 Multiple Ways (Level AA) | Supports | More than one way exists to locate each page: a persistent header navigation present on every route, a footer link set repeating the main destinations, a blog index listing all articles, a table of contents within each documentation page, and contextual links between product pages and their documentation. |
| 2.4.6 Headings and Labels (Level AA) | Supports | Headings describe the section they introduce and labels describe the field they name. No generic "Section" or "Field" text is used. Where a section's visual heading was previously a styled span, it is now a real heading with the same rendering. |
| 2.4.7 Focus Visible (Level AA) | Supports | Two changes during remediation. The keyboard indicator is now an explicit two-pixel accent outline with a two-pixel offset applied on :focus-visible, rather than relying on the user agent default, because the default is not guaranteed to hold contrast against a translucent glass card over a moving WebGL background; being :focus-visible, it does not appear for pointer users. More seriously, focus was previously placed on content rendered at opacity: 0 at 18 of 35 homepage tab stops — an indicator cannot be visible if the control it surrounds is not painted. After remediation a 36-stop traversal records zero unpainted stops. |
| 2.4.11 Focus Not Obscured (Minimum) (Level AA 2.2 only) | Supports | A failure was corrected during remediation. The header is fixed at 64 pixels and the document declared no scroll-padding-top, so a control focused after an anchor jump came to rest entirely behind it — 40 controls across the evaluated routes did so, 30 of them on the documentation page. A single scroll-padding-top: 5rem on the root element resolves it for every scroll container. Re-measured against the production site with a hit test at the focused control's edges: 0 controls obscured. |
| 2.5.7 Dragging Movements (Level AA 2.2 only) | Not Applicable | No functionality requires a dragging movement. There are no draggable elements, no drag-and-drop, no sliders and no reorderable lists. |
| 2.5.8 Target Size (Minimum) (Level AA 2.2 only) | Supports | No target fails, across 158 targets on the evaluated routes. 23 targets are smaller than 24 by 24 CSS pixels — the header navigation links at 69×17 and the constellation navigator dots at 12×12 — and each satisfies an exception: no other target's centre lies within 24 pixels of theirs, and the remainder are inline within a line of text. This was measured by computing 24-pixel circle intersection between target centres. A size-threshold check alone reported 21 failures on this site, none of which is a genuine failure. |
| 3.1.2 Language of Parts (Level AA) | Supports | A failure was corrected during remediation. The studio's name in Devanagari script, नक्षत्र, appeared in nine places across the site — in prose on the About page and in the footer line of eight routes — inside content declared as English, so a screen reader pronounced it with English rules. Each run is now wrapped in <span lang="hi">. |
| 3.2.3 Consistent Navigation (Level AA) | Supports | The header navigation contains the same items in the same relative order on all 17 routes. Items are progressively hidden at narrow widths but their relative order never changes. |
| 3.2.4 Consistent Identification (Level AA) | Supports | Components with the same function are named identically everywhere they appear: the theme toggle is "Toggle color theme" and the background control is "Background motion" on every route, and the return links follow a single "← back to …" pattern. |
| 3.3.3 Error Suggestion (Level AA) | Supports | Where an input error is detected and a correction is known, a suggestion is provided in text: the user agent's constraint validation names the field and describes what is required, including the expected form of an email address. Submission failures suggest the corrective action ("Please try again in a moment"). Dependency: as with 3.3.1, field-level suggestions come from the browser's native validation rather than from custom scripting, so this relies on a user agent implementing HTML constraint validation. Providing custom, field-level, inline error messaging would be an improvement over relying on the user agent, and is recorded here as a known enhancement rather than a defect. |
| 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) | Not Applicable | The site creates no legal commitments, initiates no financial transactions, allows no modification or deletion of user-controllable data, and submits no test responses. Its two forms send a message to the site's owner. |
| 3.3.8 Accessible Authentication (Minimum) (Level AA 2.2 only) | Supports | The only authentication path is "Sign in with Google". No cognitive function test — no password to recall, no puzzle, no transcription — is presented by this site, and nothing must be memorised or transcribed to sign in. Scope note: the credential entry itself takes place on Google's own domain and is outside this evaluation and outside naxatar's control. |
| 4.1.3 Status Messages (Level AA 2.1 and 2.2) | Supports | A failure was corrected during remediation. One live region existed on the entire site; the contact form's success and failure messages, the sign-in error, and the account page's loading-to-signed-in transition all changed silently, so a screen reader user submitting the contact form received no indication of the outcome. Status messages now use role="status" and errors that block progress use role="alert", on seven regions across five routes. Each region is present in the DOM from first paint, because a live region created at the moment its content appears is not reliably announced. The same five regions are exposed in Chromium, WebKit and Gecko. Limitation: announcement was spot-checked with VoiceOver on macOS only; NVDA and JAWS were not tested, and live-region announcement is the criterion where screen readers differ most. |
Legal Disclaimer
This report describes the naxatar.com website as built at commit 415f899, dated August 2026, and reflects the evaluation methods and scope stated above. It is a self-assessment by the site's developer rather than an independent third-party audit. The site is under active development; conformance claims apply to the build identified and to the routes named under Scope of Evaluation. Corrections and questions are welcome at [email protected] and will be reflected in a dated revision of this report.
VPAT® is a registered service mark of the Information Technology Industry Council (ITI).
✦ Companion documents: the audit & remediation record · the accessibility statement