Discussed in today’s meeting.

30 April 2025

"entirely hidden" - that is suspiciously gracious

pauljadam I have a bad example in my ios ally techniques app. The bad modal allows keyboard focus to move behind, as well as sticky headers and footers

Jamie Mostly curiosity - what is keeping use from voting on this?

<JJ> Do we agree to vote on the proposal: [w3c/matf#52 (comment)](https://github.com/w3c/matf/issues/52#issuecomment-2358554411)

<Jamie> +1

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

<JJ> This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.11.

<JJ> When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

<JJ> Note 1

<JJ> 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.

<JJ> Note 2

<JJ> 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.

<pauljadam> +1

<Carol> +1

<Joe_Humbert> -1

<Aash> +1

<Detlev> 0

<quintinb> -1 We need a note saying there should be enough visible space to interact with the component?

Unless I am missing something

<rachaely> +1

<Megan_Pletzer> +1

Like it needs to be interactable and perceivable, surely?

<Carol> that comment is not in web, i don't think we should do it for mobile

Jamie if folks have issue with the SC, perhaps it should go to the main wcag. How it relates to mobile, we could add notes, but this wouldn't be the same kind of note. We don't want it to come out as something different from the original wcag

Happy to go with the group on this

Joe_Humbert I am worried for screen reader users, but this could significantly impact them on mobile more

<Joe_Humbert> I will aLSO GO WITH THE GROUP

<Joe_Humbert> sorry capslock issue

pauljadam Maybe this doesn't apply to screen readers because they provide their own focus

Sorry pauljadam I hope I got that right

<pauljadam> Yes and if the screen reader focus was on an element that was obscured and that element was a focusable element then the SC would apply, it just would not apply to static text being visible when focused with a screen reader.

<JJ> https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html

<Zakim> rachaely, you wanted to what about switch control?

rachaely How does switch control factors in - it's not exactly the same]

Switch control does bring it's own focus

on iOS and Android anyway

<pauljadam> On iOS if something is VoiceOver focusable, it would be focusable with full keyboard access and switch control, if switch control is on a focusable element then it cannot be fully obscured.

Android Hardware keyboard is the only one that doesn't bring it's own focus to the table

For now... I have an app!

<pauljadam> sorry I don't mean static elements though

Joe_Humbert My guess is that because this is wcag 2.2 it was written through a web lens. There may not have been a distinction between keyboard interface and keyboard

pauljadam they all apply, keyboard focusable elements should not be obscured

<Jamie> 9 of 12 voters... do we need more to close?

<Jamie> 13, sorry

ACTION: Decide what modes of operation (assistive technologies) are part of "keyboard focus"

Yeah happy to invert from -1 to +1

Motion to draft

<RacheleD> +1

<Joe_Humbert> +1

<quintinb> +1

ACTION: Decide what modes of operation (assistive technologies) are part of "keyboard focus"

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

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions