Accessible navigation is the backbone of any website that works for every user, regardless of ability. Whether you’re building a new site or auditing an existing one, getting navigation right from the start is faster and cheaper than retrofitting it later. Under UK and Irish law, it isn’t optional.

For businesses across Northern Ireland, Ireland, and the UK, the Equality Act 2010 and the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 place clear legal obligations on website owners. This guide covers the technical and practical steps to meet WCAG 2.2 standards: from semantic HTML foundations through to keyboard logic, mobile touch targets, and the cognitive load considerations that most technical guides overlook entirely.

Why Accessible Navigation Matters for UK and Irish Businesses

Poor navigation doesn’t just frustrate users. It excludes them. Around 1 in 5 people in the UK live with a disability, and many rely on assistive technologies — screen readers, switch controls, or keyboard-only navigation — to use the web. When your navigation fails them, they leave, and they don’t come back.

The Legal Framework You Need to Know

The Equality Act 2010 requires UK businesses to make “reasonable adjustments” so disabled users can access services, including websites. The Public Sector Bodies Accessibility Regulations 2018 extend stricter obligations to government, NHS, and education websites, requiring WCAG 2.1 AA compliance as a minimum. Private sector organisations face risk through the Equality Act, where an inaccessible design causes demonstrable exclusion.

In Ireland, the European Union (Accessibility of Websites and Mobile Applications of Public Sector Bodies) Regulations 2020 implement equivalent requirements. WCAG 2.2, published in October 2023, is now the current international standard and introduces additional success criteria around mobile navigation, visible focus indicators, and dragging-based interactions.

The risk isn’t theoretical. UK regulators have issued enforcement notices, and litigation around digital accessibility has increased steadily since 2020. For any Belfast or Dublin business managing a public-facing website, accessible navigation is a compliance requirement, not a best practice.

The Real Impact on Users

A keyboard user navigating a site with no skip link must tab through every menu item on every page before reaching the main content. A screen reader user hitting a <div> styled as a button — with no role, no label, and no keyboard event — gets nothing. A person with low vision on a high-contrast display loses their place entirely if focus states disappear into the background.

These are not edge cases. They describe the daily experience of millions of users, and they represent direct losses in traffic, conversion, and brand trust for your business.

Building the Semantic Foundation

Before any ARIA attribute or JavaScript, the structural HTML must be correct. The majority of accessible navigation failures stem from skipping this foundation entirely.

The <nav> Element

Wrap your primary navigation in a <nav> element. This carries an implicit ARIA landmark role of “navigation”, which tells screen readers this is a region they can jump to directly. If you have more than one <nav> on a page — primary menu, breadcrumbs, footer links — add a distinct aria-label to each:

<nav aria-label="Primary navigation">...</nav>
<nav aria-label="Breadcrumb">...</nav>

Without labels, a screen reader user who navigates by landmarks will encounter two regions, both announced as “navigation”, with no way to distinguish them.

Why <ul> Elements Matter

Navigation links should use an unordered list structure. Screen readers announce lists with a count (“list, 6 items”), which gives users a mental map of the menu before they start tabbing. A group of <a> tags inside <div> Elements provide no such context.

One common mistake is adding role="menu" to a standard navigation list. The ARIA menu role is designed for application menus (like a desktop File menu) and carries specific keyboard expectations: arrow key navigation, Escape to close. For a standard website navigation, a list of links with no ARIA menu role is more accessible, not less. Our broader ARIA accessibility guide{target=”_blank”} covers this distinction in detail.

Approach	When to Use	Risk
Native <button> + <ul>	Standard navigation menus	Low: works without JS
aria-expanded toggle	Dropdown / hamburger menus	Low: well-supported
role="menu"	Application menus only	High: requires full arrow-key implementation
Overlay plugins	Never	Dropdown/hamburger menus

Essential WCAG 2.2 Navigation Requirements

WCAG 2.2 introduced several success criteria that directly affect how navigation must be built and tested. Most competitor guides stop at WCAG 2.1. Getting these right is where you separate a compliant site from one that merely looks accessible.

Focus Appearance (2.4.11)

WCAG 2.2 tightened the requirements for visible focus indicators. The focus outline must have a contrast ratio of at least 3:1 against adjacent colours, and a minimum enclosed area equal to the perimeter of the unfocused component. Removing outline: none from your CSS without a visible replacement is a WCAG failure — and it’s one of the most common accessibility errors in professionally built sites.

Target Size (2.5.8)

WCAG 2.2 sets a minimum touch target size of 24×24 CSS pixels for interactive elements, with the W3C recommending 44×44 pixels as best practice. For mobile navigation links, this means sufficient padding around each item, not just the text itself. Test on real devices: what looks correct in browser DevTools doesn’t always translate to a genuine touch experience.

