Artefacts

Here's what I'd push back on, roughly in order of how much it matters:

**1. Colour is the only signal of state.** Grey-to-green is a pure hue/lightness change with nothing else riding on top of it — no icon, no checkmark, no text change. Somewhere around 1 in 12 men and 1 in 200 women have some form of colour vision deficiency, and red-green confusion is the most common variant, which can make a grey-vs-green distinction genuinely hard to read at a glance, especially at small sizes. This is also just a WCAG "Use of Color" violation on its face (success criterion 1.4.1) — state needs a second channel. The cheap fix is a checkmark or tick icon that appears alongside (or instead of) the colour shift, so the shape changes, not just the fill.

**2. Grey reads as "disabled," not "not yet done."** In most UI conventions grey is the colour of an inactive/unavailable control. If this pill is tappable (which "marked complete" implies), a grey resting state risks telling users the opposite of what's true — that it can't be interacted with. An outlined or neutral-but-clearly-live style for the incomplete state would avoid that ambiguity.

**3. 11px label text is too small for a control at this height.** At 32px tall, there's a lot of vertical real estate around that label, but 11px is below the size most guidance treats as a safe floor for UI copy (commercial practice generally starts around 12-13px minimum, with 14-16px preferred for anything that needs to be read reliably, especially by younger users or on lower-end mobile screens). Since this sounds like an education product, I'd also worry about it being read by children or by teachers on classroom devices at a distance/angle — 11px is punishing there.

**4. Contrast needs checking in both states, not just one.** Whatever text colour sits on top of "grey" and "green" both need to independently clear 4.5:1 against their background (11px doesn't qualify as "large text" under WCAG 2.2, so the small-text threshold applies, not the more lenient 3:1 for large/bold text). It's common for a palette to be tuned so the text works on the accent colour but forgets to re-check it on the neutral resting colour, or vice versa. Also worth checking the pill's edge against the surrounding page background at both states — a light grey pill on a white background can disappear entirely for low-vision users if there's no border.

**5. Touch target is short of the usual minimum.** 32px is below the ~44-48px minimum interactive target size recommended by most platform and accessibility guidelines (Apple HIG ~44px, Material ~48px, WCAG 2.2's 2.5.8 Target Size at 24px minimum with spacing exceptions). If this pill is the actual tap target — not just a status chip sitting next to a bigger tappable row — it's going to cause mis-taps, particularly for the same population (kids, or anyone with a motor-control difference) most likely to be using an education product.

**6. Colour change alone tells a screen reader nothing.** If this is genuinely an interactive toggle (mark complete / unmark), it needs proper state semantics — `aria-pressed`, `aria-checked` with a checkbox/switch role, or equivalent — so the completion state is exposed programmatically, not just visually. And the accessible name or a live region should announce the change ("Marked complete") rather than relying on sighted users noticing a colour fade.

**7. 600ms is slow for a state-confirmation animation.** Typical UI colour/opacity transitions land in the 150-300ms range; something that's meant to read as instant confirmation ("yes, that registered") starts to feel laggy or uncertain past about 300-400ms — the user taps, and for over half a second nothing visibly happens, which invites a second tap. I'd cut this down substantially, or pair it with an immediate secondary cue (e.g., the icon/checkmark appearing right away) so perceived responsiveness doesn't depend on the colour tween finishing.

**8. No mention of reduced-motion handling.** Even a simple colour fade should respect `prefers-reduced-motion` and either shorten drastically or cut straight to the end state for users who've asked for reduced motion — it's a small addition but it's part of doing animation properly rather than as an afterthought.

**9. No error/pending state considered.** If "marking complete" involves any round-trip (saving progress to a server), the design as described only has two states (grey, green) with nothing for "saving" or "failed to save." Without that, a network hiccup either shows a false-positive green or silently reverts with no explanation, which is confusing either way.

If I had to prioritise fixes: add a non-colour indicator (icon) first, fix the touch target and label size second, verify contrast in both states third, then tighten the animation timing and add motion/state-semantics polish once the core control is solid.