eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

Accessible Blockchain Tasks: Review Context, Follow Status and Recover Safely

—

by

eduKate Asia
Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.

中文版 · Blockchain learning guide · Previous article

Blockchain learning · Extension BCX004

Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.
Study photograph for illustration; it does not establish that the pictured students are studying blockchain.

A blockchain interface is not accessible merely because its buttons have labels. A person must be able to reach the correct network and account, understand the action, move through an authorisation handoff, receive meaningful status and recover without accidentally repeating an operation. Each boundary can break an otherwise readable page.

This lesson audits a fictional end-to-end task using nine supplied checkpoints. Some failures concern keyboard or assistive-technology access; others concern the accuracy of the state being communicated. Together they determine whether the user can complete the intended task with informed control.

The exercise uses a mock provider and synthetic equipment records. There is no real wallet, secret, transaction, credential issuance, payment or personal data. We are analysing supplied observations, not claiming to have performed a live accessibility audit. The result is a task-specific acceptance verdict, not a certificate of WCAG conformance.

Choose your reading route

In this guide

Sections 1–3 define the task, checkpoints and review criteria. Sections 4–8 inspect navigation, handoff, changed context, status and recovery. Sections 9–11 provide the verdict, proposed repair and retest record. For general foundations, see How Assistive Technology Works.

Back to contents · Next section

1. Define the action a person is trying to complete

The mock application lets an authorised practice office set the review flag of synthetic equipment record Record17 to Reviewed. The intended context is network N1 and practice account Office-A. The operation does not assert that any physical equipment has actually been inspected; the record is a teaching fixture.

Before authorisation, the user should be able to identify N1, Office-A, Record17, the exact change and its scope. A successful provider connection is not permission to make that change. Reviewing a summary is not the same as signing, and signing is not the same as confirmed application success.

The tested journey has six broad stages: choose context, prepare the change, review it, handle the mock authorisation window, observe submission and learn the eventual result. A separate recovery path handles cancellation, account changes and lost connection.

The interface’s job is to make those stages understandable and operable. An unexplained spinner or a familiar account icon cannot carry the entire meaning. Nor should a user need to infer failure from the fact that a button changed colour.

Back to contents · Next section

2. Read the nine-checkpoint evidence packet

Each checkpoint is an independent test fixture. A later checkpoint begins from its supplied state even if an earlier fixture contains a blocker. This lets us inspect the complete journey without pretending a keyboard user could pass through an inaccessible first step.

The dossier supplies exact keyboard reachability, focus and assistive-technology observations for the fictional interface. It also supplies the relevant application outcome. We accept these observations for the exercise; a real test would record the actual browser, operating system, assistive technology and versions.

  • C1: network selection works only with a pointer; there is no keyboard-equivalent path.
  • C2: the review exposes the complete synthetic network, account, target and action in readable text, with an accessible way to inspect each identifier.
  • C3: the mock authorisation modal opens, but focus stays behind it and its controls are unreachable through the supplied keyboard path.
  • C4: the account changes from Office-A to Office-B after review; the old review remains marked current and submission remains active without renewed review.
  • C5: the user cancels before any signature or submission; the application correctly reports that no operation was submitted.
  • C6: after submission, only a coloured spinner changes; no meaningful pending status is available in the supplied assistive-technology output.
  • C7: a supplied receipt shows application execution failure, but the interface reports successful record issuance.
  • C8: the provider disconnects after submission; the interface calls the operation cancelled and offers an unqualified repeat action.
  • C9: verified evidence establishes successful execution and the stipulated finality condition; the interface accurately exposes that result with its network and request context.

Back to contents · Next section

3. Separate standards from the bespoke task requirements

WCAG 2.2 provides the accessibility framework. Its supporting Understanding pages explain requirements such as keyboard operation, meaningful focus order and perceivable status messages. Those explanations are informative guidance; the normative criteria and conformance requirements belong to the recommendation itself.

Our worksheet also imposes task-specific integrity requirements: a changed account invalidates the previous review, a pending operation is not described as complete, and a disconnect is not described as cancellation. These are explicit requirements of this fictional journey. We do not claim every one is a standalone WCAG criterion with the same wording.

This separation improves the verdict. A reviewer can identify a keyboard access barrier, a focus barrier or a false execution message without stretching a standard to say something it does not say. A small collection of passing checks also cannot establish site-wide conformance.

For interpreting an actual supplier’s report, use Reading an Accessibility Conformance Report. The present lesson instead follows a concrete blockchain interaction across its boundaries.

Back to contents · Next section

4. Reach and inspect the context without a pointer

C1 fails the specified keyboard requirement. The person cannot select the required network through the supplied keyboard interface or any equivalent path. A visually attractive selector does not solve that access barrier.

