Gestures and hands-free control during a workout

Two people cannot use your swipe-to-skip gesture: somebody with limited dexterity, and somebody with a bar racked on their back. The fix is the same for both, which is the most useful thing to know about hands-free design in this category. "Hands-free" here is not a minority feature bolted on at the end. It is the normal operating condition of a strength app, and the accessibility work and the product work are the same work.

This page is engineering guidance and makes no legal claims; that layer is compliance.

Apple's rule, and the example it ships with#

Apple's Human Interface Guidelines state it plainly:

"Gestures can be less comfortable for people who have limited dexterity, so offer onscreen ways to achieve the same outcome. For example, if you use a swipe gesture to dismiss a view, also make a button available so people can tap or use an assistive device."

Two details are worth pulling out. The remedy Apple names is an onscreen way to achieve the same outcome — an equivalent control, not a reduced consolation path buried in a settings screen. And the closing clause covers the assistive-device case as well as the tap: a control that exists as a real onscreen element is addressable by things that are not fingers.

Apple's verb here is "offer", and we are keeping it. This is not a page that will tell you a platform requires something it recommends.

The gesture inventory#

Every workout UI ends up with a handful of gestures that were added because they felt good in a design review. Write them down and give each one a twin.

The long-press row is the one that most often survives review and should not. A press-and-hold is a timed gesture, so it asks for steady contact for a fixed duration, and it fails for a tremor, for a gloved hand, and for anybody whose forearms are shaking after the set that the gesture is supposed to end. A destructive action with a timed input and no visible alternative is the worst combination in the table.

Google's accessibility principles page lists "Add accessibility actions" among its best practices, alongside labelling elements. If a row in your session list has behavior that is reachable only by dragging or swiping it, that is the reference to read before you decide the behavior is fine as it is.

Voice Control on Apple platforms#

Apple's guidelines describe the capability directly:

"Let people use Voice Control to give guidance and enter information verbally. With Voice Control, people can interact with their devices entirely by speaking commands. They can perform gestures, interact with screen elements, dictate and edit text, and more."

For a workout screen the relevant clause is "interact with screen elements". Our judgement, not Apple's statement: elements your app has never labelled are the ones we would expect to be hardest to address by name, which makes labelling the same piece of work that serves a screen reader. We did not test this and Apple's sentence does not say it, so treat it as a reason to label rather than as a documented behavior.

The design consequence is smaller than teams expect and more boring than a custom voice feature. You do not build a speech pipeline. You make sure the controls that matter during a session exist as real, named, onscreen elements rather than as gestures over an undifferentiated canvas.

Android: accessibility services exist, and writing one is not your route#

Google's documentation on accessibility services describes the category: "These services run in the background and communicate with the system to inspect screen content and interact with apps on the user's behalf. Examples include screen readers (like TalkBack), Switch Access tools, and voice control systems."

Then comes the caution that we think most teams reading this page need:

"An accessibility service is a specialized tool, not a standard way to make your app accessible."

The sentence continues into a recommendation to use standard APIs if you want your app to work with existing services like TalkBack; our extraction was truncated there, so we are not going to complete Google's sentence for it. The point that survives intact is the first half. Teams occasionally scope a "hands-free mode" as an accessibility service that reads and drives their own UI. Google's own documentation calls that a specialized tool rather than the standard route, and the standard route — labelled controls, real onscreen elements, accessibility actions — is also cheaper.

What we cannot tell you is how Voice Access or Switch Access behave in practice. The support documentation for those was unreachable from our research environment when this cluster was compiled, so this page says only that Google's own page names screen readers, Switch Access tools and voice control systems as examples of accessibility services. Any specific behavior of those tools is something to verify yourself, on a device, against current documentation.

The barbell case#

Design for the moment when hands are unavailable rather than for a user category, and the requirements come out concrete.

A rest timer that has to be started by tapping is a rest timer that starts late every time, because the user racks the bar first. Start it on the event, not on the tap. A set that can only be logged by typing a number is a set that gets logged three sets later from memory. Offer an increment control large enough to hit without looking, and default to what the user did last time. A screen that advances only by swiping is a screen that cannot advance while somebody is holding a plank.

Where a sensor or camera can detect the event instead of asking for a tap, that is a different problem with its own accuracy limits, and it belongs to how rep counting works rather than here. The relevant point for this page is that automatic advancement never removes the need for the manual control. It removes the need to use it.

Two product surfaces where this lands hardest: strength training apps, where hands are occupied by definition, and running apps, where the phone is strapped to an arm and the user is moving. On the wrist the whole control surface is smaller and the same rule bites harder, which is watch apps.

Monday morning#

List every gesture in your workout flow, including the ones the framework gave you for free, such as swipe-to-dismiss on a sheet. For each, name the onscreen control that achieves the same outcome. Anything without one is this week's work.

Then delete the long-press. If a destructive action currently needs a press held for a fixed duration, replace it with a button and a confirmation, and see whether anyone notices. Finally, run the session flow using only taps on named controls, with the phone on a bench and your hands chalked — the failures show up in the first two minutes. Verifying it properly is accessibility testing.