Success Criterion 2.4.5 - Multiple Ways - Level AA

[JJdeGroot]

Discussion:

MATF meeting on June 12, 2024

[Source](https://www.w3.org/2024/06/12-matf-minutes.html#t02) https://w3c.github.io/wcag2ict/#multiple-ways if you have comments on that put yourself on queue with p+ in an app we are normally dealing with processes / flows JJ: discussing differences between web and app - does 2.4.5 really aplly to mobile apps JJ: is that desirable that there are multiple ways Alain: when you have navigation but often no additional search function or site map … could sometimes be applied to mobile applications … it is an exception in the EN Section 508 standards for software also list WCAG 2.4.5 as an exception. explaining why 2.4.5 as well as consistent id and consistent nav are not covered in our BIK test procedure JJ: the new ADA has no exception for 2.4.5 for apps JJ: hinges on what is considered a process in an app Rachele: Losts of apps have a tab bar - they are nto discrete entities but pare of a whole - so probably does not apply Mick: we look at it as a flow - users can find it difficult to get back Jamie: web versions of processes such as a financial transfer - is it considered the same thing in an app and thus a good example for a set of pages / screens? Good to identify the processes we see to check whether they are equivalent JJ: agree, will help to see examples of processes JJ: Tries to set up a meeting with someone from theWCAG2ICT TF to discuss examples of "sets of software" JJ: will link into GitHub issues

Summary:

1. Applicability of WCAG 2.4.5 to Mobile Apps:

   • JJ: Raised the issue of whether WCAG 2.4.5 (Multiple Ways) applies to mobile apps, given that apps typically deal with processes and flows rather than traditional web navigation.
   • Alain: Pointed out that while navigation is present in apps, they often lack additional search functions or site maps. Mentioned this as an exception in EN standards.
   • Mick: Noted that Section 508 standards for software list WCAG 2.4.5 as an exception, explaining its exclusion from the BIK test procedure.
   • Rachele: Commented that many apps use a tab bar which integrates various functions into a whole, suggesting that 2.4.5 might not apply.

2. Navigation and Process Flows in Mobile Apps:

   • JJ: Discussed the desirability and practicality of having multiple ways to navigate in apps.
   • Jamie: Brought up the example of financial transfers in web and app environments, questioning whether they should be considered the same in terms of process flows.

3. Identifying Equivalent Processes:

   • Jamie: Emphasized the importance of identifying processes in both web and app contexts to determine their equivalence.
   • JJ: Agreed, stating that identifying and examining examples of processes would be helpful.

4. Coordination with WCAG2ICT Task Force:

   • JJ: Suggested setting up a meeting with someone from the WCAG2ICT Task Force to discuss examples of "sets of software" and their applicability.
   • JJ: Plans to link the discussion into GitHub issues for further collaboration and tracking.

[jamieherrera]

Coming back to this, I think there's definitely a use case for requiring an alternative way to access information for some types of apps.

The SC may not actually be much different than web, so we wouldn't need that much of a variation.

1. Assuming we get a working definition for "set of app screens" that can stand alone apart from the impractical "set of apps", the applicability of Multiple Ways to apps as worded in WCAG now would only apply within this subgroup of "set app screens".
2. The many processes that are part of the native app experience would be exceptions. For example, if "set" means screens that share the same navigation bar, this may be just "high level" screens that are also available in a menu; every screen that has a back button is (likely) part of a process.

In that sense we can have a 2.4.5 Multiple Ways SC that actually applies to users in a single app, but also acknowledge that it exists for high-level navigation only.

Applicable examples of "more than one way":

• menu: most apps already have this
• Search: The search mechanism is a key feature in some apps, but would not make sense in others: I can think of several apps where a seach function is the primary way I find things, followed by the default setup . Instagram, Facebook, NPR etc use Search.
• Tab Bar: Other apps definitely have a tab bar option to find sections of content (maybe not an individual screen, but definitely main sections as part of this "sets of app screens", in addition to a possible tile on a "home" screen.