search

w3c / matf

Other
5 stars 0 forks source link

Success Criterion 2.1.1 - Keyboard - Level A #12

Open detlevhfischer opened 1 month ago

detlevhfischer commented 1 month ago

Looking at the EN 301 549 clause 11 Software which we use as the baseline for testing native mobile apps with the BIK app test, keyboard operability is required (even though it is a far less common usage scenario compared to desktop apps). Apps run on tablets, which can have a physical keyboard attached (via bluetooth, USB, or even purpose-made like Apple's Magic Keyboard for the iPad). In practice we encounter many issues when testing apps with a keyboard, the most frequent being:

So these issues may require separate issue enties under 2.4.3, 2.4.7, 1.4.11 and so on. I just put this here to get a feeling whether people recognise this situation, and how they deal with it in their consulting / testing practice (short of saying: "well, we think keyboard is not applicable for mobile apps").

AlainVagner commented 1 month ago

I agree with this description of the issue. We also test mobile apps with an external keyboard in our reference framework in Luxembourg. The usage of a keyboard with mobile apps may be limited, but it opens the gates to other devices such as switchs, which emulate keystrokes. On iOS, we configure the keyboard with the setting "full keyboard access" activated. On Android, we only test with Switch Access installed and activated.

julianmka commented 1 month ago

At CSUN, there was a presentation about keyboard testing on mobile: Keyboard accessibility testing on mobile devices

jamieherrera commented 1 month ago

A big challenge for iOS and iPad currently is that Ctrl+tab, which is the only way to move through some content, is not prominent on the Full Keyboard Access instructions in the Settings. I have an open ticket with Apple https://developer.apple.com/forums/thread/747458

audreymaniez commented 1 month ago

It seems that there are two possible keyboard navigation modes on mobile, with and without accessibility services.

Keyboard navigation without accessibility services is convenient for people who don't require adaptation but who, for some reason, prefer to navigate/enter text with a physical keyboard rather than a virtual one, for example.

But, as is well described in the first place, without accessibility services enabled, it's seemingly impossible for a motor-disabled user to interact with interfaces.

For example, switch access on android, is an accessibility service that enables operation of any device that falls into the contactor category (the keyboard is a contactor, volume up/down keys etc.). Whatever the device, it's the fact of interacting with an external device that's taken into account, and it's the switch access service that allows them to activate the platform's accessibility features.

I don't know whether a motor-disabled person navigating with a keyboard without activating such an accessibility service can/should be considered as a use case ? and should be tested ?

detlevhfischer commented 1 month ago

It seems that there are two possible keyboard navigation modes on mobile, with and without accessibility services.

Our line in our test procedure for 2.1.1 (or EN 11.2.1.1) is similar to 2.1.1 for web where testing happens without accessibility services (i.e. screen readers VoiceOver or TalkBack) activated. There was a time where you had to activate VO on iOS to be able to use the keayboard at all, but now we just ensure that Accessibilty > Keyboards > Full keyboard Access is activated.

without accessibility services enabled, it's seemingly impossible for a motor-disabled user to interact with interfaces.

This is interesting - have you got examples of apps and switch access where that could be investigated / verified?

jha11y commented 3 weeks ago

The usage of a keyboard with mobile apps may be limited, but it opens the gates to other devices such as switches, which emulate keystrokes.

To my knowledge, keyboard and switch access are separate and not reliant on one another for native mobile content. Switch Access on iOS/iPadOS preceded Full keyboard access or access with a keyboard with VoiceOver off on iOS by many years.

I believe keyboard testing and access is important for native mobile content, but less important than it is on desktop. Also, many of the issues described are possibly OS issues that developers can only possibly attempt to fix. Apple and Google need to do better.

detlevhfischer commented 1 week ago

@AlainVagner

I have just corrected this comment since I found the setting "Use on-screen keyboard" after all...

I followed your link to switch access to understand why you enable that for keyboard testing (so far I have tested by just connecting a physical keyboard via USB-C). The Android documentation seems to be severely out of date: the page Set up Switch Access for Android has a Step 2: Enable the on-screen keyboard refering to settings in Android 7.0 or later which don't seem to exist in that form in the current Android version 14 (no surprise perhaps).

In Android 14 I go to System > Keyboard > Physical keyboard > Use on-screen keyboard

But may I ask what makes you think keyboard testing needs to rely on Switch access activated? Is that still current information?

audreymaniez commented 1 week ago

Maybe we don't all talk about the same kind of "keyboard"?

"Keyboard" is not just the physical keyboard, but it's about any interface that generates the same events as a keyboard (without being a physical keyboard), as can do all kind of switches (buttons/face/volume button). Contactors other than physical keyboards can hardly, if ever, interface directly with Android without going through switch access (or another accessibility service).

So, is testing only with a physical keyboard without accessibility service is sufficient to be sure that each kind of "keyboard interaction" is covered by the criteria?

As @detlevhfischer pointed, settings for keyboard control as evolve on android, maybe testing differences between two modes of operations on a control app (with and without switch access) can help understand today if there are real differences between the two modes for the keyboard only?

jamieherrera commented 1 week ago

@Audrey “Full keyboard access” is an accessibility service in Apple devices.

It will be relevant to mention voice access/ voice control at the very least to identify what part it plays as an alternative to the accessibility expectations for a physical keyboard on mobile and tablet devices.

On Tue, Jul 2, 2024 at 6:34 AM Audrey Maniez @.***> wrote:

Maybe we don't all talk about the same kind of "keyboard"?

"Keyboard" is not just the physical keyboard, but it's about any interface that generates the same events as a keyboard (without being a physical keyboard), as can do all kind of switches (buttons/face/volume button). Contactors other than physical keyboards can hardly, if ever, interface directly with Android without going through switch access (or another accessibility service).

So, is testing only with a physical keyboard without accessibility service is sufficient to be sure that each kind of "keyboard interaction" is covered by the criteria?

As @detlevhfischer https://github.com/detlevhfischer pointed, settings for keyboard control as evolve on android, maybe testing differences between two modes of operations on a control app (with and without switch access) can help understand today if there are real differences between the two modes for the keyboard only?

— Reply to this email directly, view it on GitHub https://github.com/w3c/matf/issues/12#issuecomment-2203181091, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI6TQ7OO7MIZFNITUPWIKZTZKKT7FAVCNFSM6AAAAABIDJQ2DOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBTGE4DCMBZGE . You are receiving this because you commented.Message ID: @.***>

detlevhfischer commented 1 week ago

@audreymaniez I am aware that "keyboard" is not just the physical keyboard but also an interface for assistive technology.

What I would like to see (or have examples for) are issues that can be detected with switch access enabled that keyboard testing without switch access enabled would miss. This would be important to know for practical reasons - if testing all app elements / functions just with the keyboard would catch operability issues for AT (like switch access or voice access) as well, this would greatly simplify testing.

audreymaniez commented 1 week ago

Totally agree. I can try on my side to find relevant applications to test and document if there are differences with accessible services on android or not.

AlainVagner commented 1 week ago

@detlevhfischer With switch access enabled on Android, we had 3 years ago really less issues with the focus indicator visibility IIRC. Things may have improved in the mean time. We need to test this with more recent versions of Android.

detlevhfischer commented 1 week ago

@AlainVagner

we had 3 years ago really less issues with the focus indicator visibility

Ah, I see. The default kb focus indicator is still poor (light grey tint, I believe around 1.5:1) but assuming it is visible at all, that doesn't affect checking whether interactive controls can be fully operated in either mode (switch access on or off). And that is what I am getting at.

qbalsdon commented 4 days ago

When content can be operated through a keyboard or alternate keyboard, it is operable by people with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as by people who must use alternate keyboards or input devices that act as keyboard emulators. Keyboard emulators include speech input software, sip-and-puff software, on-screen keyboards, scanning software and a variety of assistive technologies and alternate keyboards. Individuals with low vision also may have trouble tracking a pointer and find the use of software much easier (or only possible) if they can control it from the keyboard. Reference

Given the amount of flexibility provided by a Keyboard interface, and the opportunity to create other forms of inputs (switches, game controllers - Not necessarily for games, but a person with limited mobility might use a controller as assistive technology) I think it's important to retain this criteria in the Mobile CAG. Mobile operating systems are not limited to small form factors and are often paired with physical keyboard cases. I believe it would be an unhelpful move to be relaxed on this case.

Jetpack compose (Android) is not great at Keyboard shortcuts and it's clearly something that the industry is not familiar with.

I wonder why the Keyboard in the Evinced MCAG was left out - would be great to find out why

jha11y commented 4 days ago

As I have commented before, On both iOS and Android other forms of input (particularly Voice and switch access plus anything that uses switch emulation) does not require keyboard accessibility for native apps. This is different from desktop where everything is tied into the keyboard.

on iOS switch control was introduced in iOS 7 (ref: https://medium.com/gettecla/what-is-switch-control-mode-in-apples-ios-811cc2f0cec8), Full keyboard access was release in iOS 13.4 (ref: https://developer.apple.com/videos/play/wwdc2021/10120/) before that there was some keyboard support in iOS 9.

I think switch access on Android was supported from Android 5 lolipop, but I'm having trouble confirming.

qbalsdon commented 4 days ago

@jha11y Please help me understand, are you saying we shouldn't have a keyboard SC for mobile? Or limit it in some way?

Or perhaps that it's not graded at the same level? Like not A, but AA?

I understand that Switch and Voice do not require keyboard input, but wouldn't they also benefit from Keyboard?

jha11y commented 4 days ago

@qbalsdon definitely not. Saying that we might need to either expand this to include other input methods or have a separate requirements for non-keyboard input.

I just saw posts in this ticket that said other inputs like Voice or switch access/control may rely on keyboard access (like desktop), but that is not the case for iOS or android. Switch access seems to be what many other not keyboard, other inputs use to interact with mobile apps not the keyboard.

This makes sense especially on iOS where switch access predates keyboard access. Particularly the way SC 2.1.1 refers to keyboard access and how desktop keyboard access work and provides for other input types

qbalsdon commented 2 days ago

@jha11y Thanks for the clarification - I'm in 100% agreement! "Multiple ways" can be applied in... well... multiple ways! 🤣