What to call an exercise, a set and a rep range

3x10 @ 60kg is a perfectly good string for a person who can see it. It is compact because the layout carries half the meaning: the position of the row says which exercise, the column says which set, the symbol says the unit. Read aloud, it is a number, a letter, a number, a symbol, a number and two letters. Nothing in that says three sets of ten repetitions at sixty kilograms, and nothing in the platform is going to work it out for you.

This is the part of accessibility work that no API does. The platforms give you somewhere to put a string; the string is yours. This page is engineering guidance and makes no legal claims; law and store policy live in compliance.

What the platforms actually ask for#

Google's accessibility principles set the bar in one sentence: "Users must be able to understand the content and purpose of each interactive and meaningful UI element within your app." Note what it asks for — content and purpose. A weight value has content. A plus button has purpose. A set row has both.

Apple's accessibility guidelines frame the same job differently: "Describe your app's interface and content for VoiceOver. VoiceOver is a screen reader that lets people experience your app's interface without needing to see the screen." Without needing to see the screen is the test to apply to every string below. If understanding it requires knowing what column it was in, it fails.

Both companies stop there. Neither tells you how to word a superset or whether to say kilograms every time. Everything from here on is our editorial judgement, and you should overrule it where your users' vocabulary differs.

Six rules for a fitness string#

Expand the notation. Gym shorthand is a visual convention. 3x10, 8/12, @, BB, AMRAP and 1RM have to be spelled out in whatever words your product means by them — your product's meaning, not a general one you assume.

Name the unit once, where the unit lives. Say kilograms or pounds on the weight, not on every fragment of the row. If your app lets people switch units, the string is generated, never hard-coded.

Put the identity first. A listener often hears the first two words and moves on. "Bench press, set two of four" is scannable. "Set two of four, bench press" is not.

Numbers should be read as quantities, not glyphs. 1:30 is a colon between two numbers until you write it as one minute thirty seconds. +2.5 is a plus sign until you write it as increase by two point five kilograms.

Say the same thing the same way. One template per element type across the whole app. A user who has heard forty set rows should be able to predict the shape of the forty-first and listen only for the number that changed.

Do not read decoration. A rest-day dot, a divider, a chevron and a gradient are not information. If a control is icon-only, describe the action; if a graphic is decorative, it does not need a description at all.

The table#

The left column is what a fitness app renders, the middle is what we would write instead, and the right is the reason — which matters more than the example, because your wording will differ.

The last row is different in kind: a value that changes constantly is not the same problem as a label that never changes. Apple's own documentation distinguishes an element's label from its value in exactly that context, describing the frequently-updating case as an element that "frequently updates its label or value".

A completed set is a state, not a name#

The most common labelling mistake in a training app is renaming a row when its status changes: "set 2" becomes "set 2 completed", and now the row's identity moves under the user.

Google's Compose semantics documentation has the concept for this. Of the state description, Google writes: "The StateDescription describes how the 'On' state should be referenced. By default this is a localized version of the word 'On', but this can be made more specific (for example, 'Enabled') based on the context."

Your context is training, so your states are not "on". Ours would be completed, skipped, in progress and not started. The row's name stays "set 2, 10 reps at 60 kilograms" from beginning to end; only the state changes. Two benefits: the user hears the state without re-hearing the whole row, and your logging code stops building strings by concatenation.

Group the row before you word it#

Wording a set row well does not help if the row is four separate stops. Google documents the grouping mechanism — "Composables and modifiers can indicate that they want to merge their descendants' semantics properties by calling Modifier.semantics (mergeDescendants = true) {}" — and gives the reason on the principles page: "Consolidating related elements helps users of assistive technology discover the information on the screen more efficiently."

Grouping and wording are the same decision made twice: decide what one stop is, then write the sentence it should say. Our boundary rule is one stop per decision the user makes. An exercise in a plan is one decision, a set is one decision, and a stepper is two actions that stay separate.

Where the strings come from#

Almost every string above should be generated from the same data that renders the visual row. Hand-written descriptions go stale the day somebody adds pounds, changes the rep scheme or renames the exercise, and nobody notices because nobody on the team is listening to the app.

So build one function per row type that takes the model and returns the sentence, use it for the accessible description, and test it as a pure function against the ugly cases: zero reps, a bodyweight set with no load, a range like eight to twelve, a set with no target, a unit switch mid-session. That is ordinary unit testing and belongs in your suite alongside the rest of test. The domain shapes those strings must survive are in building a strength training app and adding rep counting.

Monday morning#

Pick your busiest row type — the set row — and write down, in words, what one instance should say from cold, with no layout and no column headers. Find where that row is described in code and replace what is there with a sentence generated from the model. Move completion out of the name and into a state. Do the same for the exercise card and the rest timer, then grep for descriptions that are string literals: each one is a label that will be wrong by the next release.