Meeting minutes
JJ WCAG2Mobile there has been a delay - perhaps next week there'll be a publication early May
2.4.3 Focus Order
<JJ> https://
<JJ> w3c/
Aash From a design point of view - what if there are elements that cannot be used by (e.g. visual impairments) - for example maps
Sorry I couldn't capture the end of that - someone enabled translations on zoom and zoom stole my focus
Which is ironic
<JJ> sorry, just opened the transcript panel to keep track of all text
Aash maps iterate through focus which is not helpful for people with assistive technologies.
pauljadam everything operable with a touch gesture needs to be focusable as well
<pauljadam> Put the map in a container with a name and VoiceOver can skip over it or to it
Detlev If I understand correctly - this is not specific to mobile. Maps can have 100's of dots, which can also be problematic due to grouping, it really depends what you do outside that map. I think it's difficult to tell without entire context
<pauljadam> On desktop you can make the map pins focusable with arrow keys like radio buttons rather than tab key so they can skip past faster with keyboard.
<pauljadam> its often confused with reading order yes
Detlev Do we have concensus that focus order does refer to keyboard as opposed to swipe focus order (screen reader)
<JJ> https://
@JJ it seems to apply to all
pauljadam I have a focus order test case: as a keyboard user that focus is moved to controls. For screen reader and switch you focus on everything, but keyboard you just get interactive elements. Other assistive tech can be used to test
Important note: Switch ordering and keyboard ordering is different on Android
Switch allows for focus of containers and has an additional menu
ACTION: If keyboard interface is replaced with accessibility interface, emphasize the focus logic / differences between keyboard/web and app behavior
(and actions, don't forget the actions - hidden from keyboard users)
Detlev to what extent do we take modifiers - they are quite common. Is there is a good way of securing focus order without modifiers?
TAB+X is the accessibility shortcut
I really dislike that
(or Z, but it's Tab as a modifier)
2.4.11 Focus Not Obscured (Minimum)
<JJ> https://
<JJ> w3c/
"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/
<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://
<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
1.3.1 Info and Relationships
pauljadam ARIA landmarks exist on web, but can't do this on mobile. Apple never tells you what to do with it. How do we write success and failure techniques
<RacheleD> quit