ACCESSIBILITY
Focus on What’s Important
It requires focus, semantics, and context working together.
Press the Tab key.
Focus moves to a link.
Press it again.
Another link.
Again.
Another.
Now imagine there are forty links in the footer of a corporate website.
Company. Products. Industries. Resources. Investors. Careers. Support. Legal. Privacy. Social media.
Every one of those links technically receives keyboard focus.
But the browser’s default focus indicator has been removed.
Where are you?
You know the keyboard is doing something. Maybe the page scrolls slightly as you move. Maybe nothing appears to happen at all.
The links are focusable.
The website is not necessarily keyboard accessible.
That distinction matters.
Keyboard accessibility is not successful because every interactive element can receive focus.
It is successful when people can tell where focus is, understand what they have reached, and reasonably predict where they will go next.
That requires more than a ring around a button.
It requires focus, semantics, and context working together.
Focus Is Personal
Developers often think about focus as a visual treatment.
A border.
An outline.
A box-shadow.
Something we add to :focus-visible.
That visible indicator is important. A sighted keyboard user needs to know which control will respond when they press Enter, Space, or another key.
But the visual indicator is only the visible manifestation of something larger.
Focus represents a user's current position in the interactive experience.
When someone navigates with a mouse, their pointer gives them a persistent spatial reference.
They can see the page.
They can see the target.
They move the pointer to it.
Keyboard navigation works differently.
The user moves sequentially through interactive elements.
Tab.
Tab.
Tab.
At each step, focus answers a very simple question:
Where am I now?
Remove the visible indication of focus and you have removed the answer.
This becomes particularly obvious in interfaces with a large number of links.
A footer containing dozens of destinations might look perfectly understandable at a glance. Headings divide the links into columns. Spacing creates groups. Typography establishes hierarchy.
A mouse user sees that structure all at once.
A keyboard user encounters it one interactive element at a time.
If focus is invisible, the visual organization of the footer does very little to help them understand their current position.
The structure still exists.
Their location within it does not.
Focus Is a State
One of the easiest ways to create focus problems is to start managing the focus order before we need to.
HTML already gives us a useful model.
Native interactive elements such as links, buttons, inputs, and selects participate in sequential keyboard navigation naturally.
The order generally follows the document.
That is a feature.
It means the DOM can establish both the structural reading order and a predictable interaction sequence.
Then we discover tabindex.
And sometimes things get weird.
What tabindex actually changes
tabindex is not a way to assign every interactive element a position.
It is a way to influence whether and how an element participates in keyboard focus.
Three kinds of values matter most.
tabindex="0": join the normal flow
A value of 0 places an element into the normal sequential focus order.
Its position is determined by its location in the document.
It does not mean:
Put this first.
It means something closer to:
Let this participate where it naturally occurs.
There are valid reasons to use it, particularly when implementing certain custom interactive patterns.
But native interactive elements usually do not need it.
This already works:
<a href="/about">About</a>
<button type="button">Save</button>
<input type="text">
<select>
<option>One</option>
</select>Adding tabindex="0" to every link and button does not make them more accessible.
They were already keyboard accessible.
And adding tabindex="0" to non-interactive content does not magically give that content meaningful interaction semantics.
A focusable <div> is still a <div>.
tabindex="-1": a destination, not a stop
A value of -1 is more interesting.
The element does not become part of the normal Tab sequence.
But JavaScript can still move focus to it.
That makes tabindex="-1" useful when an application needs to deliberately move someone to a new point of orientation.
Think of it as a destination rather than a stop along the normal route.
For example, a form submission fails and an error summary appears near the top of the page.
The user pressed Submit near the bottom.
Leaving focus on the Submit button may technically be valid, but it may also leave them unaware that something important has appeared somewhere else.
An application might move focus to the error summary so the user immediately encounters the problem and can navigate from there.
A dialog is another example.
Opening the dialog changes the user's interaction context. Focus should move into that context.
When the dialog closes, focus usually needs to return to the control that opened it.
Those are deliberate transitions.
They are very different from moving focus simply because something happened on the screen.
Positive tabindex: creating a second document order
Then there are positive values:
tabindex="1"
tabindex="2"
tabindex="3"These values allow developers to explicitly reorder sequential keyboard navigation.
It sounds useful.
Usually it is a warning sign.
Imagine maintaining a page where every interactive element has been numbered.
Then another link gets added near the top.
Do the other numbers change?
What happens when conditional content appears?
What happens at a responsive breakpoint when the visual layout changes?
What happens when another engineer adds a button without knowing about the numbering system?
The DOM already contained an order.
Positive tabindex creates another one on top of it.
Now the application has two representations of sequence that must remain synchronized.
That is unnecessary complexity with very little upside.
If the focus order feels wrong, the better question is usually not:
What tabindex number should I assign?
It is:
Why is the document structured in the wrong order?
Fix the structure whenever you can.
Do not build a manual navigation system over a broken one.
Focus Is Orientation
This is where focus starts becoming more than a property of individual controls.
It has a flow.
People build a mental model as they move through an interface.
They know roughly what came before them.
They have some expectation about what comes next.
That expectation is easy to destroy.
Visual CSS ordering can make something appear in one place while leaving it somewhere else in the DOM.
Positive tabindex can send keyboard users through a completely different sequence.
JavaScript can unexpectedly move focus.
A dialog can open without taking focus, leaving keyboard interaction behind the visible overlay.
A dialog can close and dump focus at the top of the document.
A validation message can appear somewhere the user never encounters.
Each problem is slightly different.
They all damage orientation.
Focus Is Context
JavaScript gives us the ability to call:
element.focus();The API is easy.
Knowing when to use it is harder.
A useful rule is:
Move focus when the user's interaction context has changed enough that leaving focus where it is would make the new state difficult to understand or operate.
A dialog opening is a context change.
A dialog closing is a context change.
A failed form submission that produces an error summary may create a new point of orientation.
A client-side route transition may require attention to where the user begins in the newly presented content.
But a notification appearing on the page does not automatically mean focus should move to it.
A validation hint changing does not automatically mean focus should jump.
Every expanding region does not need to steal focus from the control that expanded it.
Focus is not a notification system.
Moving it has a cost.
When an application changes focus, it changes where the user's next keyboard action will occur.
That should be intentional.
Links need context
Keyboard focus is only one way people navigate links.
Screen-reader users often have additional navigation strategies available to them.
They may move by headings.
They may move by landmarks.
They may navigate directly through form controls.
And they can often inspect or move through links as a collection rather than reading every surrounding sentence first.
This exposes a familiar accessibility problem very quickly.
Imagine a page containing links like:
- Click here
- Learn more
- Learn more
- Read more
- Click here
- Learn more
Within the full visual page, each one might appear understandable.
Perhaps this sentence says:
Learn about our accessibility program. Click here.
Another says:
We publish annual sustainability reports. Learn more.
A sighted reader may naturally combine the link with the surrounding sentence.
But remove the links from that visual context and the meaning collapses.
A screen-reader user's list of links can become:
Click here
Learn more
Learn more
Read more
Click here
Learn more
Learn more about what?
Click where?
Read what?
The anchor works.
The semantics are insufficient.
Compare that with links such as:
- Accessibility approach
- Annual sustainability report
- Engineering careers
- Investor relations
- Privacy policy
Now the links remain useful even when someone encounters them outside the visual sentence in which they appeared.
That is an important design constraint.
A link is not just the words between <a> and </a>.
Its purpose exists within a larger semantic context.
Structure carries context too
Return to that large corporate footer.
Imagine dozens of links placed inside 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>Those links work.
But we know more about them than the markup communicates.
Some belong to company information.
Some belong to support.
Some belong to legal information.
That organization can be expressed structurally.
Headings can name groups.
Lists can express collections.
Navigation landmarks can identify sets of navigation links.
The visual design may show these relationships with columns, spacing, borders, or typography.
Semantic HTML gives those relationships another representation.
That matters because not everyone experiences the visual layout.
A sighted user may scan the page spatially.
A sighted keyboard user may navigate through each interactive element while watching the focus indicator.
A screen-reader user may navigate through headings, landmarks, or links without traversing the page in the same visual sequence.
These users are not interacting with three different websites.
They are interacting with different representations of the same document.
Good semantics make those representations agree.
Native elements already carry behavior
This is also why choosing the correct native element matters so much.
Consider:
<a href="/writing">Writing</a>That one element already carries an enormous amount of behavior.
It has link semantics.
It participates in keyboard navigation.
It exposes its role to assistive technology.
It supports familiar browser interactions.
It has expected activation behavior.
Now compare it to:
<div tabindex="0">Writing</div>Making the <div> focusable did not make it a link.
We have created a keyboard stop without establishing the meaning or full behavior users expect from a link.
Now we need to start reconstructing what the anchor already provided.
This pattern appears constantly in accessibility work.
We reach for JavaScript, ARIA, or tabindex to recreate behavior the platform already knows how to provide.
The simplest accessible implementation is frequently the one that interferes with the browser the least.
Different layers answer different questions
There is an important distinction here.
A meaningful link name does not replace visible focus.
Visible focus does not replace good link text.
A properly ordered DOM does not replace semantic grouping.
A <nav> does not solve an invisible focus indicator.
These layers complement one another.
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.
And for anyone moving sequentially:
Where will I go next?
A sensible document and focus order help answer that.
Accessibility starts to become much easier to reason about when we stop expecting one technique to solve every problem.
Focus can exist and still disappear
There is another subtle version of this problem.
The focus indicator exists.
But it cannot be seen.
Maybe the focused control is underneath a sticky header.
Maybe a fixed cookie banner covers it.
Maybe a sticky footer obscures the bottom of the viewport.
Maybe the outline technically renders, but its contrast against the surrounding design makes it nearly impossible to perceive.
From the browser's point of view, focus exists.
From the user's point of view, their location has disappeared.
This is why focus needs to be treated as part of layout and interaction design, not just as a CSS pseudo-class engineers add near the end.
A focus indicator occupies visual space.
Sticky surfaces can interfere with it.
Scrolling behavior affects it.
Responsive layouts affect it.
Focus is part of the interface.
Orientation is the larger goal
There is a tendency to describe accessibility as a checklist of individual requirements:
- add alt text
- label the input
- show a focus ring
- don't use positive
tabindex - use descriptive links
- add landmarks
Those requirements matter.
But they become easier to understand when we ask what problem they are solving.
A large part of accessible interaction design is preserving 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?
That is why focus, semantics, and context belong in the same conversation.
Focus Is Intentional
There is a simple philosophy behind most of this:
Start with the correct HTML.
Let links be links.
Let buttons be buttons.
Let the DOM establish a sensible reading and interaction order.
Give groups meaningful structure.
Give links names that survive outside their visual sentence.
Make focus visible.
Then introduce programmatic focus when an interaction genuinely changes the user's context.
Use tabindex="0" when something legitimately needs to join the normal focus order.
Use tabindex="-1" when something needs to be a programmatic focus destination without becoming another Tab stop.
And when you find yourself reaching for tabindex="7", stop and inspect the structure instead.
The browser's defaults are not perfect.
But they are often a much better starting point than the custom interaction model we are about to build over them.
Keep the experience in focus
A focus indicator may be the part we can see.
But focus itself is navigation.
It is orientation.
It is the connection between one interaction and the next.
Semantics give those interactions meaning.
Context gives them a place within the larger document.
When all three work together, someone navigating a forty-link footer can see where they are, understand what each destination means, and make sense of the structure around those destinations.
When they do not, an interface can technically contain all the right links and still leave someone lost.
And this is where accessibility work begins to cross boundaries.
The order may come from HTML.
The focus indicator may come from CSS.
Programmatic focus may come from JavaScript.
The interaction model may have been designed in Figma.
Tests may verify parts of all of them.
Each artifact can look correct on its own.
The harder question is whether they still describe the same experience.
That is where another class of design-system problem begins.