Build the interfaces and check their behavior in the browser.
These sheets describe activities and teaching exercises. They do not constitute job offers, certifying courses or recruitment promises.
All job descriptions
Implement browser interfaces: HTML structure, presentation and interactions connecting content and services with visitor actions, performance and accessibility.
Browser validation supports usability but cannot secure data alone. Server checks remain essential; agree API contracts and errors with back-end developers.
Build a keyboard-usable form and demonstrate slow-response and simulated-server-error states.
This is an editorial description of common activities. Job titles and scope vary across teams; it is not a certification framework.
W3C: organising accessibility responsibilities across a team
Create a catalog filter that can be used on the keyboard and shareable by a URL.
Work on a copy or demo environment. Define the data used and the expected result before you begin. Keep your decisions and the difficulties encountered in order to be able to explain the process.
A functional interface, course tests and component documentation.
A complete task succeeds with different entries and errors remain accessible.
For each check, note the context, the action, the expected result and what has been observed. Distinguish a successful verification from a remaining hypothesis. Another person must be able to understand the deliverable without attending all its manufacture.
Use the Functional Validation BookMouse operation on a single screen is not enough. The interface must announce its changes and maintain an understandable state.
Collaboration to explore: Design UI.
Specify the sharing of responsibilities: who provides the information, who decides, who checks and maintains the result. A good handover retains the constraints and decisions, not just the final file.
Employment, trades and trainingExamine a visible feature in ordinary and degraded conditions. The deliverable should explain keyboard behaviour, small-screen use and what happens when a dependency does not respond.
| Skill | Evidence to examine | Failure to spot |
|---|---|---|
| Semantics | Controls use appropriate elements and understandable names. | A clickable element cannot be operated by keyboard. |
| Resilience | Loading, empty and error states can be reproduced. | A network error leaves a blocked interface without explanation. |
| Maintenance | The change is localised and dependencies and checks are known. | Fixing the component breaks other occurrences. |
Download the editable CSV checklist
The file contains this table and blank columns for the observed result, owner and follow-up. It opens in a spreadsheet; downloading it does not send your observations to the site.
Test the component without JavaScript where a basic fallback is intended, then with a slow request. Separate intended behaviour from the observed failure and fix what blocks the user.
Extended exercise: Integrate a filterable list with maps with titles, photos and links. HTML must remain understandable before JavaScript runs. Test a very long title, no response, a slow connection and a language that is written from right to left. Use images adapted to their displayed size and declared dimensions. Check the focus order after an action: Updating the list should not lose the context of the searching person.
These criteria are a working basis to adapt to the context. For each, note the action taken, the expected result, the observed result and the information remaining to be confirmed.
Document dependencies, useful commands and structure decisions. Keep the test data that reproduces long, empty and multilingual cases. When handing over, explain how to add a card and what checks to start again. Proper rendering in a single browser is not enough to conclude on all the conditions of use; Indicate the actual controlled environments.
Choose interactivity according to the task. A readable page and a rich application require different dependencies, states and loading conditions.
Rendering at one width does not validate components. Long content, zoom, translations and missing data change layouts.
Test the same task with a keyboard, on a small screen and with a network interruption. Provide a way to reproduce observed errors.
It allows you to show an approach and its limits. It is neither a diploma, nor a certification, nor proof of a production experience.
Specify that this is an exercise, your role, constraints, decisions and checks. Use test data and media whose rights are established.
A complete task succeeds with different entries and errors remain accessible. Add the difficulties encountered and what remains to be verified rather than presenting absolute validation.
It may provide useful conventions, but structure, labels and behaviour depend on implementation. Check the final workflow with its data, error states and screen adaptations. Choosing a tool does not replace these checks.
