Success Criterion 2.4.11 - Focus Not Obscured (Minimum) - Level AA

[JJdeGroot]

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#focus-not-obscured-minimum

Share your thoughts for applying to mobile apps as a comment below.

[jamieherrera]

Based on previous task force conversation, this SC can be applied to native mobile apps and mobile web with minimal or no deviation from WCAG2ICT and include both Note 1 and Note 2:

Proposal

In MATF's first draft of guidance, this SC's section will read as:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.11.
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

Note 1
Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this Success Criterion.

Note 2
Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered hidden due to author-created content.

Please indicate your agreement with a thumbs up emoji 👍, or if you disagree, use the thumbs down emoji 👎 and elaborate in comments.

[jha11y]

Notes from 25 September, 2024 Meeting:

Meeting Minutes 25 September

Jamie: The content itself seems straightforward. Things to think about: How is this different from focus visible? What is obscured but still allowed? There could be questions raised about how this plays out in real practice. What does it mean as a concept?

Illai: On mobile, not so much web, in many cases you have elements receiving focus that should not be part of the page / screen - while using keyboard it makes sense

Joe_Humbert: Are there any stats on keyboard usage? (He did say he supports the idea :) ) How prevelant is it?

Joe_Humbert: do mobile OS use the same HID interface - is it the same as desktop

Devanshu: In my opinion and experience - the problem is that there is no stats and that is the main problem. People do ask about keyboard accessibility. There are a lot of companies making these devices, but no standards seem to exist

Illai: I didn't mean refer to keyboard - but we should try to rephrase that we should not focus on keyboard for this criterion

quintinb: +1 Illai

Karla: +1 Illai

Jamie: What do folks think about the addition of a layer that includes voice control and voice access, but focus on the audience that needs this type of focus? Is this about things that have access focus?

Jamie: voice users may have issues with this because the component under "focus" is actually obscured by something else

Joe_Humbert: should we replace the word "keyboard" in everywhere or just in this criteria?

Illai: we should look at the context of each one

I think we could call it "Input focus"

Jamie: 2.4.11 could say "When a keyboard operable component receives focus" - this about the component that has focus. The question about which type of focus is unclear. People may consider this verbose or get overly literal with the language.