Meeting minutes
Planning
JJ: Updates the group on Joe, Julian, and himself working identifying small variation SCs that we can move on from.
JJ: We will use Github issue comments to propose SCs issues that can be closed. By next meeting, SCs that apply directly as written will have comments.
2.3.1 Three Flashes or Below Threshold
JJ: Will be out in September, Joe will run meetings.
<Joe_Humbert> I will be facilitating the meetings, not "in charge" :-)
JJ: Summarizes current activity on this SC's github issue.
Joe_Humbert: This will require guidance on testing.
Joe_Humbert: This might happen if devs create a custom animation. Regular OS animations already take this SC into consideration.
JJ: Testing might be similar to ICT
Detlev: The WCAG SC defines "threshold" of 10 degree visual field. Can make testing more difficult.
Detlev: Only AAA conformance rules out any flashing that occurs more than 3x/second
Detlev: The size of the flashing area depends on device size so success/failure could vary.
JJ: Seems like applying is pretty direct but testing is more complicated.
GleidsonRamos: OS animations and transitions are within the SCs guidance, but Flutter and other cross-platform technologies allow animations that are much more disruptive
JJ: Had a recent experience where custom animations were quite busy and distracting.
Detlev: Animation isn't flashing. Hasn't seen any transitions that include flashing.
JJ: Hasn't failed this SC, nor have colleagues.
GleidsonRamos: In a stock app, transition between positive and negative values can generate flashes. Not usually faster than 1/sec, but if animations get queued they can occur very frequently.
GleidsonRamos: Flashes occupied ~10% of screen
JJ: In first draft, we can just say whether the SC applies as written. In follow-up versions, we can address testing.
JJ: Would be helpful to have a failing example.
Joe_Humbert: Clarifies that the guideline applies but Note 1 in WCAG 2.2 needs to be tweaked to address mobile apps.
2.4.3 Focus Order
JJ: Summarizes WCAG2ICT guidance and Github issue
JJ: There's always discussion of where focus order should begin, is auto-focusing on an input field okay
Joe_Humbert: Re: Where to start focus order, I recommend not forcing focus order on screen load. Forcing focus in iOS can lead to weird, jumpy experiences.
Joe_Humbert: This is a common accessibility issue at my company. Devs can do lots of things that compromise reading/focus order.
<julianmka> +1 to what Joe says
@Detlev: Clarifies we are covering keyboard focus order in this SC
JJ: I've also seen this apply to other ATs like screen readers.
Detlev: Are failures of this SC covered under 2.1.1 Keyboard focus or other SC also?
Detlev: As mentioned in this SC's Github issue, mobile keyboard navigation can shift from tab to arrow keys which can complicate things.
@Detlev: Cites a developer who recently mentioned that keyboard support is hard and focus is on screen reader and touch-based ATs.
JJ: This SC includes a definition that explicitly cites keyboard interfaces - "navigated sequentially"
JJ: From a technical standpoint, Android has properties which can alter keyboard order. iOS has more robust full keyboard access in more recent version.
JJ: Cross-platform technologies like Xamarin, Flutter, etc. have much more limited support.
julianmka: Interprets this SC to include speech recognition -- emphasis on focus of interactive elements.
Joe_Humbert: Considers this SC to apply to screen reader focus order on mobile because 1.3.2 meaningful sequence has a very specific definition. Does skipping over static content reduce the meaning of the experience?
JJ: Some questions over how broadly to apply this SC. Does intent only include keyboard?
Detlev: AGWG seems to have some consensus that most members think that any screen reader focus would be reported 1.3.2 meaningful sequence.
Detlev: Example, related content that isn't grouped would be a minor failure of 1.3.2.
ACTION: Link to AGWG consensus for 2.4.3 Focus Order / 1.3.2 Meaningful Sequence
Detlev: AGWG consensus seems to recognize 2.4.3 as applying primarily to keyboard.
Jamie: The difference between focus order and meaningful sequence - one is about focusable components in the operable category. Meaningful sequence is about things on the screen that can be perceived. Nothing in 2.4.3 Focus order calls out keyboard as the only tool to use.
Detlev: Adding to Voice Control conversation -- it would fall under 2.1.1 keyboard operable.
JJ: Do we need to reach consensus about which ATs fall under 2.4.3
Jamie: That seems like a WCAG decision, not just mobile. Should we be that specific?
JJ: If 2.1.1 considers other forms of keyboard interface like voice control, then it seems like voice control shoudl also be considered in 2.4.3 focus order.
ACTION: Define meaningful / meaning as intended in 1.3.2 Meaningful Sequence
Jamie: This could be an opportunity to define what "meaningful" means. 2.4.3 is cited often in issues, but also often canceled because the definition of "meaningful" is vague.
@jamei
@Jamie: Might not be a MATF issue specifically, but iOS's keyboard functionality is more distinct from typical web keyboard interactions.
<Joe_Humbert> https://
Joe_Humbert: The understanding doc does talk about "meaningful" and gives examples.
Joe_Humbert: Unlike on desktop, I'm not certain that other ATs hook into keyboard interface/interactions the way is true for computer-based browser content.
<Jamie> +1 research to confirm AT and keyboard interface
JJ: As far as I know, ATs like switch and voice control do not hook into key events in iOS.
JJ: We could add a definition where we explain thinking behind including other ATs with keyboard, or substitute "assistive technologies" for "keyboard"
<Jamie> +1 JJ
<JJ> julianmka: Brings up that default focus order should not be a fail?
<Joe_Humbert> +1 to default focus order is not a fail.
<Jamie> +1
JJ: Need to define what "default" means in context of focus order.
<Joe_Humbert> Apple seems to mess with default VoiceOver focus/reading order in different versions of iOS
ACTION: Definition for 'keyboard interface' in apps, perhaps replace it with 'assistive technologies'
ACTION: Define what "default" means in context of focus order
julianmka: We could include a best practice to keep consistent focus order practices across an app, if you do choose to force focus.
<Jamie> +1 @detlev question
Detlev: Doesn't want to lose sight of the keyboard aspect of this SC.
Detlev: If we refer to "assistive technologies" does that mean we're no longer concerned with keyboard?
<Jamie> ie could keyboard be replaced with other AT like Voice Control
<Joe_Humbert> +1 to noting what detlev said is some definition or note
JJ: Could also look at other standards like 508, EN 301 549 to see how they hand keyboard vs other ATs
<Jamie> Full keyboard access is AN at
Detlev: Would be quite unusual to class keyboard as an AT. It's a mode of input.
Jamie: In follow up to julianmka's point re: setting focus order: If Consistent Navigation includes sets of screens, this consideration could fall into that SC.
<JJ> To add on Jamie, Full Keyboard Access on iOS is part of Accessibility settings and has to be enabled before you can navigate using the keyboard (when it's disabled, you can only input text)
Jamie: Operating systems are inconsistent about how they set focus. The issue of where focus should begin and if it matters could be considered under Consistent Navigation if we could move to defining "set of screens" instead of "set of apps"
<Detlev> +1 to Jamie reg. consistent navigation
JJ: Lots more to discuss here, let's keep it going in Github issues.