Accessible institutional
navigation

Engineering keyboard, focus, and ARIA into Concordia's global header and mega menu

AccessibilityFront-end developmentInformation architecture

Overview

Client

Concordia University, Web Evolution Team

My Role

Accessibility Lead

Team

Michael Cardillo

Accessibility Lead

Andrei Kalamkarov

Front-End Development

Joelle Beauregard

Designer

Chantal Bellemare

Information Architect

Timeline

2024 – 2025

Concordia's global header appears on every main-site page. It includes the mega menu, search, sign-in, language toggle, and quick links — and thousands of pages depend on it.

As part of the Concordia Design System, we redesigned that header to work the same way everywhere: clearer structure, stronger accessibility, and a pattern the main site and subsites could share.

I led accessibility strategy and QA while frontend rebuilt the header. The work focused on visible focus, full keyboard support, and a navigation pattern the main site and subsites could share.

What shipped is a dual-mode system — hover for mouse users, full keyboard parity for everyone else, and a mobile panel with trapped focus — rolled out on the main site, then adopted by subsites in 2025.

Outcomes at a glance Checked with automated tools and manual keyboard / screen reader testing across major browsers and devices.

WCAG 2.2 AA

Keyboard use, visible focus, contrast, bilingual pronunciation, and clear structure — aligned with Quebec accessibility requirements.

Mouse + keyboard parity

Menus open from the keyboard as well as hover. Escape closes them and returns focus — nothing depends on a mouse alone.

Reusable across properties

Main site and subsites share the same navigation behaviour and focus styles — one model instead of one-off fixes.

Problem

A global nav that worked for mouse users only.

An accessibility mini-audit on the previous header surfaced barriers that blocked keyboard and assistive technology users across the entire site:

Keyboard & AT

Mega menu panels were unreachable by keyboard or screen reader.

Semantics & focus

Invalid landmarks, suppressed outlines, and hover-only interaction.

These barriers limited discoverability, created friction for screen reader users, and blocked WCAG 2.2 AA compliance. The header is the first interactive surface on every page — fixing it meant rethinking markup, interaction logic, and QA together, not bolting ARIA onto the old structure. Six systemic issues from the audit:

Mega menu inaccessible to keyboard and assistive technology.

Dropdown panels had no keyboard open/close model and no focus management.

Mega menu inaccessible to keyboard and assistive technology.

Dropdown panels had no keyboard open/close model and no focus management.

Invalid navigation landmarks.

role="navigation" on <ul> elements broke landmark semantics.

Focus indicators suppressed or inconsistent.

Failed WCAG 2.4.11 — focus not visible, especially in Safari.

Hover-only interaction model.

Touch and keyboard users could not reliably open or traverse menus.

Improper ARIA menu patterns.

role="menuitem" on list items without proper list semantics — custom menu roles without the required wrappers.

Contrast gaps on non-text UI.

Dropdown shadows and hover/active states below 3:1 against white backgrounds.

The core tension

The same header had to work for everyone — but it only really worked with a mouse.

People needed to

Use every menu without a mouse
Always see where they were on the page
Hear a clear structure — not decorative noise
Tab through the header in a sensible order

What the header did instead

Menus only opened on hover
Focus was missing or nearly invisible
Screen readers heard “chevron” and broken structure
Keyboard paths fell apart once you left the mouse

One header on every page — mouse users could get around; keyboard and screen reader users could not.

Principle

Build keyboard, focus, and screen-reader support in from the start — don't retrofit accessibility.

Architecture

Accessibility built into how the menu works

We designed accessibility into the interaction model from the start — not as a cleanup pass after the visuals were done. Six decisions drove that approach:

What has to work before any fancy behaviour is added?

Key decisions:

Separate link from dropdown trigger

Opening a menu and visiting a section overview are two different actions — so each gets its own control. Keyboard users never get stuck choosing between them.

Native lists over custom menu roles

Menus use ordinary lists and links. Screen readers announce them the way people expect, without the confusion of custom menu patterns.

Clear group headings

Each column in the mega menu has a real heading, so assistive technology can announce the structure — for example, “Programs” — instead of a wall of undifferentiated links.

A visible focus style everywhere

A consistent burgundy outline shows where you are on the page, including in Safari, on both light and dark header backgrounds.

Quiet decorative icons

Chevrons and arrows are visual only. Screen readers no longer announce them as separate controls.

Correct bilingual pronunciation

French and Indigenous names are marked so screen readers say them correctly — including terms like Otsenhákta, NouLa, and Carrefour.

Implementation

One header, built once, shared everywhere

I led accessibility while working with design and frontend to rebuild the global header as a single shared component. The same navigation powers the main site and, later, subsites — so we weren’t solving the problem one property at a time.

Editors manage mega menu and quick-link content in one place. Empty sections stay hidden. When a menu opens or closes, the interface tells assistive technology what’s happening, so the experience stays in sync for everyone.

From QA to Fixes

From audit failures to
shipped fixes

We combined automated scans with manual keyboard and VoiceOver testing across browsers and devices. Each failure became a concrete fix:

Research finding

Decorative icons were announced as “chevron” — noise that made menus harder to understand.

Design response

Decorative chevrons and arrows are silent to screen readers now. Only the real controls get announced.

Research finding

Custom menu roles broke how lists are usually announced.

Design response

Menus use ordinary lists and links again, so assistive technology can navigate them the familiar way.

Research finding

Column headings were skipped or read as buttons, because mobile and desktop shared the wrong pattern.

Design response

Desktop columns use real headings — for example, “Programs” — so the structure is clear without button chrome.

Research finding

Focus was invisible in Safari on search and header controls.

Design response

A shared focus style with enough offset keeps the outline visible everywhere, and separate from hover.

Research finding

Dropdown shadows were too light against white — below the contrast needed for non-text UI.

Design response

We darkened the shadow under panels so edges stay visible for low-vision users.

Research finding

French and Indigenous labels were mispronounced — FR, Otsenhákta, NouLa, and similar names.

Design response

Language and pronunciation cues now guide screen readers for Birks, eConcordia, NouLa, Otsenhákta, and Carrefour.

Verification

QA across content, UI, and accessibility

Before release we checked links, headings, layout, browsers, and a dedicated accessibility pass. Keyboard navigation, visible focus, colour contrast, zoom, and touch target size all passed after iterative fixes. Toast notifications no longer cover search or mobile panels. Automated scans tracked remaining issues as the patterns settled.

Shipped system

Every main-site page, one accessible shell

Rolled out across all main-site templates, with subsites picking up the same accessible patterns in 2025.

Focus is easy to see again — a high-contrast outline that works on white and burgundy. Menu columns announce their headings to assistive technology. The header stays out of the way when printing, and stays visible while any panel is open.

This header became the model for how Concordia builds complex, accessible UI. Keyboard behaviour, clear focus, and correct bilingual pronunciation aren’t one-off fixes — they’re part of the shared navigation. Subsite teams and future design-system components get the same foundation instead of reinventing it.

Built on

Shared design-system patterns, a single navigation component, and consistent focus styles across the header

Built on

Shared design-system patterns, a single navigation component, and consistent focus styles across the header

Orientation

Skip to main content is first; the main nav is clearly labelled for assistive technology

Keyboard

Open with Enter or Space, close with Escape, and always return focus to where you started — with no traps behind overlays

Testing

Automated scans plus VoiceOver and keyboard passes across major browsers and devices

Keyboard flow

Skip link first, panels that keep orientation

The first Tab lands on Skip to main content, then the menu triggers. Enter or Space opens a panel; Escape closes it and returns focus. Overlays keep you inside until you leave — you never get lost behind them.

Skip link focused

Escape returns focus

Desktop mega menu

Hover when you want it, keyboard when you need it

Menus open on careful hover or from the keyboard. Four columns with clear headings and flat link lists — no nested traps on desktop. Overview links sit at the top of each panel, and targets are large enough for touch.

Mega menu columns

Opened from the keyboard

Mobile offcanvas

One panel, trapped focus

On smaller screens, search, mega menu, quick links, and key actions live in one side panel. Opening it locks the page behind; closing restores focus and scrolling. Sections expand and collapse instead of dumping everything at once.

Collapsed sections

Expanded section

Search & subsites

Same rules, wherever the header appears

Search opens as a full-width overlay and keeps focus inside until you close it. Subsite headers use a tighter look but the same accessible behaviour — including hiding empty navigation branches.

Search overlay

Subsite header

Next steps

Ongoing improvements after launch

After launch we moved overview links to the top of each desktop dropdown, improved bilingual labels, and tightened how subsites track navigation in analytics. Next up: small typography and spacing adjustments so the header aligns more closely with the design system’s tokens. Quantitative before-and-after scores from Siteimprove and Hotjar still need publishing once those tools are renewed.