Create a screen-reader-friendly menu page

Why use this

1. A diner using a screen reader may have difficulty finding categories or moving between dishes in an image-heavy menu. A visually neat page can still force them to listen through unrelated content to locate a particular item.

2. This job could turn supplied menu information into a proposed navigable structure with clear headings and meaningful item relationships. Testing that structure with intended reading patterns matters more than assuming that visible headings alone make the menu usable.

Why an agent / simpler alternative

Useful judgment

Choose a coherent hierarchy, keep dish descriptions and prices associated, and identify ambiguities needing restaurant review.

Simpler alternative

Use a simple semantic document or an existing accessible menu template for a short menu.

Unsuitable when

The source menu is unreadable or the result would be represented as certified accessible without evaluation.

Proposed inputs

1. Name

   Menu content

   Owner

   Restaurant or authorized owner

   Minimum scope

   Current categories, dishes, descriptions and stated prices

   Quality check

   Verify source order and item associations

2. Name

   Navigation brief

   Owner

   Owner or accessibility reviewer

   Minimum scope

   Desired category/item navigation and language needs

   Quality check

   Define meaningful heading levels and nonvisual labels

Access and setup — proposed or unknown

Proposed minimum

1. Draft a private content outline from supplied materials; no website hosting, public sharing or live edits.

Compatibility unknowns

1. Current page-generation tools, screen-reader/browser behavior and exact runtime compatibility are unknown.

External actions requiring approval

1. Publishing the page, uploading licensed material or altering the restaurant's website requires approval.

Expected deliverable and review checks

Proposed artifact

Menu-page candidate outline with heading hierarchy, item/price associations and proposed navigation checks.

Critical checks

1. Check headings in sequence; preserve dish context; ensure price and modifiers belong to the right item; plan actual assistive-technology review.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   Every dish uses the same level as a category

   Why it matters

   Navigation loses the menu's hierarchy

   Proposed response

   Revise the nesting and inspect the heading list.

2. Signal

   A visual column separates prices from dishes

   Why it matters

   Reading order may attach the wrong price

   Proposed response

   Keep each item's details together in the semantic structure.

Effort and cost — unknown

Setup work

1. Confirm menu content and navigation expectations.

Ongoing review

1. Review updated dishes and evaluate usability with assistive technology.

Unknowns

1. Source freshness, accessibility testing effort, hosting and service costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent two categories with three dishes, one modifier and a price in a separate visual column; propose a semantic outline.

Acceptance checks

1. Preserve hierarchy; bind each price/modifier to its dish; avoid an accessibility certification claim.

Stop conditions

1. Stop if source associations are unclear or public hosting is not authorized.

Limits

1. A heading-based candidate does not by itself demonstrate complete accessibility, current prices or dietary suitability.