Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

opacity: 0 makes an element transparent; it does not remove the element from the interface. The element stays in the DOM, and its controls may still receive keyboard focus or pointer events. For content that should truly be unavailable while closed, use an appropriate hidden state and manage focus when the component opens and closes.

What `opacity: 0` actually does

Setting an element’s opacity to zero makes it and its children appear invisible. It does not remove them from the document or automatically make them unavailable to users. As MDN’s CSS opacity reference explains, a fully transparent element can still register pointer events and, if it is in the tab order, receive keyboard focus.

That distinction matters for controls such as buttons and links: a person may not see a control but still reach it with Tab, activate it, or encounter it while navigating the page.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Why `pointer-events: none` is not enough

pointer-events: none prevents pointer interaction with the element; it does not by itself remove keyboard focusability. A keyboard user may still tab to focusable descendants even when a mouse or touch interaction cannot reach them.

In a screenshot lightbox example, Indie Core Dev found that three buttons remained tabbable despite the lightbox using pointer-events: none. The author counted 52 tab stops on that site before changing the visibility approach and 49 afterward. Those figures describe that page’s particular implementation, not a general statistic. The example and the author’s reported keyboard tests are documented in the lightbox article.

Choose a hidden state that matches the behavior you need

If closed content should be hidden from users and assistive technology, use a state that actually hides it rather than relying on opacity alone. The right choice depends on whether the component needs to remain rendered for an animation and how its focus should behave.

Approach What it does When to consider it
opacity: 0 Makes the element visually transparent, but does not by itself remove pointer interaction, keyboard focusability, or exposure to assistive technology. As a visual effect, paired with separate interaction and accessibility handling when needed.
visibility: hidden Hides the element visually and makes it unavailable for normal interaction and focus while hidden. When the element should be hidden but remain in the rendered structure; test the transition and focus timing.
display: none Removes the element from layout and makes it unavailable for interaction and assistive technology while not displayed. When no visual exit transition or retained layout space is needed.
HTML hidden attribute Marks content as not currently relevant and hidden from presentation. When the content should be inactive and hidden until the attribute is removed.

MDN advises against using opacity alone to convey information to screen readers. Choose the hidden state based on the component’s intended behavior, not only on how it looks.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Manage focus when hiding a dialog

A modal dialog needs more than a hidden style. When it opens, move focus into it. While it is open, keep Tab and Shift+Tab navigation within the dialog and support Escape dismissal. When it closes, return focus to the control that opened it when appropriate.

The W3C ARIA Authoring Practices modal-dialog pattern describes this focus behavior. It also makes an important distinction: aria-modal="true" communicates modality to assistive technologies, but does not create modal behavior. The application must actually prevent interaction with the background and visually obscure the rest of the page before claiming that the dialog is modal.

Account for visibility and focus timing

In the lightbox example, the author found that calling focus() while the dialog was still visibility: hidden did not move focus. The implementation made visibility change immediately on opening, then delayed the visibility change on closing so the opacity fade could finish. That is one implementation’s solution, not a universal timing rule: test the actual component, transition, and focus sequence.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Test the closed and open states with a keyboard

  1. Close the lightbox, drawer, menu, tooltip, or other component, then press Tab through the page. Confirm that hidden controls are not encountered.
  2. Open the component using the keyboard and confirm focus moves to a useful control or location inside it.
  3. Use Tab and Shift+Tab to check whether focus stays inside. This is expected for a modal; a non-modal component may have a different interaction contract.
  4. Dismiss the component using its expected method, including Escape when it is modal, and confirm focus returns to the opener when appropriate.
  5. Check that what assistive technology exposes and what keyboard users can reach match what is visibly available.

These checks reflect the W3C modal-dialog pattern and the reported keyboard testing of the lightbox example; they are practical checks, not a claim of independent cross-browser testing.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.