search

w3c / matf

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

Accessibility of elements hidden by default #72

Open detlevhfischer opened 1 month ago

detlevhfischer commented 1 month ago

Hi all In an app audit the question came up when looking at a chat view if a hidden reply icon (revealed via a swipe right or a long press on a chat entry) could be considered conformant. I am not sure myself. So each chat entry has the option to be quoted in the reply. From the point of view of ease of reading and keeping the total view, the sequence of entries, uncluttered, it is understandable that the function [reply to this entry] is one that is revealed rather than being permanently available via a more menu or a dedicated icon under each entry. What do you think?

I have started a discussion here as a main WCAG github discussion (because the question is not really app-specific, the content actually being in a web view) and would really appreciate your thoughts! https://github.com/w3c/wcag/discussions/4110

julianmka commented 1 month ago

Posting my comment here since I'm specifically addressing the native mobile experience.

Actions revealed on swipe or long-press is a pretty common pattern at this point, particularly in the context of chat and texting apps (thinking of Discord, Signal, WhatsApp, iMessage, Google Messages, Facebook Messenger, and others, although of these only 1 or 2 actually make the hidden actions easily accessible via AT). I think the discoverability issue you identify is something common to the hidden action pattern as a whole. I'm not sure that users not knowing an action exists is so much an accessibility problem as a usability one.

We know that WCAG isn't really concerned with the general usability of things. There are numerous ways to build a WCAG-conformant but unusable experience. No doubt, discoverability is a weakness of hidden actions, but that's an issue that affects everyone, not only people with disabilities. (And, depending on how the actions are exposed to ATs, some AT users might be at an advantage, in that they are informed of "actions available"/shown the actions on select with switch control/etc. when other visual affordances are lacking.) I wouldn't fail an app that did this, provided that the actions could be unambiguously executed using the device's on-board ATs.

I just spent a few minutes exploring Discord, Google Messages, Facebook Messenger, and Signal (all on Android 14). Signal probably came the closest in terms of exposing the context/reply menu and emoji reactions with TalkBack, Voice Access, and switch control, but the TalkBack experience in particular was lacking. I would fail all of them under 2.5.1/2.5.7.

BUT with appropriate use of the mobile platforms' accessibility APIs, this pattern can absolutely be made accessible. I would say that this pattern is a risky choice in that there are many ways to fail to make it accessible without due diligence, but it's not impossible, nor is it an automatic failure.

JJdeGroot commented 1 week ago

I think the discoverability issue you identify is something common to the hidden action pattern as a whole. I'm not sure that users not knowing an action exists is so much an accessibility problem as a usability one.

I would say this part is key: do users with disabilities / users of assistive technologies have an equal experience? In this case, I would say the experience is equal. The actions are hidden for everyone.

They DO need to be accessible for everyone though, probably through custom accessibility actions.

Related video: Making Apps More Accessible With Custom Actions

And what we talked about our VoiceOver and Switch Control in our demos today, custom actions can be leveraged across many of the assistive technologies we ship including full keyboard access and voice control which are new this year.

The pattern also relates to the iOS TableView pattern where you have to swipe to reveal actions such as delete, which are also available through custom accessibility actions.

Code samples Android: https://appt.org/en/docs/android/samples/accessibility-action Compose: https://appt.org/en/docs/jetpack-compose/samples/accessibility-action iOS: https://appt.org/en/docs/ios/samples/accessibility-action SwiftUI: https://appt.org/en/docs/swiftui/samples/accessibility-action

detlevhfischer commented 1 week ago

I agree that hidden stuff is a problem for all. Thanks for your replies, @julianmka and @JJdeGroot !

Just as a side note: While in the chat of the app I referred to, the reply function for each message is available to pointer users (who know it's there, and swipe or long-press), and actually available as custom action to SR users (so it's actually easier to discover for them than for sighted users), it is not in any way keyboard accessible. I guess it would pass (11).2.1.1 Keyboard if the hidden action would 'slide in' and then be actionable when tabbing or arrowing through the chat log messages. Is this something that would be awkward or difficult to implement, or is it easily doable?