WebInclusiveby Giuseppe Stumbo

Templates and exercises

You can practise independently here without requesting a workshop. Want to understand how to describe a barrier and prepare its assessment? Read the completed examples, then choose an exercise. Write your submission in a document and compare it with the guidance. For a guided programme on your team's product, see the Training service.

Materials or lab: choose where to start

Start with examples to understand their structure, or choose an exercise and practise. Each path explains what to do and what result to prepare.

  • Materials: consult the examples

    Follow the contact form case: from the problem to a proposed fix and retest plan. The three completed documents show the information needed by someone reading a bug report and by someone correcting or verifying the defect.

    Expected result: Understand what information to collect, how to document it and which tests to plan. These are fictional reference examples to adapt to your context.

  • Lab: complete an exercise

    Choose one of the four exercises and read the scenario and activities. Prepare the «Deliverables» in your document, then use «Check the result» and compare your work with the example answer. Work alone or with your team.

    Expected result: A submission to review: text and error handling, keyboard behaviour, a bug report or a summary of tests and decisions. Record real test outcomes only after performing the tests.

Who it is for
Designers, developers, QA and product contacts, individually or in groups.
What you can produce
An exercise submission: component text and behaviour, a bug report or an assessment plan.
How you work
Read the examples, choose an exercise and write your submission in a document or the team's tools.

Materials: guided contact form case

For reference. Look at the three screens, then use the five tabs to follow context, issue reporting, evidence, proposed fix and retest plan. The sequence shows how to document the work; the described tests remain to be performed.

Fictional demonstration scenario, not a client project. The product, versions and initial behaviour are invented; no tests have been performed on the described form. The evidence shown here is illustrative and retesting remains to be done.

The case in three screens

Three demonstration screens: generic error, proposed fix and expected confirmation. The descriptions also include the example text.

Generic error

The alert does not identify the field to correct.

Name: Mario Rossi. Email: mario@. Message: I would like information about an accessibility audit. Alert: «An error occurred». Button: «Send enquiry».

Error associated with the field

The message identifies the email and suggests the format.

Name: Mario Rossi. Email: mario@. Message: I would like information about an accessibility audit. Error: «Enter a complete email address, for example nome@example.com». Button: «Send enquiry».

Expected confirmation

Confirmation appears after a successful server response.

Name: Mario Rossi. Email: mario@example.com. Message: I would like information about an accessibility audit. Status: «Enquiry received». Confirmation does not demonstrate email delivery.

FORM-DEMO-001

Fictional scenario

Context and scope

  • Objective and scope

    An imaginary consultancy website collects enquiries through required name, email and message fields. The assessment objective is to let people identify and correct errors without losing data. The sample includes an empty form, invalid email, correction, successful submission and server error. Email delivery, anti-spam, privacy and the rest of the site are excluded.

  • Planned environments

    Illustrative component: sito-demo.example/contatti, pre-fix version demo 1.0, candidate version demo 1.1. Planned environments: Windows with Chrome and NVDA; iPhone with Safari and VoiceOver. A real assessment records exact versions, settings, date and build for each test.

Issue report FORM-DEMO-001

  • Issue report

    Title: errors do not identify the fields to correct. Planned reproduction: open the form, complete the name and message, enter «mario@» in the email field and activate «Send enquiry» using only the keyboard.

  • Results and impact

    • Simulated initial behaviour: «An error occurred» appears; the email border turns red, but there is no textual explanation of the problem and focus stays on the button.
    • Expected result: identify the invalid email, explain how to correct it and make the message available to screen readers too, while retaining other values.
    • Impact: someone who cannot see colour or uses a screen reader must search for the cause of the failed submission; the generic message also leaves readers unsure what to correct.
    • Proposed priority: high within the demonstration flow, because the enquiry cannot be completed without correcting the error. This is not a WCAG-assigned severity; in the real product, justify it using frequency, impact and alternatives.

Illustrative evidence and requirements

