Success Criterion 2.1.4 - Character Key Shortcuts - Level A

[JJdeGroot]

Discussion:

15 April 2024

[Source](https://www.w3.org/2024/04/15-matf-minutes.html#t05) How to test single key shortcuts? JJ: this is specifically how do we test this in apps? and how do people do it in websites? I also don't know how you would do it on websites? JJ: there are some default ways in iOS to find out Rachele: for web there are bookmarklets that press all the keys for you, that seems not possible for apps QuintinB: I'm working on figuring out how to test this QuintinB: it is hard to find out discover shortcuts Joe: there are tools to emulate keyboard, that may theoretically be possible, not sure if realistic JJ: this is the Accessibility Scanner app by Google. which runs an accessibility service Some other options in web - look for shortcut instructions in the content, check the code for keydown, keyup and keypress listeners, and of course press all the keys hdv: Rachele's strategy of using bookmarketls is smarter, would recommend that, but if all fails you could manually press all the keys, that should work for apps too JJ: could be cumbersome JJ: we probably want to write an understanding-doc for testing success criteria for apps with one or more ways to test a criterion JJ: on web auditors can look at the source code for answers, with apps you can't unless you are given access to the source code JJ: maybe something to discuss in the next meeting Mick Keane: my experience is that I don't have access to the source code usually, and this is the most challenging part JJ: when I audit I don't use the source code JJ: equivalent to bookmarklets for websites would be automated testing, eg generic code to send key commands etc and apply this to any app… maybe interesting to build some kind of repository with some automated options Create a decision tree to guide testing methods? hdv: maybe solution to source code vs not would be: you can never audit based on source code, because what you're testing is the UI that exists when the source code result is executed I think we need to be careful will only end result testing. For things like roles in accessible names. End user result can be almost the same hdv: you'd always need to test what the user sees, not what the source code in theory would do If you want to check out some of what I am doing for keyboard testing: https://www.ally-keys.com thank Quintin Joe_Humbert right, but if there's a difference, wouldn't you need to test the result instead of the source code? yes. Just need to be careful. Not disagreeing with you

1. Testing Single Key Shortcuts in Apps:

• JJ: Raised the question of how to test single key shortcuts in apps and websites.
• Rachele: Mentioned the use of bookmarklets for web testing, which may not be possible for apps.
• QuintinB: Working on figuring out a method for testing; highlighted the difficulty in discovering shortcuts.
• Joe: Suggested tools to emulate keyboard actions could be theoretically possible but questioned their practicality.
• JJ: Mentioned the Accessibility Scanner app by Google, which runs an accessibility service.

2. Testing Strategies for Web:

• JJ: Suggested looking for shortcut instructions in the content, checking the code for keydown, keyup, and keypress listeners, and manually pressing all keys.
• hdv: Supported Rachele’s strategy of using bookmarklets for the web and recommended manual key pressing for apps if other methods fail.

3. Documentation and Decision Tree:

• JJ: Proposed creating an understanding-document for testing success criteria in apps, outlining multiple ways to test each criterion.
• JJ: Noted that web auditors can look at the source code for answers, which is not possible for apps without source code access.
• Mick Keane: Shared that lack of access to source code is a significant challenge.
• JJ: Discussed the potential for automated testing tools to send key commands to apps, suggesting the development of a repository for automated options.
• hdv: Emphasized the importance of testing the UI that users interact with, rather than relying solely on source code.

4. End Result vs. Source Code:

• Joe_Humbert: Cautioned against focusing only on end result testing, as it may not fully capture roles and accessible names. Emphasized the need to test the result seen by users.
• hdv: Agreed on testing user-visible results rather than theoretical source code behavior.
• QuintinB: Shared a resource for keyboard testing: ally-keys.com

[AlainVagner]

For mobile apps, we test this SC with an external keyboard. Once the external keyboard is properly configured (full keyboard access on iOS, switch access on Android), we try most of the characters we can input with a keyboard such as a-z, A-Z, 0-9 and symbols and check if an action is done on the app. If something happens on the app, we then check if there is a way to disable or configure the shortcut. (a machine translation of our test)

[iadawn]

Possibly stupid question, but what are the use cases for keyboard shortcuts on a mobile app?