W3C’s Keyboard explanation concerns operating functionality through a keyboard interface, with a specific exception for inherently path-dependent input. Selecting a network in this fixture does not require freehand movement. A repair should provide an operable, discoverable path rather than merely adding a decorative label to the pointer-only control.

C2 passes its supplied context-inspection requirement. The user can read N1, Office-A, Record17 and the requested Reviewed flag without relying on colour or a truncated identifier alone. This does not authenticate a real network by itself; it ensures the interface communicates the context that the separate setup evidence supplies.

Long real identifiers may need a concise label plus an accessible full-detail view. The relevant requirement is that important distinctions remain inspectable. Reading a long identifier character by character at every step is not the only possible design, and a shortened display should not hide the only way to distinguish two contexts.

Back to contents · Next section

5. Preserve focus through the authorisation handoff

C3 fails the supplied modal task. The authorisation window is visible, but the person using the defined keyboard path cannot reach its controls. They cannot review or cancel through that path. The underlying application cannot declare the journey accessible simply because the barrier appears in a separate component.

W3C’s Focus Order explanation describes order that preserves meaning and operation. For this mock modal, the proposed repair puts focus at a meaningful point inside it, keeps the relevant modal interaction usable, and returns focus to a sensible location when the window closes.

This is a design proposal for our fixture, not a claim that every real wallet window shares the same technical implementation. A browser extension, separate browser window or mobile handoff can require different testing. Record which component controls each transition and which team must repair it.

Do not remove the review step to make navigation shorter. Accessibility should preserve the person’s opportunity to understand and decline the action. Nor should the application ask for a recovery phrase or private key as an “accessible alternative.” No secret disclosure is necessary for this mock task.

Back to contents · Next section

6. Treat an account or network change as meaningful context

C4 fails the defined review-binding requirement. The user reviewed Office-A, but the active account is now Office-B. Keeping the old summary marked current would let the next action proceed under a context the user did not review.

The proposed repair marks the previous review stale, announces the changed account in understandable text, and requires a fresh review of the updated context before enabling the authorisation path again. It should preserve safe draft information where appropriate, rather than silently submit or unexpectedly discard everything.

EIP-1193 defines provider events for changes to the chain and available accounts. These events help an application learn that its context changed. Receiving such an event is not user consent, and the event alone does not guarantee that the application has updated every summary or pending request correctly.

A network change deserves the same careful reconciliation in this fixture. Identical-looking account text on another network does not establish the same record or permissions. The application should explain which context changed and what the user needs to review, without implying that changing a displayed network erased an earlier submitted operation.

Back to contents · Next section

7. Communicate pending, failed and completed states accurately

C6 fails the pending-status requirement. The coloured spinner does not provide the meaningful status available to the supplied assistive-technology user. The person cannot tell whether the operation is waiting for authorisation, submitted, executing or already complete.

W3C’s Status Messages explanation addresses programmatically available status information that assistive technology can present without requiring focus to move to the message. A repair can expose a concise “submitted, result not yet confirmed” update while allowing the person to continue reading.

This does not mean announcing every new block repeatedly. The proposed task design announces meaningful state changes and keeps the latest status available for inspection. Constant interruption can make the interface harder to use without adding decision-useful information.

C7 fails for a different reason: the message is inaccurate. The supplied receipt establishes failed application execution, while the interface says issuance succeeded. Making that false message easier to hear would not solve the integrity defect. The repaired text should identify the failed requested change and the evidence context without implying that every other aspect of the transaction or account was rolled back.

C9 passes its supplied result requirement. The outcome text matches the verified successful execution and defined finality evidence, and retains request/network context. That pass is local to this checkpoint; it does not erase C6 or C7 failures.

Back to contents · Next section

8. Distinguish cancellation before submission from disconnect afterward

C5 passes because its premise is explicit: cancellation occurs before any signature or submission, and the mock component confirms that no operation was submitted. The interface accurately reports that bounded outcome. It should return the user to a usable place with the retained draft state described clearly.

C8 fails because the provider disconnects after submission. Disconnection prevents or interrupts the current observation path; it does not establish that the submitted operation was cancelled or that it cannot execute. The interface’s cancellation claim is unsupported.

An unqualified repeat action is also unsafe in the fixture because the original outcome is unresolved. A proposed repair preserves the request identity, reports the observation gap and offers an appropriate status-recovery path before suggesting another operation. It does not promise that reconnecting will always recover a result or that every network has the same cancellation mechanism.

The distinction matters to all users, including someone relying on screen-reader output. If the only announced message is “cancelled,” they may reasonably believe no external effect remains possible. Accurate recovery wording is part of maintaining informed control, not an optional technical footnote.

