Wayzi Navigate: find your place, then move through the page.

How can the structure of a page become a useful control?

A header, a search region, the main content and a list of headings describe different ways into the same page. Someone looking for a section may want to search its name. Someone moving repeatedly through a long page may prefer a keyboard shortcut.

Wayzi Navigate brings those routes into one component. It reads the host page's landmarks and headings, groups them, and lets someone choose where to go. The host document remains the source of that structure.

I took this from interaction design into a working TypeScript implementation. The current work centres on the Navigate component. Other ideas in the broader Wayzi project are at different stages and are not required for this component to work.

Find a destination without losing the page.

The panel presents landmarks and headings separately, so people can distinguish a page region from a section within it. Search narrows the list; heading levels help communicate the document's hierarchy.

Keyboard controls support opening the panel, moving through results, choosing a destination and closing it. The component includes announcements and target highlighting to help make a change of location perceptible.

The working demo shown above uses the same component as the source package. Searching for “Heading” narrows the list to matching sections, and Escape closes the panel. These are observable prototype behaviours, with broader testing still needed across browsers and assistive technologies.

<wayzi-navigate
landmarks="main navigation search complementary"
headings="h1, h2, h3"
headings-scope="main"
highlight-target="smooth"
scroll-on-hover="false"
></wayzi-navigate>

These attributes configure the installed component. A content-heavy page can expose a broad outline; another integration can limit the panel to headings in the main content. The component depends on meaningful HTML, including useful headings and named landmarks. It cannot supply structure that the host page does not have.

Let people adjust the tool they are using.

The preferences panel covers colour mode, colours, type size, density, position and navigation behaviour. Keyboard shortcuts have their own settings. Preferences are stored locally so they can be restored on a later visit in the same browser.

Font and density controls are scoped to the component. That distinction matters: changing the navigation panel should not unexpectedly resize the document someone is trying to use.

wayzi-navigate {
--spacing: calc(0.25rem * var(--wayzi-density, 1));
--text-base: calc(1rem * var(--wayzi-font-scale, 1));
}

This excerpt from the stylesheet connects user preferences to CSS variables. The component then uses those values in its own controls. It is a practical connection between a design decision and the implementation that has to respect it.

Make a change of location understandable without seeing it.

For someone using a screen reader such as VoiceOver, an outline around a heading cannot carry the whole interaction. The destination needs a meaningful name, and a change of location needs to be communicated through more than its position on screen.

Wayzi gives navigation items accessible labels that identify their landmark or heading level. A persistent, visually hidden live region receives updates when the menu opens, a result is selected or settings are saved. It is marked as a status region with polite announcements, giving assistive technology an update to present alongside the page's own semantics.

<div
role="status"
aria-live="polite"
aria-atomic="true"
aria-relevant="additions text"
>
Navigated to Heading level 3: CSS Variable Customization
</div>

This shows the region's attributes and the message captured from the working demo. Its visual-hiding styles are omitted for readability. Selecting the search region produced “Navigated to Landmark: Site search”. These are updates emitted by the component, rather than a transcript of VoiceOver speech.

The captures use the option to keep the panel open after navigation. That makes the selected item and destination visible together. It also provides a useful scenario for testing the relationship between focus, visual highlighting and announcements.

The next VoiceOver review needs to check what is actually heard, when it is heard and where keyboard focus continues. Announcement timing when the panel closes, focus after choosing a destination and shortcut conflicts are part of that review. A live-region message alone cannot establish that the complete journey works well with a screen reader.

Direction and contrast belong in the behaviour.

The source includes document-direction detection, language handling and translated interface strings, including Arabic. The intention is to account for reading direction in the component rather than treating it as a cosmetic change added at the end.

That implementation still needs review with native speakers and assistive technology. Direction detection and translated labels are useful foundations; they do not establish that every interaction works equally well in every language.

Colour customisation introduces another responsibility. The component calculates contrast and surfaces warnings against a chosen target. The demo captures show one of those warnings. Making it visible helps someone understand a consequence of the colour configuration, but the check does not assess the whole page or all accessibility requirements.

Working behaviour, with validation still to do.

Wayzi Navigate has a working component, a demo, configurable navigation and saved preferences. It provides concrete material for evaluating the interaction instead of relying only on static screens.

The next step is to test that interaction with people using different navigation methods, then resolve the issues those sessions expose. Focus behaviour, shortcut conflicts, language quality and the amount of control offered by the settings all need that scrutiny.

The project remains in development. The contribution here is the designed and implemented interaction, together with a clear boundary around what has and has not been validated.