Smoothie Scout

Tell it what is in your fridge

Most recipe sites work backwards. You find a recipe, then find out you are missing three things. Smoothie Scout starts from what you already have. Tap the ingredients in your kitchen, pick a goal like energy or better sleep, and it ranks 500 blends by how close you are to making them, listing what is missing from each one.

No account, no install. What you tap stays in your browser.

What the team built

500 recipes. 60 are written by hand. The other 440 are generated from two curated tables: 78 ingredients and 10 goals, each mapped to the nutrients it leans on and the ingredients it should avoid. The generator is deterministic, so the same tables always produce the same catalogue, and a 36-test suite reviews what nobody could check by hand across 500 recipes.

My role

The team wrote the app. My part was the work that needed a person in the loop.

• Manual accessibility testing. I sat with NVDA on desktop and VoiceOver on mobile and used the app the way someone relying on them would.
• Collaboration with the coding agent. I worked through the fixes with it rather than handing off a spec, which mattered most where the first fix made things worse.
• Character in the recipes. Generated names started out as ingredient lists. I iterated until each blend had a name of its own, cutting the words that were too obscure to recognise or that carried a second meaning.

What manual testing found

Automated tools are good at contrast ratios and missing labels, and they caught real problems here. Most of what was broken for screen reader users never showed up in a scan.

• Controls with no name. Goal cards and ingredient chips reached the accessibility tree as unnamed buttons. Valid markup, visible text, nothing flagged.
• A fix that made it worse. An aria-label replaces everything inside the element, so the visible text got pruned out of the tree. Four attempts before the cause was clear. The controls now take their name from their own text.
• An invisible checkbox is not a checkbox. Both sr-only and opacity: 0 drop the input from the accessibility tree. The checkbox now covers the whole chip and paints nothing.
• Navigation in the way on every route. Only the home page had a skip link. A floating results bar also overlapped the chips below 1024px, blocking clicks for everyone.

I logged what I could not fix as well. One hover-mode behaviour reproduced identically across four implementations, which told me the cause was not in our markup.

Where it landed

No automated violations on any route, in light or dark mode, at desktop or mobile width, before or after interaction. More usefully, a version a screen reader user can get through start to finish.

• Focus indicators are real outlines, so they survive Windows High Contrast mode.
• Motion is gated behind prefers-reduced-motion.
• Contrast clears WCAG AA everywhere, including a wordmark that passed against the page colour and failed against the translucent nav it actually sits on.