Navigator Mega Menu: accessibility audit

This page reports only what was measured, with links to the evidence. Most results come from the local test harness: the module's HubL rendered by Jinjava 2.7.4 into static pages, tested in Google Chrome with Playwright. A screen reader pass with Orca and Chrome ran on the live demo page. Everything not yet tested is listed under "Not yet tested".

Target: WCAG 2.2 level AA. This is a target, not a certification. Automated checks and scripted tests do not catch every issue.

Summary of results (local harness, Chrome)

Check	Result	How it was checked
Automated scan (axe-core, WCAG 2.0 to 2.2 A and AA plus best practice)	0 violations in 95 scans (closed, every panel open, tabs, More, search, language, drawer, drill-down, accordion, transparent header)	automated axe scans in the test suite
Text contrast, all four presets	Clean Light, Dark and Brand Accent (solid bar): every pair at least 6.7:1 (needs 4.5:1), Oct 19 2026 on main da51070. Frosted layers (the Frosted Glass preset and Header background style Frosted on every preset), measured on rendered pixels over pure black and over pure white page content as the worst case, at rest, hover, focus and with a panel open: text at least 4.61:1 at 1440 and 390 (Brand Accent with theme color #0f766e 4.68:1), enforced by the M4 test "frosted worst-case contrast on rendered pixels"	contrast measured on rendered pages
Focus ring against what is behind it, Oct 19 2026	Measured with each control focused, in the bar, utility row, skip link and the search and language dropdowns at 1440 and in the open drawer at 390 (JavaScript on and off), enforced by the M4 test "focus ring against its background". Lowest per preset: Clean Light 6.09:1, Dark 9.9:1, Brand Accent 6.7:1 (5.47:1 with theme color #0f766e), Frosted Glass and Clean Light + Frosted 3.96:1 over black page content (needs 3:1). Correction: the earlier "at least 6.7:1" claim was wrong. On main before this fix, Brand Accent's top-level ring was the panel blue on the blue bar (1.00:1; 1.22:1 with a teal theme color), and its drawer buttons had a white ring on the white drawer	focus ring contrast measured on rendered pages
Transparent header over a dark hero	10.35:1	contrast measured on a rendered page
Primary button text on any theme color	at least 4.58:1 by design (white or black picked); 4.62:1 worst over 67 sampled colors	automated colour sampling test
Keyboard: full Tab pass with every panel opened	focus never lost, hidden, off screen or covered (four demo sites)	tested with keyboard only
Mobile menu dialog	focus moves in, Tab stays inside, Escape closes, focus returns to the menu button	automated browser test
Touch targets in the mobile menu	none under 44 by 44 pixels at 390 and 768 wide	target sizes measured in the browser
Reduced motion	animations and transitions become instant	tested with reduced motion turned on
Screen reader (Orca 48.1 with Chrome, live demo, Oct 19 2026)	No blockers. Three should-fix findings (page behind the open drawer still readable, drill-down Back button named only "Back", no-JS triggers announced as collapsed) were fixed in PR #37; the Back button now reads "Back to main menu"	manual screen reader pass and retest
Retest of PR #38 findings on main (4bf04f0), Oct 21 2026	Fixed: the drill-down level now reads in Orca, and the touch tap issue on the menu button did not recur (3 of 3 taps)	manual retest
Without JavaScript	every menu link is in the page and reachable by keyboard	tested with JavaScript turned off
Layout shift (CLS)	0 on all four demo sites, at every mobile breakpoint choice, and with the page streamed in two parts	layout shift measured in the browser
Response to opening a panel (lab INP proxy, 4x slower CPU)	Rule: each demo site loads 5 times and the median of the 5 worst panel-open times must stay under 100 ms (INP "good" is under 200 ms). Local, Oct 19 2026 on main da51070: medians 16 to 24 ms, worst single run 48 ms. CI (GitHub-hosted runner), 8 runs from #11 (49b4390) to #13 (ddafa0f): medians 16 to 96 ms, highest on Kettle (Frosted Glass, 32 to 96 ms), single runs up to 152 ms. One CI run failed with a Kettle median of 104 ms and passed when re-run, and before the median rule single runs failed at 104, 136 and 184 ms. Kettle on CI does not yet clear 100 ms with margin	timed in the browser, locally and in CI

How the menu works for assistive technology

One <nav> landmark with a name you choose (Main by default). There are no role="menu" or menuitem roles: the header follows the WAI-ARIA Authoring Practices disclosure navigation pattern, which screen readers announce as ordinary links and buttons.
Each top-level item with a panel is a <button> with aria-expanded and aria-controls. A top-level item that has its own page keeps that page as the first link in its panel (Overview).
Only one panel is open at a time. Escape closes it and returns focus to its button. Pressing outside, or moving focus out of the item, closes it.
Arrow keys: Left and Right move across the top items, Down opens a panel and moves into it, Up and Down move through its links, Home and End jump to the first and last item. Tabbed panels use arrow keys between tabs.
Hover opening is optional, mouse only, with a delay. Click, keyboard and touch work the same way.
A hover-opened panel stays open while keyboard focus is inside it. Moving focus to another item with Tab closes it, even if the pointer is still resting on its button.
Resizing across the mobile breakpoint while focus is in a panel or the drawer moves focus to the control that now opens it (the menu button on mobile, the first top item on desktop), not to the page.
With two menus on one page, the menu with an open panel stacks above the other, and a panel holding keyboard focus stays above a hover-opened panel of the other menu.
Below the mobile breakpoint the menu is a modal dialog (role="dialog", aria-modal="true", named). Focus moves to the close button, stays inside while open, and returns to the menu button on close. Page scrolling is locked while it is open.
A Skip to content link is the first focusable element (on by default, target configurable).
The link to the current page carries aria-current="page". The top-level item for the section the visitor is in gets an underline bar as well as a color change, unless the editor turns underlines off.
The language switcher lists only languages the page is translated into, each in its own language.
All panels are in the page source, so the full navigation works without JavaScript and is readable by search engines.
No icon font: icons are inline SVG with aria-hidden="true", because every link and button already has a text name. The module's files contain no outside URLs (checked on every build by an automated rule); a browser request log on live pages has not been run yet.

What editors control, and how the module protects contrast

Presets were checked for contrast in every state listed above. Frosted layers are checked against the worst page content that can sit behind them (pure black and pure white) by an automated test, so a see-through bar cannot drop below 4.5:1 with the default colors.
Any color an editor changes overrides that one color. The module cannot stop an editor choosing low-contrast colors, so the guide asks editors to keep text at 4.5:1. The one automatic safeguard is the primary button: if the editor sets only its background, the text is white or black, whichever contrasts more.
Reduced motion is always respected, whatever animation the editor picks.

Not yet tested

Screen readers other than Orca: NVDA with Firefox, JAWS with Chrome, VoiceOver on macOS and iOS, TalkBack on Android.
Browsers other than Chrome: Firefox, Safari, Edge, iOS Safari, Android Chrome.
Real devices and 200% and 400% zoom.
Live HubSpot pages: automated scans and Lighthouse on published test portal pages.
Windows high contrast (forced colors) mode.

Known limitations

On a menu with too many top items for one line, items move into a More button once the script runs. The header does not shift while this happens (CLS 0 on the 16-item demo at 390 and 1440 pixels, measured in the browser).
Lab timings come from a local page, not field data from real visitors.
On a slow shared CI machine, opening a panel on the Frosted Glass demo takes up to 96 ms (median of 5), close to the 100 ms target. Locally it is 24 ms. The frosted blur is the likely cost: with the blur turned off as an experiment, the Kettle demo's local time dropped by about 8 ms (QA measurement, Oct 19 2026). The blur is a design choice and is unchanged.
While the page is still arriving, the menu and the utility row each stay invisible until their end marker is parsed, then appear in place. If the marker never arrives, the menu appears after 2 seconds (after 8 seconds if the page stops partway through the menu's links, and then also 8 seconds after opening the mobile menu); a site-wide reduced-motion rule that sets animation: none !important cancels that fallback.

Reporting a problem

Email info@allgusto.com with the page address, browser and assistive technology. Accessibility reports get priority.

Last updated: October 21, 2026.