search

w3c / matf

Guidance from the Mobile Accessibility Task Force (MATF)
https://w3c.github.io/matf/
Other
8 stars 3 forks source link

Success Criterion 2.4.3 - Focus Order - Level A #35

Open JJdeGroot opened 4 months ago

JJdeGroot commented 4 months ago

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#focus-order

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

Keanem6 commented 3 months ago

I think it applies as written in terms of requirements. But i do think it's worth what's expected from the basic keystrokes for iOS and Android, and certain patterns, such as where focus should land when navigating to new views/screen, selecting back buttons, closing modals...etc.

arctouch-gleidsonramos commented 3 months ago

Remembering that the recommendation for both iOS and Android is that the focus order not be changed programmatically, and that this must be planned by design.

jamieherrera commented 3 months ago

This sc is in the top 5 most filed at my company (in both web and mobile) but also most cancelled; "meaningful" could have a note (also apply to 1.3.2 meaningful sequence) to clarify what makes this SC not met, where "meaningful" is maybe more broadly applied in native mobile. I'm not as well-versed in the functional ability in native code to alter the tab order; I do know that custom components need to be made keyboard accessible otherwise they may be skipped entirely. I don't think this SC needs to bend to current Apple or Android limitations, but rather include that a default focus order is not a fail.

JJdeGroot commented 3 months ago

Discussed in today's meeting.

21 August 2024 [Source](https://www.w3.org/2024/08/21-matf-minutes.html#t03) 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. +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. https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html 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. +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" +1 JJ julianmka: Brings up that default focus order should not be a fail? +1 to default focus order is not a fail. +1 JJ: Need to define what "default" means in context of focus order. 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. +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? ie could keyboard be replaced with other AT like Voice Control +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 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. 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" +1 to Jamie reg. consistent navigation JJ: Lots more to discuss here, let's keep it going in Github issues.