You can now fully operate SpeakerClock with no or low vision. We gave SpeakerClock the full Accessibility treatment. In this article I describe some of the things I learned adding accessibility features to SpeakerClock, now that it is fully written in SwiftUI.
SpeakerClock’s UI is divided into 3 sections, the presets at the top, the LED timer as big as possible in the center and the phase “traffic light” at the bottom.
The main interaction gesture is to horizontally swipe over the LED digits to change the timer. This kind of gesture is not possible when VoiceOver is active because there you can pan over the screen to quickly get to the hot spots of interactive elements.
I solved this by having individually adjustable sub-elements for the minutes and seconds while the timer is not running. This way you can swipe vertically to adjust the minutes and seconds separately.
There are three kinds of standard gestures for Voice-Over which I made full use of:
- double-tap with single finger to select an element
- double-tap with two fingers to perform a “magic tap”
- draw a Z with two fingers to “escape”
I used #1 for the single-tap function of the preset and speaking phase buttons. #2 substitutes for the long press. The rationale is that you have to consciously tap with two fingers instead of one to modify the presets, as to prevent you from accidentally changing them.
In the regular flow of things, VoiceOver basically comments on the focused element and after a short pause also reads out the accessibility hint that tells the user what interactions are possible. I also used VoiceOver’s announcement notifications to give audio feedback on some interactions.
The cherry on top is that certain timer values get red out aloud. In the yellow and green phases you get a voice prompt every minute. The phase transitions get announced as well. In the red phase there is an announcement very 15 seconds, with the final 10 seconds being accompanied by beeps.
That felt like a reasonable amount of voice feedback for starters. I might add some configuration options at a later point.
In this video I am demonstrating all that we discussed.
Conclusion
I would say my implementation is 95% perfect. There are some edge cases still – which I cannot do much about – where VoiceOver will insist of speaking something that it wouldn’t need to. Unfortunately there is no way to tell Accessibility to “shut it” for certain times when there is something more important going on.
It cost me a lot of experimenting and the better part of a day to get to this stage. I am anxious to hear from actual users of SpeakerClock, in particular those who are visually impaired and might have use for a timer. And some regular users also asked about acoustic feedback. What sort of configuration options related to sounds might make sense?
Also published on Medium.
Categories: Updates