Proposed fix and responsibilities

  • Actions and responsibilities

    • Content and design: indicate «required» in labels and use «Enter a complete email address, for example nome@example.com». Colour accompanies the text rather than replacing it.
    • Development: keep native HTML controls and associated labels; on error, set aria-invalid and associate the message with the field. In the chosen flow, move focus to the first invalid field after submission without clearing data.
    • Development: validate on the server too; prevent duplicate submissions while the request is in progress. Announce confirmation through a status region without moving focus; for a technical error, retain values and allow another attempt.
    • QA: check keyboard use, focus, error reading and status messages. Dependencies: a server response distinguishing data errors from technical errors, approved text and a test environment that does not send to real recipients.

  • Expected behaviour and risks

    After the fix, expected behaviour is: focus on email, a specific message associated with the field and retained data. Confirmation is expected only after a successful server response: «Enquiry received». It does not promise email delivery. Regression risks: duplicate announcements, stale errors after correction, obscured focus on mobile and unintended value clearing.

Retest plan and acceptance criteria

Retesting repeats the defect tests to verify resolution; regression tests check how changes affect related behaviour, such as data retention and submission. This list collects the tests to perform before closing FORM-DEMO-001: it is an assessment plan, not an achieved result.

  • Empty form

    Acceptance criterion
    Each unfilled required field has a text error; the first receives focus after submission.
    Status
    To be performed

  • Invalid email

    Acceptance criterion
    The message identifies the problem, suggests the format and is read with the field in both planned environments.
    Status
    To be performed

  • Data correction

    Acceptance criterion
    The error is removed on revalidation; name and message remain unchanged, and focus does not jump while typing.
    Status
    To be performed

  • Successful submission

    Acceptance criterion
    Confirmation appears and is announced after the successful response; focus remains appropriate and only one request is sent.
    Status
    To be performed

  • Server error

    Acceptance criterion
    The message distinguishes the technical problem from field errors; values remain available and another attempt is possible.
    Status
    To be performed

  • Keyboard and mobile

    Acceptance criterion
    The flow can be completed without a mouse, focus is visible and messages are not clipped at 320 px or with enlarged text.
    Status
    To be performed
Case status

Proposed fix; no retest result available. All six tests remain to be performed.

When to consider the issue resolved

After testing the corrected version in the planned environments and recording dates, versions and evidence. If a test fails, the bug remains open; any residual risks must be documented.

Example limitation

The plan concerns only this form and the specified environments: it does not cover every assistive combination and is not a conformance statement.

Materials: completed bug report, fix and retest

For reference and adaptation. These three fictional documents show how to connect an issue report, corrective work and the corresponding verification result. For your submission, reuse the field structure and include only data and evidence from the case you are addressing.

Bug report

Teaching scenario: a basket button without an accessible name.

ID

DEMO-A11Y-001

Title

The button for removing an item has no accessible name.

URL, screen or component

negozio.example/carrello — bin icon button beside the jacket.

Environment

Windows, Firefox, demo build 1.4.0. In a real test, state the system and browser versions.

Assistive technology, if used

NVDA, default settings. In a real test, state the version.

Steps to reproduce
  1. Open the demo basket containing a jacket.
  2. With NVDA on, use Tab to reach the bin button.
  3. Listen to the name before activating the button.
Expected result

The screen reader announces a button named «Remove jacket from basket».

Observed result

The screen reader announces an unnamed button.

User impact

Someone using a screen reader does not know which item will be removed.

Severity

High in the example: it is the only removal control. Reassess in the real product.

Related requirement

WCAG 4.1.2 — Name, Role, Value: the button must have an accessible name.

Evidence

NVDA recording and accessibility tree with an empty name. Fictional evidence: DEMO-A11Y-001-prima.

Remediation

Teaching scenario: correcting the button, responsibilities and acceptance criteria.

Owner

Demonstration shop's frontend team; QA responsible for retesting.

Area involved
  • Development: correct the button name in the basket component.
  • QA: repeat the keyboard and NVDA test.
Proposed fix

Give the native button a name including the action and item: «Remove jacket from basket».

Dependencies

Item name available in the component and text translated into the product's languages.

Regression risk

Incorrect names with multiple items; check focus after removal.

Acceptance criterion

Each button identifies its item, is reachable with Tab and removes the correct item.

Retest

Teaching scenario: recording the result after correcting the button.

Retest date

6 October 2026 — illustrative date, demonstration build 1.4.1.

Outcome

Passed in the example: NVDA identifies the action and item; keyboard removal works with two items too.

Evidence that the fix works

Recording and accessibility tree after the same steps. Fictional evidence: DEMO-A11Y-001-dopo.

Remaining notes

Only Firefox/NVDA in the example. Other planned configurations remain to be tested.

