Web Programming with JavaScript: From DOM to APIs

Module 9: Different Ways to Use the Interface

Course progress0%
Course content

Module 1

Your Program Works. Can Someone Use It?Design the Page around the TaskRender the Data, Preserve the RulesLab: Prove the Interface Preserves the Contract

Module 2

A Click Is an Intention, Not a Business RuleWhere Does the Current Order Live?Render Results without Fighting the User

Module 3

Form Values Are Not Yet Order DataA Rejection Must Explain the Next ActionLab: Make a Quote Editable without Duplicating Policy

Module 4

An Order Has States, Not Just ButtonsA Disabled Button Is Not Enforcement

Module 5

Save a Draft, Not a PromiseTwo Tabs, One Draft

Module 6

HTTP Is a Contract between Two ProgramsBuild Your Own Local HTTP LabFetch without Hiding Loading or Failure

Module 7

The Last Intention Wins, Not the Last ResponseRetry Is a Business Decision

Module 8

The Browser Is Not the AuthorityConflicts and Repeat Submissions

Module 9

Can the Person Finish without a Mouse?Readable Results and Useful Performance

Module 10

Tests That Challenge the ContractTest Time Order, Not Just Values

Module 11

Review Generated Code with Evidence

Module 12

Boundaries before More FilesLifecycle and Tooling Have a Purpose

Module 13

Final Project: The Order WorkbenchFinal Review: Can You Handle the Next Change?

Module 14

What Would a Framework Actually Own?Framework Readiness: Explain before You Adopt
45 min

Can the Person Finish without a Mouse?

Audit a complete task with keyboard navigation and understandable feedback

By the end of this lesson

  • Audit a complete task with keyboard navigation and understandable feedback
  • Preserve focus and announce only useful state changes

A screenshot misses the task

The page looks finished. Now unplug the mouse. Can you change quantity, identify a rejected value, save a draft and recover from a failed catalogue request? Accessibility is part of whether the workflow works.

Use native buttons, inputs, labels and headings. A clickable div needs behavior that a button already supplies. Name every control by its visible purpose: "Save draft" and "Retry catalogue" communicate more than "Go".

Run one complete scenario

  1. Reload and move through the page with Tab. The focus indicator must remain visible and follow the reading order.
  2. Reach the quantity field through its label. Enter an invalid value and submit with Enter.
  3. Read the error associated with that field. Correct it without losing the rest of the draft.
  4. Submit successfully. Keep focus on the invoking control unless a deliberate new context requires moving it.
  5. Start a slow catalogue load, then an error and retry. Its status should be understandable without relying on color.

Do not assign positive tabindex values to repair an illogical document order. Fix the order. Do not remove outlines without providing an equally visible focus style.

Announcements and focus have different jobs

Use a persistent polite status region for non-urgent loading/success messages. Insert text into it when the state changes. Avoid announcing every keystroke or placing the entire page inside a live region. For form errors, connect hints with aria-describedby, set aria-invalid when appropriate, and use a focused error summary or the first invalid field according to the form's size.

A disabled control cannot normally receive focus. Put the reason for a forbidden action in nearby visible text, not exclusively in a tooltip attached to that control. For example: "Only drafts can be changed. This order is confirmed."

A small-screen constraint

Test at 320 CSS pixels and at 200% zoom. Labels, totals, errors and actions must remain readable without overlapping. Use flexible grids and wrapping text, not a fixed width that only suits your monitor. A long product name must not push its price off-screen.

Counterexample and correction

A render function replaces the whole form after every keypress. The values appear right but focus disappears and text selection resets. Update results and relevant messages separately; maintain stable controls. This is the same separation of responsibilities that made earlier state tests easier.

Submit a task-based audit with observed results and fixes. An automated scanner may supplement it, but cannot prove that a person understands a conflict or can recover from one. If you can test with a screen reader, record the browser/tool and exact scenario; do not claim that coverage without doing it.

Lesson complete?

Your progress is saved on this device.