Element	WCAG 2.2 Minimum	W3C Recommended
Navigation links	24×24 CSS px	44×44 CSS px
Toggle buttons (hamburger)	24×24 CSS px	44×44 CSS px
Icon-only controls	24×24 CSS px	44×44 CSS px

Consistent Navigation (3.2.3)

Navigation must appear in the same relative order on every page of the site. If your primary menu changes position or order between pages, you fail this criterion. This sounds obvious, but it’s frequently broken by page templates that reorder elements for “design variety.”

Implementing Keyboard-Only Navigation

WCAG 2.1 Success Criterion 2.1.1 requires that all functionality is operable by keyboard alone. For navigation, this means three interconnected things.

Managing Tab Order and Visible Focus

The tab order must follow the visual and logical flow of the page: the skip link first, then the logo or home link, then the main navigation, then the page content. Never use tabindex values above 0 to force an order. This creates unpredictable behaviour and breaks the natural DOM flow for users who rely on it.

Visible focus indicators are required under WCAG 2.2 Success Criterion 2.4.11. Test your navigation by unplugging your mouse and tabbing through every interactive element. If you lose track of where you are at any point, your focus state fails.

The Skip to Main Content Link

A skip link is a visually hidden anchor that becomes visible on focus, allowing keyboard users to jump past the navigation to the main content. It must be the first focusable element on the page, and it must actually work — clicking it should move keyboard focus to the <main> element, not just scroll the viewport.

<a href="#main-content" class="skip-link">Skip to main content</a>

This satisfies WCAG 2.4.1 (Bypass Blocks). Without it, a keyboard user must tab through every navigation element on every page load, every time. It’s a ten-minute fix that most sites still haven’t made.

Advanced ARIA Patterns for Complex Menus

For dropdown menus and toggle navigation, ARIA attributes communicate state to assistive technologies. The principle is to use only what’s necessary.

Toggle Buttons and aria-expanded

A hamburger menu or dropdown trigger must be a <button> element, not a <div> or <span>. Buttons receive keyboard focus natively, fire on both Enter and Space, and announce their role to screen readers without additional code.

Add aria-expanded to communicate the open/closed state:

<button aria-expanded="false" aria-controls="nav-menu">Menu</button>
<ul id="nav-menu">...</ul>

When the menu opens, toggle aria-expanded to "true" via JavaScript. The screen reader announces the change in state without any further intervention.

Using aria-controls Correctly

aria-controls creates a programmatic relationship between the trigger and the content it controls. It takes the id form of the controlled element. Not all screen readers implement aria-controls consistently, so they should supplement clear visual and logical relationships, not replace them.

The Escape key must close any open menu and return focus to the trigger button. Users who open a dropdown by mistake need a reliable way out. This is a keyboard interaction that’s frequently forgotten in JavaScript implementations.

Responsive Design: Accessible Mobile Navigation

Mobile navigation introduces challenges that code-only guides frequently miss.

Is the Hamburger Menu Accessible?

Yes, if implemented correctly. The toggle button must be a native <button>, labelled clearly with either visible text or aria-label="Open menu", and must manage focus. When the menu opens, focus should move to the first menu item. When it closes, focus must return to the toggle button. Without this focus management, keyboard and screen reader users are stranded.

Focus Traps in Overlay Menus

When a full-screen overlay navigation opens, focus must be trapped inside it. A screen reader user who can tab outside the menu into hidden page content is lost. JavaScript must cycle focus between the first and last focusable elements within the open overlay, and Escape must dismiss it.

Ciaran Connolly, founder of ProfileTree, puts it plainly: “Most of the accessible navigation failures we see during audits are not complex ARIA problems. They’re missing skip links, invisible focus states, and hamburger menus that don’t work with a keyboard. These are quick fixes that make a real difference.”

Beyond Screen Readers: Cognitive Load and Voice Control

Most accessibility guidance focuses on blindness and screen reader users. Two equally significant groups are frequently overlooked: people with cognitive disabilities and users of voice control software.

Reducing Cognitive Load in Navigation

For neurodivergent users — including those with ADHD, dyslexia, or anxiety — navigation complexity is a barrier in itself. “How many links is too many?” is a genuine question. Research broadly supports limiting top-level navigation items to five to seven choices, with clear grouping and predictable labelling.

Avoid hover-only interactions that require sustained cursor precision. Use clear, literal link labels rather than creative or metaphorical ones. A link that says “Our Story” is harder to parse quickly than one that says “About ProfileTree.” For users with cognitive disabilities, literal beats clever every time.

Voice Control and Accessible Names

Voice control users (for example, those using Dragon Professional) navigate by speaking the visible text of links and buttons. If a button is labelled visually with an icon and has a label aria-label that doesn’t match the visible text, the user can’t activate it by voice. WCAG 2.5.3 (Label in Name) requires that the aria-label accessible name include the visible label text. This applies to every navigation element.

For web development services{target=”_blank”} that serve regulated industries — healthcare, legal, financial services — this is particularly relevant. Staff using voice control due to motor impairments need the same frictionless access to your web tools as any other user.