Back to contents · Next section

9. Give the task-specific acceptance verdict

Under the supplied requirements, C2, C5 and C9 pass. C1, C3, C4, C6, C7 and C8 fail. That is three passing checkpoints and six failures. The complete journey is not acceptable under this worksheet because essential context selection, authorisation access and outcome interpretation remain broken.

Do not convert three out of nine into a WCAG conformance percentage. The checkpoints were selected for a particular task; they are not a complete standard inventory, statistical sample or severity-weighted scoring system. One critical barrier can prevent completion even when several other screens work well.

The findings should preserve their different causes. C1 needs a keyboard-equivalent path. C3 needs handoff focus and operability repair. C4 needs review invalidation and context reconciliation. C6 needs accessible meaningful status. C7 needs truthful outcome mapping. C8 needs uncertainty-preserving recovery.

This gives the owner a repair plan instead of a single vague instruction to “improve accessibility.” It also prevents a colour change or an added label from being mistaken for a fix to an application-state error.

Back to contents · Next section

10. Specify a repaired journey before retesting

In the proposed revised journey, the user reaches the network selector by keyboard, chooses the synthetic network, and can inspect the complete action context. The review state explicitly binds N1, Office-A, Record17 and the exact requested change.

Opening the mock authorisation component gives a meaningful focus position and usable review/cancel controls. Closing it returns the user to a logical place. If the account or network changes before authorisation, the review becomes stale and the interface explains the new context before the person proceeds.

After a supplied submission, the status says that submission has occurred and the result remains unconfirmed. A failure result is reported as failure of the requested application action. Successful-finalized wording appears only when the supplied evidence supports both parts. A disconnect leaves an unresolved status with a retained identifier rather than pretending to cancel history.

These are proposed acceptance behaviours, not repairs already implemented or tested. Retesting must use the actual revised components and the supported browser/assistive-technology combinations. A written design is evidence of intent, not evidence that the interaction works.

Back to contents · Next section

11. Keep a reproducible test record

For each checkpoint, record the starting fixture, component versions, input method, steps, focus location, accessible names and state announcements, visible status, underlying outcome evidence and observed result. Separate the tester’s expected behaviour from what actually happened.

Include keyboard-only operation and relevant assistive-technology use rather than treating an automated scan as the whole evaluation. Where feasible, include people with relevant access needs in the review process, with appropriate consent and privacy protection. This article supplies no real participant data and makes no diagnosis about any individual.

Record cross-component responsibility. If the application is correct but the mock wallet handoff fails, the end-to-end task still fails. Conversely, a provider event being emitted correctly does not prove the application’s accessible status or review binding is correct.

The form-submission states prerequisite explains general save, submit and recovery clarity. The extra work here is to preserve that clarity across changing chain/account context, authorisation boundaries and independently evidenced execution states.

Back to contents · Next section

Exercise and model answers

  1. Which checkpoints pass? C2, C5 and C9, under their supplied premises.
  2. Why does C4 fail even if Office-B also has some permission? The existing review was for Office-A. The fixture requires renewed review of the changed context rather than assuming the user approved it.
  3. Can an accessible announcement repair C7 if it still says success? No. The announced content would remain false relative to the supplied execution evidence.
  4. Does C8’s disconnect prove cancellation? No. The request was already submitted; its outcome is unresolved through the interrupted observation path.
  5. Does passing all nine revised fixtures certify WCAG 2.2 conformance? No. It would establish those task checks for the tested scope, not every applicable criterion and conformance condition.

For a practical writing exercise, replace “Something went wrong, try again” in C8. A better synthetic message is: “Connection lost after request T1 was submitted. Its result is not yet confirmed here. Keep this request reference and check its status before starting another operation.” This wording does not claim the action failed or that repeating it is harmless.

Back to contents · Next section

Frequently asked questions

Is accessibility only about screen readers?

No. Keyboard access, focus, understandable state and perceivable information can matter to people with varied access needs and input methods. This worksheet samples specific barriers rather than covering every need.

Must every status change move focus?

No. Many status messages should be available to assistive technology without moving focus. A deliberate context change such as a modal has different interaction requirements; test the actual flow.

Should the interface reveal secrets to make identifiers readable?

No. Public context and action details are different from recovery phrases or private keys. Accessibility does not require exposing secrets, and this exercise contains none.

What should a reader learn next?

Use the linked general accessibility and form-state articles for foundations. Then practise writing a full task trace with account/network changes and uncertain outcomes, rather than evaluating isolated buttons alone.

Back to contents · Next section

Sources and further reading

An accessible blockchain task lets the person understand what is being authorised, follow what actually happened and regain control when the evidence is incomplete.

Back to contents