Define a readable interface, its components and their states.
These sheets describe activities and teaching exercises. They do not constitute job offers, certifying courses or recruitment promises.
All job descriptions
Make screens and components readable, consistent and usable through visual hierarchy, typography, colour, spacing and interaction states.
A mockup alone does not demonstrate accessibility or feasibility. Check it against UX findings, development constraints and the working interface.
Deliver a component with states, content rules and validation criteria instead of an isolated ideal screen.
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
Design the same product sheet with a long name, an absent image and a selection error.
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.
Screens, a component library, and integrating state specifications.
explicit rules and components that remain understandable in their less favorable states.
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 BookA model with only the ideal case does not describe how the interface works. Translated texts and incomplete content should also be reviewed.
Collaboration to explore: Web integration.
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 trainingExtended exercise: Design the statements of an application form, from the first entry to the receiving message. Plan the keyboard focus, an invalid field, an ongoing sending and a connection error. Work with realistic content and longer translation. Describe the role of each color and icon: essential information must also be expressed by text. The result to be delivered is a consistent state system, not just a capture of the empty form.
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.
Deliver the components with their states, texts and constraints. Indicate what falls under a general rule and what responds to a particular case. Discuss behaviors with the person who integrates the interface, then check the result in the browser. A static mockup does not alone prove that the form is usable on the keyboard or that its errors are correctly announced.
Compare changes to an individual screen with changes to shared components. Choose according to how often the problem occurs and which pages use the same elements.
Contrast and font sizes alone do not establish accessibility. Check labels, states, relationships and interactions in the implemented interface.
Show the screen before and after using the same task and content. Check that the improvement remains consistent on a second page.
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.
explicit rules and components that remain understandable in their less favorable states. Add the difficulties encountered and what remains to be verified rather than presenting absolute validation.
When an identified need cannot be met without making the existing use ambiguous. Document the difference and affected states. An isolated aesthetic preference does not justify a variant that is difficult to maintain across pages.
