Contact - Gemeente Papendrecht

Zorg en hulp - Gemeente Papendrecht

Belastingen - Gemeente Papendrecht

Alle onderwerpen - Gemeente Papendrecht

Vergunningen en toestemmingen - Gemeente Papendrecht

Duurzaam en natuur - Gemeente Papendrecht

Geboorte en overlijden - Gemeente Papendrecht

Verkiezingen - Gemeente Papendrecht

Wonen en (ver)bouwen - Gemeente Papendrecht

Bezoek balie - Gemeente Papendrecht

When selecting a user interface component with the keyboard, the focus indicator must 
not be _completely 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 AAA version

This is the less strict (Level AA) version of the Level AAA check (2.4.12).

This Level AA version only flags issues where the focus indicator is _completely_ obscured, the
Level AAA 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.11](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum)
* [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-minimum

February 2026

January 2026

Papendrecht

	Title / URL	Issues
	Contact - Gemeente Papendrechtwww.papendrecht.nl/Contact	12
	Zorg en hulp - Gemeente Papendrechtwww.papendrecht.nl/Zorg_en_hulp	12
	Belastingen - Gemeente Papendrechtwww.papendrecht.nl/Belastingen	12
	Alle onderwerpen - Gemeente Papendrechtwww.papendrecht.nl/Alle_onderwerpen	12
	Vergunningen en toestemmingen - Gemeente Papendrechtwww.papendrecht.nl/Vergunningen	12
	Duurzaam en natuur - Gemeente Papendrechtwww.papendrecht.nl/Duurzaam_en_natuur	12
	Geboorte en overlijden - Gemeente Papendrechtwww.papendrecht.nl/Geboorte_en_overlijden	12
	Verkiezingen - Gemeente Papendrechtwww.papendrecht.nl/Verkiezingen	12
	Wonen en (ver)bouwen - Gemeente Papendrechtwww.papendrecht.nl/Wonen_en_ver_bouwen	12
	Bezoek balie - Gemeente Papendrechtwww.papendrecht.nl/Contact/Bezoek_balie	12

Ensure focus is not fully obscured

Papendrecht

Where this issue has occurred