Discussed in today's meeting.

21 August 2024

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.

<Joe_Humbert> 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?

<Joe_Humbert> +1 to default focus order is not a fail.

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.

+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

<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

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.

ACTION 1: Link to AGWG consensus for 2.4.3 Focus Order / 1.3.2 Meaningful Sequence (@detlevhfischer)
ACTION 2: Define what "default" means in context of focus order

Success Criterion 2.4.3 - Focus Order - Level A #35

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions