A product photograph can explain a texture, open a larger view or simply repeat a nearby description. An AI draft that lists everything in the picture has not yet decided which of those jobs matters.
For an ecommerce content editor, start with the image's placement and purpose. W3C's Images Tutorial says the text alternative depends on the image's usage, context and content.[1] Give a proposed image-description coordinator those inputs before asking it to draft text.
This note describes a MAJLS preparation workflow, not an implemented product or an accessibility certification. The coordinator prepares a review sheet. A human editor confirms meaning; a developer checks the actual markup and interaction. Neither a fluent description nor a completed sheet establishes that the whole page is accessible.
Workflow: collect context before drafting
Give each placement its own row, even when it reuses the same file. Include the asset version, page location, nearby visible text, link or button behavior, intended information, draft alternative and unresolved questions. A file-level description cannot resolve all those contexts.
Use W3C's decision tree to choose the treatment. It distinguishes meaningful photographs, functional images, redundant information, decorative images, images containing text and complex information.[2] For functional images, the alternative should convey the action rather than describe the object pictured.[3]
The coordinator should receive approved image files and page context only. A broken image, unknown destination or unseen caption is a missing input, not permission to guess. Keep the draft in a private review artifact until the owners resolve it.
Filled example: five placements on a fictional napkin page
All product details, asset identifiers, people and page behavior below are illustrative. The editor has supplied the intended behavior and visible copy. The pictures are not evidence of fiber composition, washability or manufacturing origin.
The product page is for a fictional red woven napkin with an off-white stitched edge. Asset N-01 is its main photograph; N-02 is a close-up; N-03 is a care-label image. No customer page is being edited.
| Placement and context | Purpose | Draft treatment | Human check before release |
|---|---|---|---|
| N-01 main image; not linked; adjacent title says only "Red napkin" | Informative: show visible weave and edge | Alternative: "Red woven napkin with an off-white stitched edge" | Editor confirms the detail is visible and not already conveyed in adjacent copy |
| N-01 reused as an image-only button opening a larger product view | Functional: open the view | Alternative: "Open larger view of red napkin" | Developer confirms the button's accessible name and that it actually opens that view |
| N-02 close-up beside visible text "Off-white stitching follows the edge of the red weave"; no link | Redundant: repeats that text only | Empty alternative, alt="" |
Editor confirms it adds no other relevant information; developer keeps the attribute present |
| N-01 reused as a cropped background flourish after the product details; no link or new information | Decorative | Empty alternative if implemented as an image element | Editor verifies the crop is decoration, not the only view of a product feature |
| N-03 care-label image; instructions not available elsewhere | Text information not yet transcribed | Hold; obtain verified care wording and add it as real page text before choosing the final image treatment | Product owner verifies wording; editor checks equivalent information is available and chooses the appropriate alternative |
W3C recommends a brief alternative conveying essential information for informative images and an empty alternative for purely decorative images.[1] Its decision tree also directs authors to include image text when that text is not otherwise available.[2] The last row deliberately stays pending: the coordinator must not infer care instructions from a red fabric photograph or invent words from an unreadable label.
Once the verified care wording appears as real text and the label image adds nothing else, the editor can reassess it as redundant.[2] That is a new context decision, not an automatic exemption for labels.
The first two rows use identical pixels but need different treatments. W3C's functional-image examples also distinguish an image-only link from a logo supplementing link text that already provides the destination.[3] Apply that distinction carefully; an empty alternative is not a blanket rule for clickable images.
Handoff: record decisions, not a blanket pass
In this fictional workflow, Maya is the content editor, Noor is the product-information owner and Sam is the developer. Maya receives the five-row sheet, the exact asset versions and the candidate page. Noor supplies verified care wording. Sam checks that implemented alternatives and accessible names match the approved decisions.
The handoff remains pending while N-03 lacks verified wording. The coordinator may draft rows and flag conflicts, but it cannot change product claims, approve publication or certify conformance. Consequential publication approval stays with the named human content owner, Maya in this illustrative example, after the product and implementation checks. An uncertain classification, absent text equivalent, wrong link behavior or unverified claim is an escalation condition; model confidence alone is not.
Review checklist: inspect the candidate page
- Read each description against the image's purpose and nearby text. Remove invented materials, performance promises and unnecessary repetition.
- Activate image links and buttons. Check that their names describe the real action, rather than treating them as decorative because they look simple.
- Inspect the markup. Distinguish an intentional empty alternative from a missing attribute, and check whether other labels contribute to the accessible name.
- Review images of text and complex graphics separately. W3C calls for a complete text equivalent for complex images; a short visual caption alone may omit their information.[1]
- Check the rendered page with the team's accessibility testing method, including screen-reader review where appropriate. Retain specific findings rather than writing "AI checked accessibility."
Pilot: keep the role in preparation mode
Before connecting this proposed role to a content system, Maya should establish a manual baseline on twelve representative placements: two each covering informative, decorative, functional, redundant, text-containing and complex-image cases. Record classification disagreements, unsupported statements, omitted information and human review minutes per placement. The baseline has not been measured here.
Use the same frozen placements for a shadow run, with no publishing permission. Proposed targets are zero invented product facts, zero functional-image naming misses, complete text-information handoffs and median review time no worse than the measured manual baseline. Stop on any invented claim, misnamed action or publication outside authority. Resolve the cause and rerun the affected cases.
Exit preparation testing only after two clean review rounds, developer verification of the candidate markup and Maya's recorded decision about the role's next scope. That decision does not authorize unattended publishing. For today's page, finish the pending care-label row first.
Guidance basis: W3C Web Accessibility Initiative (WAI), Images Tutorial and related pages. The filled worksheet and role boundaries are MAJLS's proposed adaptation.