Overhaul accessibility

[superhighfives]

Is your feature request related to a problem? Please describe. This was initially brought up in https://github.com/superhighfives/pika/issues/18, which shows one example of how the accessibility of the app needs work.

Describe the solution you'd like The app should be:

• Keyboard navigable (tabbing, left and right to move between foreground and background, etc)
• Appropiately labelled (for voiceover)

Additional context It currently looks as though https://developer.apple.com/documentation/appkit/nscolorsampler doesn't support keyboard for picking a colour which is a shame. This is tangentally related to #8.

Apple covers some of the implementation details of accessibility in SwiftUI in their WWDC videos, which has some great examples: https://developer.apple.com/videos/play/wwdc2019/238/

[rpkoller]

I've tested to navigate the app with voiceover and the keyboard. if you navigate to the background color by tabbing ctrl-option- arrow right and voiceover announces background #ffffff button and you press copy c then voiceover announces copy foregroundand you have the foreground color in the pasteboard instead of the expected #ffffff

tested with pika 0.0.13 and macos 12.6.1

and while i was looking up my pika version i've noticed the cheatsheet in the about window stating that copying the foreground color is cmd c while copy the background is shift command c . that is something you dont know as a screenreader user and i am unsure if someone would go through the app to look for the key settings actually there. without knowing those keyboard shortcuts i consider those key combinations quite challenging for none sighted users. i mean if you you navigate through the interface to reach a component like the background field then the cmd c key combination should be universally just copy to pasteboard and not fixed on copying one of the two colors. altering the standard behavior might be a potential source of confusion for people.

[superhighfives]

Hey @rpkoller—appreciate you taking the time to write this up. I'm working on a PR that will allow the app to be run as a standard app, rather than a menu bar only one, and that will mean the options for keyboard shortcuts, etc, will be featured in the standard top menu. That should make keyboard shortcuts more accessible.

That said, I would love some help with improving the accessibility of the app, especially as I'm not as confident with the accessibility features of SwiftUI. If anyone is looking for an issue to pick up and wants to make a PR, I'd love to check it out. I've added a help wanted tag to this issue.

[rpkoller]

thanks you @superhighfives and apologies for the late reply. i agree on one hand making the keyboard shortcuts available in the main menu makes them more prominent and easier to access. but never the less cmd-c is in the muscle memory for people to copy anything into the clipboard. altering the scope for the cmd c command that it only copies and pastes a specific color into the clipboard might be counter intuitive. so not sure if making the keyboard shortcut more prominent would solve the problem.

and in regards of help. i am unfortunately not a developer. the only thing i could provide is input from an ux and a11y perspective as well as do some testing.

[superhighfives]

Thanks @rpkoller—appreciate the additional context. Just to clarify, what would you expect to happen, pressing cmd-c?

[rpkoller]

good question. i would expect that cmd-c just copies the active element in focus. one way to tackle might be in case the background is active and you press cmd-c the background color is getting copied (and you are already correctly announcing that the background is copied - maybe make it a bit more explicit and clear and announce background color copied, that way it announces which task was successfully finished - currently it just states copy background). and if you wanna stick with the invert pattern if you press shift-cmd-c then the foreground gets copied. if the foreground is active the other way around. that way in case some forgets about the inversion the person is always able to copy the active element. currently that isn't possible if the background is active and the user presses cmd-c.

[superhighfives]

Yeah, I hear you. By focus, were you meaning within Voiceover?

Currently outside of Voiceover, Pika doesn't really have a concept of an active state for foreground or background, with the exception of when you're picking a colour—that uses an Apple API that doesn't allow other actions to be performed at that time. That said, I've just spent some time navigating around in Voiceover and there's definitely improvements to be made to the labels. I'll have a think about the idea of having different copy actions on focus in Voiceover, too—I'll need to do some research into how SwiftUI focus states work within something like Voiceover. 🤔

[superhighfives]

I have a beta that allows you to choose between using Pika as a menubar app and Pika as a standard app, in Preferences. Curious if this makes things better from an accessibility point of view, given the standard app has a standard macOS menubar.

https://github.com/superhighfives/pika/releases/tag/0.0.14-beta1

(You can either download it above, or run "Check for updates..." in Pika with "Subscribe to beta releases" enabled in the Preferences.)