Repository navigation
Clarification on Viewport Height for SC 2.4.11 (Focus Not Obscured) under SC 1.4.10 (Reflow) Conditions #5120
|
Hi everyone, I have a question regarding the testing parameters for SC 2.4.11 Focus Not Obscured (Minimum) when applied in the context of SC 1.4.10 Reflow. SC 1.4.10 specifies a viewport width of 320 CSS pixels, but it does not explicitly define a corresponding viewport height. This lack of a height standard creates ambiguity when testing for focus obscuration, especially with sticky or fixed elements. For example:
In this case, the compliance result changes depending on the viewport height chosen by the tester. My Questions:
I would appreciate the community’s guidance or any existing interpretation on this matter. Thank you! |
Replies: 5 comments 1 reply
|
Draft response: 2.4.11 is not limited / set to any particular viewport size. It applies (theoretically at least) to all possible viewport sizes, as authors should prevent the focused element from being obscured, regardless of what viewport size the user is using. |
|
@patrickhlauke Thank you for the clarification. Without a baseline height, the test results become highly subjective depending on the tester's environment. Furthermore, in extremely small viewport heights, it is technically inevitable for the focused element to be obscured by fixed components (like headers or footers). |
a tester needs to ensure that they test thoroughly at (theoretically) all viewport sizes/aspect ratios/etc. it's not enough for a tester to look at things just at their one current testing size and calling it a day. currently, WCAG defines no minima, though taking a 320 CSS px by 256 CSS px as the smallest testing target seems sensible. |
That a convenient viewport size to use because it allows an auditor to check for both vertical and horizontal scrolling simultaneously. If content fits (reflows) entirely in the viewport, it passes 1.4.10. But content is permitted to scroll along one axis or the other. I would flag your Scenario A as a fail. |
|
Thank you for the insights @patrickhlauke and @bruce-usab. I'm glad to hear that taking 320 x 256 px as a baseline testing target sounds sensible. To illustrate why this matters in practice, I'd like to share an example from my actual testing. Below are two instances at a 320px width, but with different viewport heights (256px vs. 480px):
As this demonstrates, the evaluation result changes entirely depending on the viewport height the auditor happens to use. Without an agreed-upon baseline height, testers will inevitably evaluate accessibility under completely different conditions and reach conflicting conclusions. This is precisely why having a standardized minimum height is crucial for consistent and fair auditing. |
|
It would be good to hear from some seasoned end-users (who rely upon screen magnification), but I wouldn’t fail either of those. I presume you have some concern for sort widget being partially obscured and the scroll bar appearing? Is that correct? Even if that sort button was entirely “above the fold” I don’t think I would fail it under 1.4.10 (as there is not need to scroll in both directions). It’s okay for links/buttons to be outside the current viewpoint. 2.4.11 is about tabbing through a page and the focus disappearing (i.e., tabbing to a button doesn’t cause the page to scroll the focus into the viewport. |
It would be good to hear from some seasoned end-users (who rely upon screen magnification), but I wouldn’t fail either of those. I presume you have some concern for sort widget being partially obscured and the scroll bar appearing? Is that correct?
Even if that sort button was entirely “above the fold” I don’t think I would fail it under 1.4.10 (as there is not need to scroll in both directions). It’s okay for links/buttons to be outside the current viewpoint. 2.4.11 is about tabbing through a page and the focus disappearing (i.e., tabbing to a button doesn’t cause the page to scroll the focus into the viewport.