IRC log of matf on 2024-08-21
Timestamps are in UTC.
- 13:00:08 [RRSAgent]
- RRSAgent has joined #matf
- 13:00:12 [RRSAgent]
- logging to https://www.w3.org/2024/08/21-matf-irc
- 13:00:12 [Zakim]
- RRSAgent, make logs Public
- 13:00:13 [Zakim]
- please title this meeting ("meeting: ..."), JJ
- 13:00:17 [julianmka]
- julianmka has joined #MATF
- 13:00:21 [JJ]
- Zakim, this is MATF August 21, 2024
- 13:00:21 [Zakim]
- got it, JJ
- 13:00:31 [Detlev]
- Detlev has joined #matf
- 13:00:37 [JJ]
- Meeting: MATF August 21, 2024
- 13:00:40 [Detlev]
- present+
- 13:00:52 [Joe_Humbert]
- present+
- 13:00:56 [JJ]
- agenda+ Planning
- 13:00:58 [JJ]
- agenda+ 2.3.1 Three Flashes or Below Threshold
- 13:01:05 [JJ]
- agenda+ 2.4.3 Focus Order
- 13:01:10 [JJ]
- agenda+ 2.4.4 Link Purpose (In Context)
- 13:01:15 [JJ]
- agenda+ 2.4.6 Headings and Labels
- 13:01:28 [JJ]
- present+
- 13:02:00 [Aashutosh]
- Aashutosh has joined #matf
- 13:03:32 [GleidsonRamos]
- GleidsonRamos has joined #matf
- 13:03:48 [julianmka]
- present+
- 13:04:11 [JJ]
- regrets+ quintinb
- 13:04:52 [JJ]
- move to next agendum
- 13:04:52 [Zakim]
- agendum 1 -- Planning -- taken up [from JJ]
- 13:05:15 [Aashutosh]
- present+
- 13:05:34 [Karla]
- Karla has joined #matf
- 13:06:06 [JJ]
- Scribe: julianmka
- 13:07:10 [julianmka]
- JJ: Updates the group on Joe, Julian, and himself working identifying small variation SCs that we can move on from.
- 13:07:23 [Devanshu]
- Devanshu has joined #matf
- 13:07:45 [Karla]
- present+
- 13:08:26 [julianmka]
- 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.
- 13:08:31 [Devanshu]
- present+
- 13:08:37 [JJ]
- move to next agendum
- 13:08:37 [Zakim]
- agendum 2 -- 2.3.1 Three Flashes or Below Threshold -- taken up [from JJ]
- 13:08:37 [julianmka]
- JJ: Will be out in September, Joe will run meetings.
- 13:09:05 [Joe_Humbert]
- I will be facilitating the meetings, not "in charge" :-)
- 13:09:47 [Joe_Humbert]
- q+
- 13:10:42 [JJ]
- ack Joe_Humbert
- 13:10:51 [Detlev]
- Detlev has joined #matf
- 13:10:54 [julianmka]
- JJ: Summarizes current activity on this SC's github issue.
- 13:11:03 [Detlev]
- q+
- 13:11:14 [julianmka]
- Joe_Humbert: This will require guidance on testing.
- 13:12:27 [julianmka]
- Joe_Humbert: This might happen if devs create a custom animation. Regular OS animations already take this SC into consideration.
- 13:12:40 [GleidsonRamos]
- q+
- 13:12:48 [julianmka]
- JJ: Testing might be similar to ICT
- 13:12:48 [JJ]
- ack Detlev
- 13:13:57 [julianmka]
- Detlev: The WCAG SC defines "threshold" of 10 degree visual field. Can make testing more difficult.
- 13:14:49 [julianmka]
- Detlev: Only AAA conformance rules out any flashing that occurs more than 3x/second
- 13:15:50 [julianmka]
- Detlev: The size of the flashing area depends on device size so success/failure could vary.
- 13:16:16 [JJ]
- ack GleidsonRamos
- 13:16:22 [julianmka]
- JJ: Seems like applying is pretty direct but testing is more complicated.
- 13:17:32 [julianmka]
- julianmka has joined #MATF
- 13:17:42 [julianmka]
- GleidsonRamos: OS animations and transitions are within the SCs guidance, but Flutter and other cross-platform technologies allow animations that are much more disruptive
- 13:18:17 [julianmka]
- JJ: Had a recent experience where custom animations were quite busy and distracting.
- 13:18:43 [GleidsonRamos]
- q+
- 13:18:50 [julianmka]
- Detlev: Animation isn't flashing. Hasn't seen any transitions that include flashing.
- 13:18:51 [JJ]
- ack GleidsonRamos
- 13:19:03 [julianmka]
- JJ: Hasn't failed this SC, nor have colleagues.
- 13:19:46 [julianmka]
- 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.
- 13:20:20 [julianmka]
- Gleidson: Flashes occupied ~10% of screen
- 13:20:37 [julianmka]
- s/Gleidson/GleidsonRamos
- 13:21:37 [julianmka]
- JJ: In first draft, we can just say whether the SC applies as written. In follow-up versions, we can address testing.
- 13:21:37 [Joe_Humbert]
- q+
- 13:21:52 [JJ]
- ack Joe_Humbert
- 13:21:58 [julianmka]
- JJ: Would be helpful to have a failing example.
- 13:22:36 [julianmka]
- Joe_Humbert: Clarifies that the guideline applies but Note 1 in WCAG 2.2 needs to be tweaked to address mobile apps.
- 13:23:37 [JJ]
- move to next agendum
- 13:23:37 [Zakim]
- agendum 3 -- 2.4.3 Focus Order -- taken up [from JJ]
- 13:24:05 [Joe_Humbert]
- Joe_Humbert has joined #matf
- 13:24:08 [julianmka]
- present+
- 13:24:13 [Detlev]
- present+
- 13:24:16 [Joe_Humbert]
- present+
- 13:24:20 [GleidsonRamos]
- present+
- 13:25:30 [julianmka]
- JJ: Summarizes WCAG2ICT guidance and Github issue
- 13:26:21 [Joe_Humbert]
- q+
- 13:26:53 [Detlev]
- q+
- 13:27:06 [JJ]
- ack Joe_Humbert
- 13:27:09 [julianmka]
- JJ: There's always discussion of where focus order should begin, is auto-focusing on an input field okay
- 13:27:58 [julianmka]
- 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.
- 13:28:44 [julianmka]
- Joe_Humbert: This is a common accessibility issue at my company. Devs can do lots of things that compromise reading/focus order.
- 13:28:52 [julianmka]
- +1 to what Joe says
- 13:29:04 [julianmka]
- q+
- 13:29:30 [JJ]
- ack Detlev
- 13:29:42 [Aashutosh]
- q+
- 13:29:44 [karla]
- karla has joined #matf
- 13:29:47 [julianmka]
- @Detlev: Clarifies we are covering keyboard focus order in this SC
- 13:30:04 [julianmka]
- JJ: I've also seen this apply to other ATs like screen readers.
- 13:30:27 [Joe_Humbert]
- q+
- 13:31:03 [julianmka]
- Detlev: Are failures of this SC covered under 2.1.1 Keyboard focus or other SC also?
- 13:31:59 [julianmka]
- Detlev: As mentioned in this SC's Github issue, mobile keyboard navigation can shift from tab to arrow keys which can complicate things.
- 13:32:23 [Aashutosh]
- q-
- 13:32:40 [julianmka]
- @Detlev: Cites a developer who recently mentioned that keyboard support is hard and focus is on screen reader and touch-based ATs.
- 13:33:36 [julianmka]
- JJ: This SC includes a definition that explicitly cites keyboard interfaces - "navigated sequentially"
- 13:34:08 [julianmka]
- JJ: From a technical standpoint, Android has properties which can alter keyboard order. iOS has more robust full keyboard access in more recent version.
- 13:34:28 [julianmka]
- JJ: Cross-platform technologies like Xamarin, Flutter, etc. have much more limited support.
- 13:34:30 [JJ]
- q?
- 13:34:40 [JJ]
- ack julianmka
- 13:35:45 [julianmka]
- julianmka: Interprets this SC to include speech recognition -- emphasis on focus of interactive elements.
- 13:36:14 [JJ]
- ack Joe_Humbert
- 13:36:19 [Detlev]
- q+
- 13:37:06 [Jamie]
- Jamie has joined #matf
- 13:37:17 [Jamie]
- present+
- 13:37:45 [julianmka]
- 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?
- 13:38:04 [JJ]
- ack Detlev
- 13:38:13 [julianmka]
- JJ: Some questions over how broadly to apply this SC. Does intent only include keyboard?
- 13:38:28 [Jamie]
- q+
- 13:38:56 [julianmka]
- Detlev: AGWG seems to have some consensus that most members think that any screen reader focus would be reported 1.3.2 meaningful sequence.
- 13:39:33 [julianmka]
- Detlev: Example, related content that isn't grouped would be a minor failure of 1.3.2.
- 13:39:39 [JJ]
- ACTION: Link to AGWG consensus for 2.4.3 Focus Order / 1.3.2 Meaningful Sequence
- 13:40:10 [julianmka]
- Detlev: AGWG consensus seems to recognize 2.4.3 as applying primarily to keyboard.
- 13:40:27 [JJ]
- ack Jamie
- 13:42:09 [julianmka]
- 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.
- 13:42:15 [Detlev]
- +q
- 13:42:36 [JJ]
- ack Detlev
- 13:43:37 [julianmka]
- Detlev: Adding to Voice Control conversation -- it would fall under 2.1.1 keyboard operable.
- 13:43:52 [Jamie]
- q+
- 13:44:15 [julianmka]
- JJ: Do we need to reach consensus about which ATs fall under 2.4.3
- 13:44:18 [JJ]
- ack Jamie
- 13:46:05 [julianmka]
- Jamie: That seems like a WCAG decision, not just mobile. Should we be that specific?
- 13:46:33 [Joe_Humbert]
- q+
- 13:46:39 [julianmka]
- 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.
- 13:47:57 [JJ]
- ACTION: Define meaningful / meaning as intended in 1.3.2 Meaningful Sequence
- 13:48:12 [julianmka]
- 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.
- 13:48:14 [julianmka]
- @jamei
- 13:49:18 [julianmka]
- @Jamie: Might not be a MATF issue specifically, but iOS's keyboard functionality is more distinct from typical web keyboard interactions.
- 13:49:22 [Joe_Humbert]
- https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html
- 13:49:50 [julianmka]
- q+
- 13:50:05 [JJ]
- ack Joe_Humbert
- 13:51:02 [julianmka]
- Joe_Humbert: The understanding doc does talk about "meaningful" and gives examples.
- 13:51:57 [julianmka]
- 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.
- 13:52:33 [Jamie]
- +1 research to confirm AT and keyboard interface
- 13:52:50 [julianmka]
- JJ: As far as I know, ATs like switch and voice control do not hook into key events in iOS.
- 13:53:35 [JJ]
- q?
- 13:53:35 [julianmka]
- JJ: We could add a definition where we explain thinking behind including other ATs with keyboard, or substitute "assistive technologies" for "keyboard"
- 13:53:37 [JJ]
- ack julianmka
- 13:53:45 [Jamie]
- +1 JJ
- 13:54:47 [JJ]
- julianmka: Brings up that default focus order should not be a fail?
- 13:54:52 [Joe_Humbert]
- +1 to default focus order is not a fail.
- 13:54:59 [Jamie]
- +1
- 13:55:24 [julianmka]
- JJ: Need to define what "default" means in context of focus order.
- 13:55:36 [Joe_Humbert]
- Apple seems to mess with default VoiceOver focus/reading order in different versions of iOS
- 13:56:08 [Detlev]
- q+
- 13:56:16 [Jamie]
- q+
- 13:57:01 [JJ]
- ACTION: Definition for 'keyboard interface' in apps, perhaps replace it with 'assistive technologies'
- 13:57:21 [JJ]
- ACTION: Define what "default" means in context of focus order
- 13:57:29 [julianmka]
- julianmka: We could include a best practice to keep consistent focus order practices across an app, if you do choose to force focus.
- 13:57:53 [Jamie]
- +1 @detlev question
- 13:57:55 [julianmka]
- Detlev: Doesn't want to lose sight of the keyboard aspect of this SC.
- 13:58:24 [julianmka]
- Detlev: If we refer to "assistive technologies" does that mean we're no longer concerned with keyboard?
- 13:58:27 [Jamie]
- ie could keyboard be replaced with other AT like Voice Control
- 13:58:34 [Joe_Humbert]
- +1 to noting what detlev said is some definition or note
- 13:59:13 [julianmka]
- JJ: Could also look at other standards like 508, EN 301 549 to see how they hand keyboard vs other ATs
- 13:59:33 [Jamie]
- Full keyboard access is AN at
- 13:59:33 [julianmka]
- Detlev: Would be quite unusual to class keyboard as an AT. It's a mode of input.
- 13:59:40 [JJ]
- q?
- 13:59:45 [JJ]
- ack Detlev
- 13:59:47 [JJ]
- ack Jamie
- 14:00:47 [julianmka]
- 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.
- 14:00:58 [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)
- 14:02:15 [julianmka]
- 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"
- 14:02:24 [Detlev]
- +1 to Jamie reg. consistent navigation
- 14:02:39 [julianmka]
- JJ: Lots more to discuss here, let's keep it going in Github issues.
- 14:20:54 [JJ]
- JJ has joined #matf
- 14:21:04 [JJ]
- present+
- 14:21:05 [JJ]
- Zakim, list participants
- 14:21:05 [Zakim]
- As of this point the attendees have been Carolina, Detlev, Joe_Humbert, JJ, julianmka, Aashutosh, Karla, Devanshu, GleidsonRamos, Jamie
- 14:21:12 [JJ]
- rrsagent, make minutes
- 14:21:13 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/08/21-matf-minutes.html JJ
- 14:21:36 [JJ]
- rrsagent, bye
- 14:21:36 [RRSAgent]
- I see 4 open action items saved in https://www.w3.org/2024/08/21-matf-actions.rdf :
- 14:21:36 [RRSAgent]
- ACTION: Link to AGWG consensus for 2.4.3 Focus Order / 1.3.2 Meaningful Sequence [1]
- 14:21:36 [RRSAgent]
- recorded in https://www.w3.org/2024/08/21-matf-irc#T13-39-39
- 14:21:36 [RRSAgent]
- ACTION: Define meaningful / meaning as intended in 1.3.2 Meaningful Sequence [2]
- 14:21:36 [RRSAgent]
- recorded in https://www.w3.org/2024/08/21-matf-irc#T13-47-57
- 14:21:36 [RRSAgent]
- ACTION: Definition for 'keyboard interface' in apps, perhaps replace it with 'assistive technologies' [3]
- 14:21:36 [RRSAgent]
- recorded in https://www.w3.org/2024/08/21-matf-irc#T13-57-01
- 14:21:36 [RRSAgent]
- ACTION: Define what "default" means in context of focus order [4]
- 14:21:36 [RRSAgent]
- recorded in https://www.w3.org/2024/08/21-matf-irc#T13-57-21
- 14:21:41 [JJ]
- zakim, bye
- 14:21:41 [Zakim]
- leaving. As of this point the attendees have been Carolina, Detlev, Joe_Humbert, JJ, julianmka, Aashutosh, Karla, Devanshu, GleidsonRamos, Jamie
- 14:21:41 [Zakim]
- Zakim has left #matf