A reader clicks a table-of-contents link. The page scrolls, but the heading lands underneath the fixed navigation bar. The link technically worked; the destination is still hidden.
This happens when the scroll position and the space occupied by sticky content are designed separately. The fix should account for the header’s actual behaviour, including the taller version that may appear on a narrow screen.
Leave space at the destination
For a simple layout, a target heading can use an appropriate scroll-margin-top value. MDN documents the property. For example, .article h2 { scroll-margin-top: 6rem; } illustrates the idea; six rem is not a universal header measurement.
Choose the value from the layout, not from an arbitrary snippet. If the navigation wraps, a banner appears or text size changes, revisit the spacing. A suitable scroll-padding strategy on the scrolling container may be another option depending on the design.
Test more than the click
Open a URL with the fragment already attached, navigate from the page’s contents list and use the browser’s back button. Test at narrow widths and with enlarged text. Check that the heading and enough surrounding context remain visible.
Then move through links and controls with the keyboard in both directions. A visible anchor destination does not prove keyboard focus is protected. W3C documents sticky headers that completely obscure focused elements as an accessibility failure.
If the header consumes too much of a small viewport, consider allowing it to scroll normally at that size. Keeping navigation permanently visible is useful only when it leaves the content usable.
Record the tested widths and interaction paths when reviewing the change. A screenshot at the top of the page cannot demonstrate that a link halfway through an article lands where a reader can actually see it.