Success Criterion 2.4.1 - Bypass Blocks - Level A

[JJdeGroot]

Discussion:

15 May 2024

[Source](https://www.w3.org/2024/05/15-matf-minutes.html#t03) ## 2.4.1 Bypass Blocks JJ: This is also an exception in section 508 and EN standards JJ: Yes for applicable to mobile web, and Yes but different to web for applicable to mobile native. JJ: Note from Joe: semantic markup, navigation methods (screen reader). We would need to push on google to provide better keyboard support a la iOS full keyboard access JJ: Note form Alain: Should we also mention iOS containers JJ: Apple does this in the navigation bar. But still not sure if you can jump via shortcuts from container to container @JJ: In the discussion column: The Section 508 standards for software list as an exception.​​​​​​​​​​​​​​​ However can still be done and could be merit in doing so. CC: We usually have tab bar navigations with 4-5 tabs for native and hamburger menus on mobile web. I don't think a bypass block is needed in those cases. JJ: In native there is not much buttons in a navigation bar, and less tabs in a tab bar - less need to skip content. Jamers: I'm looking at the WCAG content and it says "Small repeated sections such as individual words, phrases or single links are not considered blocks for the purposes of this provision." https://www.w3.org/WAI/WCAG22/quickref/?showtechniques=241#bypass-blocks Jamers: Native apps versus native screens conversations needs to happen. set of native apps vs set of native app screens Joe_Humbert: In the success criteria they have sufficient techniques that reference landmarks and headings. JJ: Landmarks would be similar to containers JJ: Frame techniques and hamburger menus would also apply to mobile web. Jamers: Why are we not considering sets of native screens in the same way as web pages on a website? JJ: I'm not sure either. We can get this as a topic for the next meetings. a+ AlainVagner: For me this has strong impact on Multiple Ways. Multiple ways on a set of screens I get, but not so much a set of apps. So this could effect many criteria. JJ: It will effect at least 4 success criteria.

1. Applicability to Mobile Platforms:

• JJ: Highlighted exceptions in Section 508 and EN standards, affirming applicability to both mobile web and native platforms with some distinctions.

2. Navigation Methods and Semantic Markup:

• Joe: Emphasized the importance of semantic markup and navigation methods, suggesting improvements in keyboard support for native platforms.
• AlainVagner: Raised a question regarding mentioning iOS containers and their role in bypassing blocks.

3. Native App Navigation Patterns:

• CC: Shared insights on navigation patterns in native apps, noting fewer buttons in navigation bars and tabs in tab bars, which might reduce the need for bypass blocks.
• Jamers: Advocated for discussions on distinguishing between sets of native apps and sets of native app screens, similar to web pages on a website.

4. Success Criteria and Techniques:

• JJ: Discussed the relevance of landmarks, headings, frame techniques, and hamburger menus in addressing bypass blocks, both for mobile web and native platforms.
• Joe_Humbert: Pointed out sufficient techniques referencing landmarks and headings in the success criteria.

5. Future Topics:

• Jamers & JJ: Proposed exploring the concept of sets of native screens and its impact on accessibility criteria in future meetings.
• AlainVagner: Highlighted the potential impact on multiple success criteria due to considerations of bypass blocks in sets of screens or apps.

[jamieherrera]

I suggest we define "blocks of content" or "repeating content" that would NEED to have a mechanism to bypass some repeated content but not others.

The ACT rule on this topic is helpful to compare the intent of web to the intent of a native mobile version, to better understand applicable "mechanisms" and any notes we might want to add to our version: https://www.w3.org/WAI/standards-guidelines/act/rules/cf77f2/proposed/

For consideration: the mobile web experience often collapses keyboard-tabbable header content into a single menu icon. That is mentioned in the ACT rules a way to bypass content in web; would a menu that is always collapsed in native automatically meet this SC?

potential variation for native: One thing I see much more in apps than in websites is when the navigation content is at the bottom of a screen; should our Bypass Blocks point out that users should have a way to get to this content without requiring an interaction with every interactive item in the main View? The ACT rule above explicitly excludes that scenario based on desktop keyboard shortcuts but in native, access TO the repeated content sometimes is more challenging than trying to avoid it.