UK and Ireland Legal Compliance Framework

The legal landscape for web accessibility in the UK and Ireland is specific, and generic US-centric guidance (which focuses on Section 508) doesn’t translate directly.

UK Requirements

The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require public sector websites — government, NHS, higher education — to meet WCAG 2.1 AA as a minimum. Accessibility statements are mandatory. The Equality Act 2010 extends obligations to private sector organisations: failing to make “reasonable adjustments” for disabled users can result in civil claims.

Irish Requirements

The European Union (Accessibility of Websites and Mobile Applications of Public Sector Bodies) Regulations 2020 implement the European Accessibility Act requirements in Ireland. Public sector organisations must publish an accessibility statement and provide a feedback mechanism for users who encounter barriers.

For private sector businesses in both jurisdictions, the direction of travel is clear: accessibility requirements are expanding, not contracting. Businesses that build accessibility into their web design process now avoid the cost of retrofitting it later. ProfileTree’s approach to web design for UK and Irish businesses{target=”_blank”} treats accessibility as a structural requirement, not an afterthought.

Testing and Auditing Your Navigation

No accessible navigation implementation is complete without testing. Three layers are required.

Automated Testing

Tools like WAVE, Axe, and Lighthouse catch roughly 30–40% of accessibility issues: colour contrast failures, missing labels, and invalid ARIA. They cannot test keyboard interaction logic, focus management in JavaScript menus, or how navigation is actually announced by screen readers.

Manual Keyboard Testing

Disconnect or disable your mouse and navigate the entire site using Tab, Enter, Space, and arrow keys. Can you reach every link? Is the focus indicator always visible? Can you open and close dropdown menus without a mouse? Can you return focus to the trigger after closing a menu? Test on both desktop and mobile.

Screen Reader Testing

NVDA (Windows, free) and VoiceOver (Mac/iOS, built-in) reveal how navigation is actually announced. Listen for landmark regions, list counts, button states, and skip link behaviour. Pay particular attention to menu state changes — does aria-expanded it update correctly? — and to the order in which elements are announced.

For ProfileTree clients, navigation accessibility is assessed as part of our web design and development process. If you’re auditing an existing site, our technical SEO and site audit services{target=”_blank”} can identify accessibility gaps alongside performance and crawlability issues.

Teams that want to build internal knowledge around accessibility can develop these skills through digital training. Future Business Academy runs practical digital skills programmes for SME teams across Northern Ireland and Ireland.

Beyond the Primary Menu: The Navigation Ecosystem

Accessible navigation extends beyond the primary menu bar. Breadcrumbs, pagination, and footers are all navigation components and must meet the same standards.

Accessible Breadcrumbs

Breadcrumbs must be wrapped in an <nav aria-label="Breadcrumb"> element. The current page should be marked with aria-current="page". The last item — the current page- should not be a link, as the user is already there.

The Footer as Secondary Navigation

A well-structured footer with grouped link categories, marked up as <nav> or <section> With appropriate headings, it gives users a second route through the site. Screen reader users who move between landmarks can jump directly to the footer. Group links under descriptive headings and maintain tab order that follows the visual column structure.

Pagination and Search Accessibility

Pagination controls need aria-label to be on each link (“Go to page 3”, not just “3”). The current page link should carry aria-current="page". Search inputs need visible labels, not placeholder text alone. Placeholder text disappears on input and is not consistently announced by all screen readers. These details matter more than most developers realise: pagination is often where accessibility work stops, and it’s where users with motor or visual impairments experience the most friction.

For developers who want to go deeper on ARIA implementation across these patterns, our guide to using ARIA to enhance accessibility{target=”_blank”} covers roles, states, and properties in detail.

Accessible Navigation in Practice: What ProfileTree Looks For

When ProfileTree audits a website’s navigation as part of a web design or development project, we work through a consistent checklist. The issues that appear most frequently across SME websites are not complex JavaScript problems — they are structural omissions that take hours to fix rather than weeks.

The most common failures: no skip link, focus outlines removed in CSS, hamburger menus built from <div> elements with no keyboard support, dropdown menus that only respond to hover, and footer navigation with no landmark markup. Each of these fails multiple WCAG criteria simultaneously. Each of them is fixable.

If your site was built before 2022, there is a reasonable probability that it fails at least three of the WCAG 2.2 navigation criteria. A proper audit will tell you exactly where.

Our essential skills for web designers{target=”_blank”} article covers how accessibility knowledge fits into the broader skillset expected of modern front-end developers working with UK clients.

If you’re working in a regulated sector — healthcare, legal, financial services — the obligations are more immediate. Our work on accessible and compliant legal website design{target=”_blank”} covers the specific requirements for those environments.

Getting navigation right from the start costs a fraction of what it costs to retrofit. Talk to ProfileTree about what accessible web design looks like for your business.

Frequently Asked Questions