Harbour Lights 2026
\n\n \n \n \n
\nPut your mouse in a drawer and try to buy a Friday pass on Ticketly. You will discover three things in about thirty seconds. Tab takes you through forty-odd header and footer links before reaching the festival. Focus then jumps from the Saturday button to the Friday button and back to the top. And for most of the trip you can’t see where focus is at all, because someone wrote outline: none in 2019 to get rid of “that ugly blue box”.
Keyboard access isn’t a niche. Everyone using a screen reader on a desktop relies on the keyboard, and so do switch users, people with tremor, people whose trackpad broke, and developers who simply prefer it. WCAG 2.1.1 Keyboard (A) requires that everything works from the keyboard, and 2.1.2 (A) that focus never gets trapped.
\nNative elements already support all of this. Your job is mostly not to break it, and to match these conventions when you build custom widgets in Widget Patterns.
\nTab moves through focusable elements in source order. If the visual layout puts the “Add Saturday” button before “Add Friday” but the markup has them the other way round, focus appears to jump backwards. The fix is to put the markup in the order you want people to meet it. Be wary of CSS that rearranges things visually, such as order, flex-direction: row-reverse or explicit grid placement, because focus will still follow the markup (2.4.3 Focus Order).
tabindex adjusts focusability:
| Value | \nEffect | \nUse it for | \n
|---|---|---|
0 | \nFocusable, in DOM order | \nA custom control built from a non-interactive element | \n
-1 | \nFocusable from script only, not with Tab | \nHeadings or containers you move focus to | \n
1 or more | \nJumps ahead of everything else | \nNever | \n
A keyboard user without a visible focus indicator is like a mouse user with an invisible pointer. WCAG 2.4.7 Focus Visible (AA) requires one; 1.4.11 Non-text Contrast means it should have at least 3:1 contrast against what surrounds it.
\nThe modern tool is :focus-visible. Browsers apply it when focus should be shown: always for keyboard navigation and text fields, but usually not when a button is clicked with a mouse. That answers the designer’s real complaint without hurting anyone:
:focus-visible {\n outline: 3px solid #5b3cc4;\n outline-offset: 2px;\n}Use outline rather than box-shadow for the ring. Windows contrast themes (forced colors mode) remove box shadows but keep outlines, so a shadow-only indicator vanishes for the people who most need it.
Ticketly’s header has a logo, ten menu links, a search field and an account menu: thirteen Tab stops. A keyboard user has to tab through all of them on every page. WCAG 2.4.1 Bypass Blocks (A) asks for a way past repeated content, and the classic solution is a skip link: the first focusable element on the page, hidden until it receives focus.
\n<body>\n <a class=\"skip-link\" href=\"#main\">Skip to main content</a>\n <header>…</header>\n <main id=\"main\">…</main>\n</body>.skip-link {\n position: absolute;\n inset-block-start: 8px;\n inset-inline-start: 8px;\n padding: 8px 12px;\n background: #fff;\n transform: translateY(-150%);\n}\n.skip-link:focus {\n transform: none;\n}Don’t hide it with display: none, which would remove it from the tab order. Moving it off-screen and back on focus keeps it reachable and makes it appear exactly when a keyboard user needs it.
Sticky headers and cookie banners bring the opposite problem: focus moves to an element that is hidden underneath them, which fails 2.4.11 Focus Not Obscured (AA). Tell the browser how much of the viewport the sticky parts cover, and it will scroll focused elements clear of them:
\nhtml {\n scroll-padding-block-start: 96px; /* sticky header height plus a little air */\n}For a cookie banner, the real fix is not to let it float over content indefinitely: place it in the flow, or make sure it can be dismissed before anything else is reached.
\n\nTicketly can now be crossed from top to bottom with a keyboard. The next lesson handles the harder cases, where your code has to move focus itself: dialogs and single-page app navigation.
\n","toc":[{"id":"sec-1","text":"The keys people use","level":2},{"id":"sec-2","text":"Focus order follows the DOM","level":2},{"id":"sec-3","text":"Make focus visible","level":2},{"id":"sec-4","text":"Skip links and sticky bars","level":2}],"takeaways":["Focus order follows the DOM order, so put markup in the order people should meet it, and don’t fight it with CSS reordering.","Use tabindex=“0” to add a custom control to the tab order and tabindex=“-1” for elements you focus from script; never use a positive tabindex.","Never remove the focus outline without a replacement; style :focus-visible with an indicator of at least 3:1 contrast.","A skip link as the first focusable element lets keyboard users bypass repeated navigation, and scroll-padding stops sticky bars hiding focus."],"further":[{"title":"MDN: :focus-visible","url":"https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-visible"},{"title":"MDN: tabindex","url":"https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/tabindex"},{"title":"W3C: Understanding 2.4.7 Focus Visible","url":"https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html"},{"title":"W3C APG: Developing a Keyboard Interface","url":"https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/"}],"quiz":[{"q":"In what order does Tab visit these buttons?
\n<button>Friday</button>\n<button tabindex=\"2\">Saturday</button>\n<button tabindex=\"1\">Sunday</button>\n<button>Weekend</button>A designer finds the default focus ring ugly. Which CSS is the best response?
","options":[{"text":":focus-visible { outline: 3px solid var(--brand); outline-offset: 2px; }","why":"Correct. It replaces the default with a strong, on-brand indicator that keyboard users see, while mouse clicks on buttons don’t show it."},{"text":"*:focus { outline: none; }","why":"This removes the indicator for everyone, and keyboard users lose track of where they are. It fails 2.4.7 Focus Visible."},{"text":":focus { outline: 1px dotted #ddd; }","why":"A thin light-grey line on a white page is nearly invisible. Indicators need at least 3:1 contrast against their surroundings."}],"answer":0},{"q":"When should an element get tabindex="-1"?
Ticketly’s sticky header is 80px tall. When a keyboard user tabs backwards up the page, focused links slide underneath it. Which fix addresses 2.4.11 Focus Not Obscured?
","options":[{"text":"Give the headerz-index: -1 when anything is focused","why":"Sending the header behind content would make it overlap visually in strange ways and doesn’t reliably keep focus in view."},{"text":"Add html { scroll-padding-block-start: 96px; } so the browser scrolls focused elements clear of the header","why":"Correct. scroll-padding tells the browser which part of the viewport is covered, so scrolling into view leaves room for the sticky header."},{"text":"Add aria-hidden="true" to the header","why":"aria-hidden only affects assistive technology. The header would still cover the focused link visually, and its links would vanish from the tree."}],"answer":1}],"exercise":{"kind":"web","mode":"dom","starter":{"html":"Three keyboard problems on one small page:
\ntabindex values, so focus order jumps around. Remove them; the DOM order is already right.:focus-visible outline at least 2px wide.href="#main". It may be hidden off-screen, but it must be visible while focused (don’t use display: none).Without positive tabindex values, Tab follows the markup: skip link, logo, menu, then the three passes in the order they appear. The focus rule now adds an indicator instead of removing one, and :focus-visible keeps it from flashing on mouse clicks. The skip link is the first Tab stop; it stays reachable because it is moved off-screen rather than removed, and it slides into view on focus so sighted keyboard users see it too. Pressing Enter on it moves focus to #main, past the header.