PRODUCT DESIGN·6 min

Be My Eyes: ask a person when a photo leaves questions unanswered

Be My Eyes provides everyday visual assistance for people who are blind or have low vision. Users can take a photo for a description, ask follow-up questions, or contact a volunteer to clarify what is in front of them through live video.

Break down the problem and try your own design and implementation first. Then explore the reasoning to check states, edge cases, trade-offs, and ways to test your approach. The guide offers a reasoning path, not a complete implementation.

FRONTEND EXERCISE

Keep a short status announcement separate from the description

Build a small status component for a photo-description page. A person using a screen reader—software that reads page content aloud—needs to know when the description is ready, without being forcibly moved to the new content.

Inputs: The parent page supplies phase: idle (not started), loading (generating), or done (complete). It also supplies a non-empty description when phase is done; other phases have no body text. Inputs are valid. You do not need to implement photography, network requests or error handling.
Display rules: The idle message is empty. Loading shows “Generating the photo description.” Done shows “Description ready. Read it below.” and displays description in an ordinary content area below. Remove the old body text when a new loading phase begins. Put the short message in a status region that already exists, giving screen readers an opportunity to announce changes at a suitable moment. Do not put the full description in the automatic announcement region or call focus to move the user's focus. See the W3C status-message example.
Acceptance example: Change from idle to loading to done, using “Two tops; the one on the left has stripes” as description. The corresponding message and body should appear. Returning to loading removes the old body and shows the waiting message again. An ordinary rerender in the same state should not repeatedly clear and refill the message. Focus a demo button in the parent page before the changes; focus should remain on that button afterward.
Deliverable: Implement the component and a local demo with HTML/JS or a familiar frontend framework. Record the visible results and focus check above, and explain how the status region is separated from the body.

Explore the reasoning

Let the phase supplied by the parent page determine the display, with separate responsibilities for the short notification and the description body.
Make the status container exist before updating its text, and retain appropriate status semantics. Moving focus is not a substitute for a notification, and the announcement region should not be recreated on every rerender.
Follow the waiting–complete–waiting sequence to check that the old body is removed. Observe focus and inspect the page structure the browser supplies to assistive software—the accessibility tree—to confirm that the status region contains only the short message.