Openbare informatie - SED - Enkhuizen

Evenementen in Enkhuizen - SED - Enkhuizen

Archief - SED - Enkhuizen

Projecten - SED - Enkhuizen

Afval - SED - Enkhuizen

Werk en inkomen - SED - Enkhuizen

Actueel - SED - Enkhuizen

Burgerzaken - SED - Enkhuizen

Pagina niet gevonden - SED - Enkhuizen

Afspraak maken - SED - Enkhuizen

When selecting a user interface component with the keyboard, the focus indicator must 
not be _partly_ obscured by anything in front of it. 

## Why this matters

When using a keyboard, it is important that the user can see where they are on the page.
If the focus indicator is obscured, the user may not know where they are, and may not
be able to interact with the page.

## Examples

Most common examples include:

* Banners at the top or bottom of the page, such as cookie banners
* Fixed navigation bars
* Fixed footers
* Popup modals, such as cookie consent modals

## Testing this manually

* Open the page
* Press the tab key to move focus through elements on the page
* Check that the focus indicator is not fully obscured by anything in front of it

## Comparison with Level AA version

This is the stricter (Level AAA) version of the Level AA check (2.4.11).

The Level AA version only flags issues where the focus indicator is _completely_ obscured, this
version flags issues where the focus indicator is _partly_ obscured.

## How to fix

With elements that cover part of the screen, such as cookie banners, ensure
that the user can scroll to see any content behind the banner, without having to close
the banner.

The two most very common solutions are:

1. Avoid the use of fixed elements that could obscure other elements
2. Use the CSS `scroll-margin` property (see [WCAG Technique C43](https://www.w3.org/WAI/WCAG22/Techniques/css/C43))

With popup modals, it should usually be impossible to focus anything behind the modal.
Most common modal frameworks will automatically trap focus within the modal, so that
this is impossible. Example: [Bootstrap Modal](https://getbootstrap.com/docs/5.2/components/modal/#live-demo).

## Methodology

1. Silktide simulates a keyboard user tabbing through the page
2. Silktide simulates the focused element being vertically scrolled into the center of the page
   (see 'Rationale for scrolling' below)
3. For each element that receives focus, Silktide checks that the focus indicator is not obscured
   by another element on top of it
4. If the focus indicator is obscured, Silktide raises an issue

### Rationale for scrolling

The rationale for point #2 (above) is worth expanding. At different screen sizes, the amount of scrolling
a browser makes between tabs will vary. For example, Chrome will typically avoid scrolling until a
focus element falls outside the current viewport, and then it will adopt the least amount of
scrolling possible to bring the element into view.

This means if you test a page in Silktide, and in a browser with a fractionally different height,
you may experience different elements being obscured or not, especially elements blocked by sticky headers
and footers. Every only a few pixels of difference in screen height can make a huge difference the
further down the page you go.

In all these cases, the use of user-directed vertical scrolling, e.g. via the cursor keys, would permit
the focused element to be seen. Whether that would be necessary would depend on the exact browser and
size of the browser viewport.

Silktide purposely adopts a generous frame here, to avoid flagging issues which might only affect the
exact screen size that it tested. In our testing, when we didn't do this, the number of subjectively false
positives could be very high, and extremely confusing, as they would not replicate during manual testing on
anything but the exact same browser size.

Essentially, Silktide chooses not to flag issues which _could_ affect some very particular screen sizes
_inconsistently_, but it will flag issues that should affect _all_ screen sizes consistently.

The W3C does not specify how to test this Success Criterion.

### Simulating conditional modals

Silktide adopts additional behavior to simulate the use of dialog modals that may be opened by user
behavior after a page loads (i.e. modals that don't automatically open when a page loads).

If a non-opened modal is detected, Silktide assumes that _elements outside the modal cannot be focused_.
This is not guaranteed, but it is impossible for Silktide to predict the behavior of a modal that has not
yet been opened, and this is much more accurate than assuming that the modal does not constrain focus.

As a result, a modal which is incorrectly programmed (i.e. doesn't constrain focus) may not be detected
as obscuring focus behind it, if the modal is not opened by default.

## Further reading

* [WCAG 2.4.12](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-enhanced)
* [WCAG Technique C43 - Using CSS margin and scroll-margin to un-obscure content](https://www.w3.org/WAI/WCAG22/Techniques/css/C43)

ensure-focus-is-not-obscured-enhanced

December 2025

November 2025

Enkhuizen

	Title / URL	Issues
	Openbare informatie - SED - Enkhuizenwww.enkhuizen.nl/direct-regelen/openbare-informatie/	1
	Evenementen in Enkhuizen - SED - Enkhuizenwww.enkhuizen.nl/evenementen-in-enkhuizen/	1
	Archief - SED - Enkhuizenwww.enkhuizen.nl/archief/	1
	Projecten - SED - Enkhuizenwww.enkhuizen.nl/projecten/	1
	Afval - SED - Enkhuizenwww.enkhuizen.nl/direct-regelen/afval/	1
	Werk en inkomen - SED - Enkhuizenwww.enkhuizen.nl/direct-regelen/werk-en-inkomen/	1
	Actueel - SED - Enkhuizenwww.enkhuizen.nl/actueel/	1
	Burgerzaken - SED - Enkhuizenwww.enkhuizen.nl/direct-regelen/burgerzaken/	1
	Pagina niet gevonden - SED - Enkhuizenwww.enkhuizen.nl/invented-url-for-404-page	1
	Afspraak maken - SED - Enkhuizenwww.enkhuizen.nl/afspraak-maken/	1

Ensure focus is not partly obscured

Enkhuizen

Where this issue has occurred