# Never aria-hidden Something Focusable
**NEVER** · **ID:** `interactions-aria-hidden-focusable` · **Category:** interactions
**Source:** [ARIA](https://www.w3.org/WAI/ARIA/apg/)
**Interactive version:** https://ui-guides-agent-rules.netlify.app/principles/interactions-aria-hidden-focusable
> NEVER: Put `aria-hidden="true"` (or `role="presentation"`) on a visible focusable element or a subtree that is still tabbable — it strips the a11y tree but NOT the tab order, so focus walks into a ghost: the ring travels off screen and the screen reader announces nothing. Use `inert` on the container (removes it from tab order, a11y tree and hit-testing at once) or unmount it.
Use inert or unmount to hide a subtree, so the tab order and the a11y tree agree
aria-hidden="true" removes an element and its whole subtree from the accessibility tree. It does NOT remove anything from the tab order — those are two different trees, and this is the single most common way to desynchronise them. An off-canvas drawer hidden with aria-hidden plus opacity: 0 and a transform is still fully tabbable: keyboard focus walks into it, the focus ring travels off screen, and a screen reader announces nothing whatsoever, because the element it is focused on does not exist as far as the accessibility tree is concerned. Focusing on "nothing" is a dead end no user can recover from. The correct tools remove the subtree from BOTH trees at once: unmount it, or set the inert attribute on the container — inert takes the subtree out of the tab order, out of the accessibility tree, and out of hit-testing in one attribute, which is why it also shows up in this corpus as the way to freeze the rest of the page during a drag. If for some reason you must keep aria-hidden, you have to strip tabindex and disable every focusable descendant by hand, and keep doing so as the subtree changes — which is precisely the bookkeeping inert exists to delete.
## Rule snippet
```tsx
// ghost:
```
## Bad — do not do this
`interactions-aria-hidden-focusable-bad`
```tsx
import { useState } from 'react';
const ITEMS = ['Profile', 'Billing', 'Sign out'];
export function AriaHiddenFocusableBad() {
const [open, setOpen] = useState(false);
const [focused, setFocused] = useState('nothing');
const [focusIsVisible, setFocusIsVisible] = useState(true);
const trackFocus = (label: string, visible: boolean) => () => {
setFocused(label);
setFocusIsVisible(visible);
};
return (
{/* aria-hidden + opacity-0 + translate hides the menu from EYES and from the
accessibility tree — but not from the tab sequence. The buttons inside are
still focusable, so keyboard focus walks into content that is announced as
nothing and rendered as nothing. */}
{ITEMS.map((item) => (
))}
Focus is on:{' '}
{focused} Can you see it?{' '}
{focusIsVisible ? 'yes' : 'NO — focus is on an invisible element'}
Leave the menu closed. Click Before, then press Tab four times. Presses
3, 4 and 5 land inside the closed menu: the focus ring vanishes, the readout
names an element you cannot see, and a screen reader announces nothing at all,
because aria-hidden removed it from the accessibility tree while
leaving it in the tab order.
aria-hidden="true" on a parent of focusable children — a Rules of ARIA violation
{/* One attribute, both effects: `inert` removes the subtree from the tab
order AND from the accessibility tree, and blocks pointer events too.
No aria-hidden, so the two never disagree. Unmounting the panel is the
other correct answer. */}
{ITEMS.map((item) => (
))}
Focus is on:{' '}
{focused} Can you see it?{' '}
{focusIsVisible ? 'yes — focus is always on something visible' : 'no'}
Leave the menu closed and Tab from Before: the third press lands on{' '}
After. The hidden items are simply not in the sequence. Open the menu
and Tab again — now they are, and they announce normally. This is the same{' '}
inert used to freeze the page during a drag, applied to the case it
was really designed for.
inert takes the subtree out of the tab order and the accessibility tree together