ACCESSIBILITY

Focus on What’s Important

It requires focus, semantics, and context working together.

Press the Tab key on a large corporate site and focus may move through dozens of footer links: Company, Products, Industries, Resources, Investors, Careers, Support, Legal, Privacy, social media.

Now remove the browser’s focus indicator. The keyboard is still moving through the page, and the links are still technically focusable, but the person using them has lost an important piece of information.

Where are you?

Sometimes the page scrolls a little as focus moves. Sometimes nothing appears to happen. Either way, passing focus from one link to the next is not enough to make the experience understandable.

Keyboard accessibility depends on people being able to tell where focus is, understand what they have reached, and make a reasonable prediction about what comes next. A focus ring is part of that, but so are semantics, document order, and context.

Focus Is Personal

Developers often talk about focus as a visual treatment: an outline, border, box-shadow, or a rule attached to :focus-visible. That treatment matters because a sighted keyboard user needs to know which control will respond to their next key press.

I find it more useful to think of focus as the person’s current position in the interactive experience. A mouse pointer gives someone a persistent spatial reference. With a keyboard, that position moves sequentially from one interactive element to another.

Where am I now?

A visible focus indicator answers that question. Without it, even a well-organized interface can become difficult to follow.

Take the footer again. Headings, columns, spacing, and typography can make its structure obvious to someone scanning the whole page. A keyboard user encounters those destinations one at a time. If focus is invisible, the grouping is still there, but their position inside it is much harder to track.

Focus Is a State

A common way to create focus problems is to start managing the order before the browser needs our help. HTML already gives native links, buttons, inputs, and selects a sensible place in sequential keyboard navigation, usually following the document order.

That default is useful. It lets the DOM carry both structural reading order and a predictable interaction sequence. tabindexcan change that behavior, but it is not a numbering system for every control on the page.

What tabindex actually changes

tabindex influences whether and how an element participates in keyboard focus. In day-to-day product work, the values I pay attention to most are 0, -1, and positive numbers.

tabindex="0": join the normal flow

A value of 0 puts an element into the normal Tab sequence at the point where it appears in the document. It does not mean “put this first.”

There are legitimate uses for it in custom interaction patterns, but native interactive elements usually do not need it. These elements already participate in keyboard navigation:

<a href="/about">About</a>
<button type="button">Save</button>
<input type="text">
<select>
<option>One</option>
</select>

Adding tabindex="0" to those controls does not make them more accessible; it repeats behavior they already have.

The same value on a non-interactive <div> only makes the <div> focusable. It does not give it the meaning or behavior of a real control.

tabindex="-1": a destination, not a stop

A value of -1 keeps an element out of the normal Tab sequence while still allowing JavaScript to move focus to it. That makes it useful for deliberate destinations.

An error summary is a common example. Someone submits a form near the bottom of the page and validation errors appear above it. Leaving focus on Submit may leave the new information out of their path. Moving focus to the summary can give them a clear place to start reviewing the errors.

Dialogs have a similar context change. Opening one generally moves focus into the dialog; closing it usually returns focus to the control that opened it. Those moves support the interaction rather than simply reacting to something changing on screen.

Positive tabindex: creating a second document order

Positive values let us explicitly reorder keyboard navigation:

tabindex="1"
tabindex="2"
tabindex="3"

The problem is maintenance. Add a link near the top, reveal conditional content, change a responsive layout, or let another engineer add a control without knowing about the numbering scheme, and the manual order can drift away from the document.

At that point the application has two representations of sequence to keep synchronized. If the focus order feels wrong, I would rather inspect the DOM and fix the structure than layer a second navigation order on top of it.

Focus Is Orientation

Focus has a flow. As people move through an interface, they build a rough mental model of what came before and what they expect to reach next.

That model can break in several ways. CSS can visually reorder content without changing the DOM. Positive tabindex can create a different keyboard sequence. JavaScript can move focus unexpectedly. A dialog can open while focus remains behind the overlay, or close and leave focus at the top of the document. A validation message can appear somewhere the person never encounters.

The implementation details differ, but the experience is similar: the person has to work out where they are again.

Focus Is Context

JavaScript makes moving focus easy:

element.focus();

Deciding when to call it takes more judgment. The rule I use is to move focus when the person’s interaction context has changed enough that leaving focus where it is would make the new state difficult to understand or operate.

Dialogs and failed form submissions can meet that bar. A client-side route transition may as well, depending on how the new view is presented. A notification appearing, a validation hint changing, or a region expanding usually does not mean focus should automatically jump there.

Focus is not a notification system.

Moving focus changes where the next keyboard action will happen, so it should be connected to the interaction rather than used simply to draw attention.

Links need context