Lab: choose and complete an exercise

Four fictional scenarios, each with activities, deliverables, an example answer and verification criteria. Open an exercise, write your submission in your document and check it before comparing it with the example.

Exercise 1 - Make form errors understandable

Scenario

Fictional form with required name, email and message fields. Entering «mario@» shows only «Invalid data» and the form clears the message. After successful submission, the button changes colour but no text confirmation appears.

Activity

  • Write labels and instructions for the three fields, identifying which are required.
  • Prepare text for an empty field, invalid email, successful submission and server error.
  • Describe focus, error-to-field associations and data retention after submission.
  • Define how to make confirmation available to screen readers too, without duplicate announcements.

Deliverables

  • Field text and text for the four states.
  • Focus sequence and three tests: invalid email, successful submission, technical error.

Example answer

Invalid email: «Enter a complete address, for example nome@example.com». After submission, focus moves to the email field; the name and message remain filled in.

Check the result

  • Can people understand what to correct without relying on colour?
  • Does each test specify expected text, focus and data to retain?
  • Does confirmation depend on a successful server response, rather than the click alone?

Exercise 2 - Design keyboard navigation

Scenario

Fictional navigation with «Services», a clickable page, and two subpages: «Audit» and «Training». The submenu opens only on mouse hover. On mobile, a modal panel covers the page, but Tab still reaches links underneath.

Activity

  • Separate the «Services» link from the button opening its subpages.
  • Draw the Tab and Maiusc+Tab journey with the submenu closed and open; specify Invio, Spazio and Escape.
  • For the mobile modal panel, define initial focus, focus containment and return to the opening button.
  • Specify the button's expanded state. Do not impose application-menu behaviour on ordinary link navigation.

Deliverables

  • Desktop and mobile diagrams with focus order.
  • Tests for opening, closing and accessing all three pages without a mouse.

Example answer

On desktop: Tab reaches the «Services» link, then the subpage button. Invio opens the submenu; Tab reaches «Audit» and «Training». Escape closes it and returns focus to the button.

Check the result

  • Can the «Services» page still be reached without opening the submenu?
  • Are hidden links excluded from the Tab sequence?
  • Does the mobile panel close with the keyboard and return focus?

Exercise 3 - Turn a note into a reproducible bug

Scenario

Fictional QA note: «In the basket, I cannot tell which item I am removing». There are two products, «Blue mug» and «Green mug», and two buttons with the accessible name «Remove». The environment, steps and expected result are missing.

Activity

  • Write a title, initial conditions and steps to reach both buttons.
  • Separate observed behaviour, expected result and impact on people using a screen reader.
  • Propose distinguishable names and a justified priority; identify information still to collect.
  • Define a retest for each product without claiming tests that were never performed.

Deliverables

  • A bug report with numbered steps, impact and proposed fix.
  • A list of missing tests and results needed to consider the issue resolved.

Example answer

Expected: «Remove Blue mug» and «Remove Green mug». Retest: check that each button identifies the product and removes only the chosen one. The environment and actual spoken output remain to be documented.

Check the result

  • Can a colleague reproduce the issue without asking for more steps?
  • Does the impact describe a concrete barrier, rather than just «inaccessible»?
  • Are provided facts, assumptions and missing information distinguished?

Exercise 4 - Connect tests, fixes and decisions

Scenario

Three fictional notes on a contact form: invalid email was checked with the keyboard; NVDA reading of the error was not tested; submission confirmation still needs fixing. The manager asks whether the form is ready for release.

Activity

  • Create a matrix with test, environment, evidence, status, owner and next step.
  • Distinguish what the note says from what is demonstrated: the keyboard test also requires attached evidence.
  • Plan the NVDA check and confirmation retest after the fix.
  • Write a justified release decision limited to the sample and available information.

Deliverables

  • A three-row matrix with missing evidence and assigned actions.
  • A decision note with release conditions and assessment limitations.

Example answer

NVDA error reading: not tested; owner: QA; next step: perform the test on the release candidate and attach environment, date and outcome. Do not record «passed» based solely on keyboard testing.

Check the result

  • Is every status supported by evidence or marked as requiring verification?
  • Do outstanding activities have an owner and a verifiable expected result?
  • Does the note avoid declaring the whole site conformant based on three form tests?
Read the materials' reuse conditions