Screen readers miss a changed total or payment status
Record the action, the exact visible change, the screen-reader output and where focus stayed. Determine whether the update is a qualifying status message rather than assuming every change on the page needs an announcement. W3C's Status Messages guidance describes roles and properties that let assistive technology announce qualifying updates without moving focus. Ask the component's implementer to make the changed information understandable in context, then check the same real interaction for missing, incomplete or unnecessarily repeated speech.
For: A research-only store owner or checkout maintainer investigating a visual update that a buyer using a screen reader did not receive.
Begin with a specific report from the actual checkout. Identify the control used, what appeared or changed afterward and where the buyer's focus was at that moment. Record the browser, operating system, screen reader and their versions. A total that visibly changed and a total that was spoken are separate observations.
Keep the full meaning of the visible update in the record. If an amount changed, note the label and currency as well as the amount. If a status changed, retain the words the page used and the step they describe. Do not replace a waiting message with a conclusion that a payment succeeded.
Use an authorized observation of a genuine interaction. Before-payment controls can be examined without submitting a payment; stop before any charge. For a report about a post-payment status, use existing authorized evidence of that real event rather than creating another transaction to reproduce it. Mark the announcement unknown when no one observed or recorded it.
Decide whether the status-message guidance fits
WCAG 2.2 success criterion 4.1.3 addresses qualifying status messages without a change of context. W3C's guidance covers information about success or results, waiting, progress and errors that assistive technology can present without taking focus. Not every changed number, element or region of a page is automatically a status message.
Ask the implementer to classify the actual update: what is it telling the buyer, did the interaction change context, and is the information available through the relevant roles or properties? A changed total needs this assessment in its own interaction. It is not enough to say that every price must be spoken or that a visible price never needs an announcement.
The classification helps frame the repair. If the information qualifies, identify what meaningful message should be exposed to assistive technology. If the interaction instead takes the buyer to a new page or another context, document that behavior separately and investigate the accessibility requirements for that flow. This worksheet does not turn those different interactions into one rule.
Preserve meaning without taking the buyer away
W3C warns that updating only a number can lose its context. A buyer who hears an amount without its label may not know whether it refers to shipping, the order total or something else. Ask for the relevant label, amount and currency to remain understandable together when the update is presented. Use the store's actual wording and values, not invented announcements.
Roles and properties can expose a qualifying status update without moving focus to it. Moving the buyer away from the field or control being used solely to make the change audible can introduce a second problem. Focus order is a separate WCAG criterion: when the navigation sequence matters, it must preserve meaning and operability.
Have the maintainer identify which component owns the update: the theme's totals, a checkout extension or a provider-controlled payment surface. Request the announcement semantics supported by that component, with attention to unnecessary interruption. One universal setting applied to every changing area is not a diagnosis. Repeated recalculations and duplicate announcements should be part of the observed behavior, not assumed away.
Specify the result the repair must demonstrate
Give the responsible implementer a bounded acceptance description: after the recorded action, the relevant changed information is understandable to the screen-reader user, the announcement refers to the current visible result, and focus stays where the interaction requires it. Include any observed repetition or interruption that made the original flow difficult to follow.
After an authorized repair, compare the same interaction using the recorded browser and assistive-technology combination. Keep separate notes for what changed visually, what was announced and where focus ended. Other combinations remain unobserved until checked. An announcement improvement does not establish that the amount is correct or that a payment has completed; those questions require the store and provider records.
A Prism checkout consultation can begin with the public website, research-only product context and a plain description of the missed update. Agree on any accessibility assessment or implementation scope, responsibilities, fees and terms before work. The contact form excludes card details, passwords and customer records and leads to email follow-up. A request does not purchase a repair or establish WCAG conformance.
Dynamic-status announcement map
Use one copy per actual changed message or total. Record what was observed, with unknown for anything not heard or inspected. Read the action, visual result, speech and focus rows together: a complete amount without context, a stale announcement or an unexpected focus move remains a specific issue to investigate.
Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.
Dynamic-status announcement map. The last column is for temporary notes.
Observation
Evidence to capture
Question it resolves
Your finding
Action performed
Evidence to captureReal checkout route and control used, step, time, and browser, operating system and screen-reader versions.
Question it resolvesWhich interaction and assistive-technology combination produced the report? Omit private session links.
Changed total or status
Evidence to captureActual before-and-after wording, with the total's label and currency where relevant.
Question it resolvesWhat new information did the sighted buyer receive, and what decision does it affect?
Visual update location
Evidence to captureThe named totals area, message region or payment component containing the change.
Question it resolvesWhich component owns the visible information and can be investigated?
Announcement observed
Evidence to captureWhat the screen reader actually presented, including missing context, repetition or silence.
Question it resolvesDid the buyer receive the same meaningful update? Unobserved speech stays unknown.
Focus before and after
Evidence to captureThe focused control immediately before the action and after the result.
Question it resolvesDid the buyer remain in a usable position, or did focus move unexpectedly?
Status-message classification
Evidence to captureMaintainer's assessment of the message purpose and whether context changed.
Question it resolvesDoes the interaction fit SC 4.1.3, or does the actual flow need a different accessibility investigation?
Accessibility owner and repair request
Evidence to captureResponsible component maintainer and the requested meaningful announcement behavior.
Question it resolvesWho can select supported roles or properties and address unnecessary interruption?
Observed result after the change
Evidence to captureThe same action, current visual result, announcement and focus on the recorded combination.
Question it resolvesDoes the affected behavior now match the agreed result? Do not extend the observation to untested combinations.
These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.
Limits
Not every dynamic page change is a status message. Classification depends on the actual information and interaction.
This observation map is not a WCAG conformance audit, accessibility certification or legal-compliance conclusion.
Do not place a payment to fill the worksheet. Keep card details, authentication codes, private payment-link tokens and customer records out of observations shared through the public form.
An audible success message does not independently establish the underlying payment result or provider eligibility.
W3C WCAG2.2 Understanding Status Messages — checked 2026-09-29. SC 4.1.3 concerns qualifying success, results, waiting, progress or error updates without a change of context. Roles or properties enable announcements without moving focus. Updating only a number can lose meaning; unnecessary interruption should be avoided. Not every DOM change is a status message.
WCAG 2.2 understanding, focus order — checked 2026-09-21. Success criterion 2.4.3 requires focus order to preserve meaning and operability when sequential navigation affects either.
W3C WCAG 2 overview — checked 2026-09-21. Conformance depends on success criteria covering distinct accessibility outcomes. The overview does not determine which accessibility law applies to an individual store.
Prism solutions — checked 2026-09-21. Public support covers storefront review, card-processing preparation and help with a provider's website questions. Scope, fees and terms are discussed before work; the provider decides eligibility and account terms.
Prism contact — checked 2026-09-21. The form asks for the website, products and question, excluding card details, passwords and customer records. Follow-up is by email. A request does not book an appointment, purchase a service or submit a processing application.