What it means for a web client

In the course's ladder of user needs, usability is rung five. By then the page exists and has arrived, the person can perceive and operate it, and they can read it. Usability asks a different kind of question: does the interface match how people think, and does it let them complete the task? A validator, a scanner or a spec can't answer that. You can only find out by watching someone use the page.

The course boils it down to six principles. Convention: people spend most of their time on other sites, so the logo links home and links look like links. The user's language: "Add to cart," not "Initiate procurement." Feedback: every action gets a visible reaction. Error prevention and recovery: constrain inputs, explain errors next to the field in plain words, and never throw away what the user typed. Visibility of state: where am I, what is in my cart, what will this cost? Task fit: the flow follows the user's goal, not your database schema. Nobody's goal is "create an account."

The rung has a boundary on each side. A missing label is an accessibility failure. A label that is present, announced and meaningless is a usability failure. A checkout that works but feels pushy is an acceptance problem, one rung up. Usability is measured in behavior: did people complete the task, how long did it take, and where did they go wrong.

Usability is also where the course's rule on UX and DX gets tested. When developer convenience and user experience conflict, the user wins. Your users didn't choose your framework. They want to get their task done.

Where it lives in each layer

Structure: The markup decides how much work the user has to do. The right type and autocomplete tokens on an <input> let the browser fill the form, so the user doesn't have to type it all. A real <form> submits when the user presses Enter, with no extra code. URLs are part of the interface too. Every meaningful state, such as a search, a filter or a step, needs a URL someone can bookmark, share or come back to, and Back should undo navigation, not empty the cart.
Presentation: Most usability conventions are visual. The cart sits at the top of the header, the primary action is prominent and always in the same place, and progress reads "Step 2 of 3 — Shipping." A running order summary keeps prices visible. Shipping that shows up only on the last screen ambushes the user's decision. Layout carries usability as well. Keep lines of text to a readable measure, make the page work on a 240-pixel screen, and don't put anything important behind hover, which touch screens and remotes don't have.
Interaction: Script is where feedback and forgiveness happen. Listen for submit on the form, not click on the button, or you miss the keyboard path. Use checkValidity() and reportValidity() to catch mistakes early. Validate on the client for usability and on the server for security. Keep your handlers short. A long task blocks the event loop, and input is ignored until it finishes. To the user, that looks like a broken button.
Delivery: Waiting is part of the interface. Nielsen's three limits still apply. At 0.1 seconds a response feels instant, 1 second is the limit for uninterrupted thought, and 10 seconds is the limit for keeping attention on the task. Set request timeouts from what the user is doing, and tell them plainly when something fails. A full-page postback throws away scroll position, focus and unsubmitted input. That can be the right design, but your choice of pattern decides what the user loses.

Where the course teaches it

Usability: can they use it?: rung five of the Life of a Page Load, with the six principles and the table of eight checkout sins and their fixes.
The hallway test: how to observe a participant on a task, record behavior and keep from helping.
Accessibility and Acceptance: the rungs on either side, and where usability's boundaries fall.
Verification: funnels, task completion and form-error rates as field signals, and why a funnel only counts users who made it past the lower rungs.
Who Fell Off the Ladder?: the film that previews each rung, including the usability checkout.
A Budget for Patience: the film on RAIL, including a budget for how soon the page is usable on a slow phone.
UX vs DX: why the user's experience wins when it conflicts with developer convenience.
URLs as interface: readable, predictable URLs and state you can bookmark.
Forms: events that do work: handling submit, reading values and using built-in constraint validation.
The JavaScript engine and the event loop: long tasks, dropped frames and ignored input.
The postback problem: what a full navigation discards, and when it is still the right design.
When it goes wrong: Nielsen's time limits, timeouts chosen per task, and failures reported by kind.
Who is visiting?: usability checks for each kind of visitor, from autofill and thumb reach to shared devices and the Back button.

Check your own page

Give a classmate a task, not a tour, and watch them do it in silence. Note whether they finish, how long it takes, where they go wrong and where they hesitate. Every urge you feel to explain is a finding about your interface.
Go through the eight checkout sins on your own forms. Count how many your page commits.
Submit a form with one field wrong. The error should name that field, sit next to it in plain words, and leave everything else the user typed in place.
Fill in your form using only autofill, then press Enter in a text field. Both should work.
Click every button and check that each one produces a visible reaction. Then throttle the network in DevTools and try again.
Bookmark a filtered or mid-task view, open it in a private window, then press Back through the whole task. Every state should come back, and nothing should be lost.
Use the page by touch only, then at 240 and 2560 pixels wide. Nothing should depend on hover, and text should stay readable at both widths.