Keyboard focus is only one way people navigate links. Screen reader users may move by headings, landmarks, form controls, or a list of links without reading every surrounding sentence first.

That makes vague link text obvious very quickly:

Click here
Learn more
Learn more
Read more
Click here
Learn more

In the full visual page, each link may appear understandable because a nearby sentence supplies the missing meaning. Pull the links out of that context and “Learn more” no longer says what the destination is about.

Compare that with:

Accessibility approach
Annual sustainability report
Engineering careers
Investor relations
Privacy policy

Those names remain useful in more than one navigation context. The anchor itself still matters, but so does the language that gives its destination meaning.

Structure carries context too

Consider that large footer as a generic container:

<div>
<a href="/about">About</a>
<a href="/careers">Careers</a>
<a href="/investors">Investors</a>
<a href="/support">Support</a>
<a href="/privacy">Privacy</a>
</div>

The links work, but the markup does not communicate the grouping we can probably see in the design. Some links belong to company information, some to support, and some to legal content.

Headings can name those groups. Lists can express collections. Navigation landmarks can identify sets of navigation links. The visual layout may represent the same relationships with columns, spacing, borders, or typography.

That parallel matters because people do not all traverse a page in the same way. A sighted person may scan spatially, a keyboard user may move through each interactive element, and a screen reader user may jump among headings, landmarks, or links. Good semantics help those different views describe the same document.

Native elements already carry behavior

Choosing the native element gives us useful behavior for free:

<a href="/writing">Writing</a>

That anchor has link semantics, participates in keyboard navigation, exposes its role to assistive technology, and supports familiar browser activation and navigation behavior.

Compare it with:

<div tabindex="0">Writing</div>

The <div> is now focusable, but it still is not a link.

We would have to rebuild the meaning and behavior the anchor already provided. This comes up often in accessibility work: JavaScript, ARIA, and tabindex get used to recreate behavior that a native element already knows how to handle.

The simplest accessible implementation is often the one that interferes with the browser the least.

Different layers answer different questions

No single accessibility technique carries the whole experience. A meaningful link name does not replace visible focus, and a focus ring does not explain where a link goes. Document order and semantic grouping solve different problems too.

For a sighted keyboard user: Where am I? Visible focus helps answer that.
For someone navigating through a list of links: What does this destination mean? Good link text helps answer that.
For someone exploring the structure of the page: What part of the document am I in? Headings, lists, landmarks, and other semantics help answer that.
For anyone moving sequentially: Where will I go next? A sensible document and focus order help answer that.

I find accessibility easier to reason about when each layer has a clear job instead of expecting one technique to compensate for the others.

Focus can exist and still disappear

A focus indicator can exist in the DOM and still be useless to the person navigating the page. A sticky header can cover the focused control. A cookie banner or fixed footer can obscure it. An outline can render with too little contrast against its surroundings.

From the browser’s perspective, focus never went away. From the person’s perspective, their location did.

This is why focus belongs in layout and interaction design, not just in a late CSS pass. Sticky surfaces, scrolling, responsive reflow, and the focus treatment itself all affect whether someone can actually see where they are.

Orientation is the larger goal

Accessibility reviews often show up as a list of individual requirements:

add alt text
label the input
show a focus ring
don't use positive tabindex
use descriptive links
add landmarks

Those checks are useful, but I get more value from connecting them back to the problem they are trying to solve. For interaction design, a lot of that comes down to orientation.

Can I tell where I am?
Can I understand what I have reached?
Can I understand the structure around me?
Can I predict what will happen when I interact?
If the interface changes, can I understand where I ended up?

Focus, semantics, and context all contribute to those answers. Treating them together gives us a more useful picture than checking each one in isolation.

Focus Is Intentional

My default is to start with the platform: use the correct HTML, keep the DOM in a sensible reading and interaction order, give groups real structure, give links useful names, and make focus visible.

Then I add focus management where the interaction actually calls for it. tabindex="0" can bring a legitimate custom control into the normal sequence. tabindex="-1"can make something a programmatic focus destination without adding another Tab stop. Positive values are usually a sign that the underlying structure deserves another look.

Browser defaults are not perfect, but they are often a better starting point than a custom interaction model we have to rebuild and maintain ourselves.

Keep the experience in focus

The visible ring is the easiest part of focus to point at, but the larger job is helping someone keep their place as they move through an interface. Semantics explain what they have reached; context explains where it sits in the document; focus connects one interaction to the next.

In the forty-link footer, those pieces work together when a person can see which link has focus, understand the destination from its name, and recognize the group it belongs to.

This is also where accessibility crosses implementation boundaries. Document order may come from HTML, the indicator from CSS, programmatic focus from JavaScript, and the interaction model from design. Tests can verify parts of each one.

The useful review question is whether those artifacts still describe the same experience once they are assembled in the product.