A website can load quickly, look polished and still prevent someone from booking an appointment, reading an explanation or correcting a mistake. Accessibility becomes clearer when we follow a real task from its first instruction to its final confirmation.
The gold standard of web accessibility is a service people with disabilities can perceive, operate and understand through appropriate technologies, supported by evidence about the complete journey. A badge or an automated score is not a substitute for that evidence.
This guide connects Websites with accessible content, interfaces, evaluation and maintenance. Its examples are fictional teaching cases, not an accessibility certification of this website or a legal assessment of any service.
eduKateSG · Web Accessibility
Find your next learning step
Start with the task a person needs to complete, then follow the barriers, tests and repairs that matter.
Full chapter index · Practice and transfer · Education root · How X Works
Full chapter index
Define access · Chapters 1–2
Build clear structure · Chapters 3–4
Test the whole journey · Chapters 5–7
Repair and transfer · Chapters 8–10
Continue the work · Chapters 11–12
Define what someone needs to accomplish before listing technical checks. “Submit a school enquiry and receive confirmation” is more useful than “make the page accessible”, because it identifies a journey that can be examined.
People may use keyboards, screen readers, magnification, speech input or other arrangements. Needs also differ within these groups. Do not treat one person’s successful attempt as evidence that everyone using the same technology will succeed.
In an invented enquiry task, the reader must find the course, understand eligibility, enter information, resolve errors and recognise success. A barrier at the last step can make the earlier steps insufficient. Record both the information needed and the actions required.
The Web Content Accessibility Guidelines 2.2 organise requirements under perceivable, operable, understandable and robust principles. Their testable success criteria provide a shared reference; criteria have different conformance levels.
State the version, level and scope being evaluated. Meeting a few checks on a landing page is not the same as demonstrating conformance for an entire multi-step process. A claim should also identify the evaluation date and relevant limitations.
This guide does not turn a technical standard into legal advice. Requirements can depend on jurisdiction, contract and service context. For learning, practise the narrower discipline: name the criterion, collect suitable evidence and explain what has and has not been assessed.
A clear heading structure helps readers find sections and understand relationships. Meaningful links tell readers where they lead; a series of identical “click here” links can make destinations hard to distinguish outside their surrounding paragraphs.
Consider an original course page with a title, entry requirements, lesson information and an enquiry section. If all section labels are styled paragraphs, visual appearance may suggest structure that the markup does not express. Repair the structure as well as the font.
Ask a learner to summarise the page from its headings. Does the sequence tell a coherent story? Then inspect the actual markup or accessibility information. A visual scan and a semantic inspection answer related but different questions.
A form control needs a name that identifies its purpose. Visible labels and programmatic associations should work together. The W3C WAI labels tutorial demonstrates explicitly associating a label’s for attribute with the control’s id.
An invented contact form uses the visible label “Email address”, a persistent instruction about the required format, and an appropriately associated input. Its placeholder is not the sole instruction: text that disappears while typing is a weak place to keep essential information.
Now compare a button visually labelled “Send enquiry” with an accessible name that says only “Submit 2”. The mismatch should prompt investigation. Record what the control looks like, what assistive technology reports and what action it performs. The strongest repair aligns the intended action across these layers.
Try the complete task without a pointing device. Can the user reach the needed controls, activate them and leave each component? Can they tell where the keyboard focus is? A control’s presence on screen does not establish operability.
Use a short test script: open the menu, choose the course, move to the enquiry fields, intentionally trigger a recoverable error, correct it and submit. Record the actual focus sequence and where the journey stops, not simply “keyboard checked”.
The WCAG 2.2 Understanding documents explain the relevant criteria. A custom component may require a particular interaction pattern; do not invent keyboard behaviour merely because a mouse interaction looks intuitive. Prefer established native controls where they fit the task.
CHAPTER 6 OF 12 · Test the whole journey
6. Errors and completion belong to the same journey
An accessible form must support recovery, not just a correct first attempt. If a required field is missing, the person needs to understand what went wrong and how to repair it. Essential information should not depend solely on a red border.
| Journey step | Useful check | Evidence to retain |
|---|---|---|
| Find the form | Destination and heading are clear | Page and link description |
| Enter information | Controls have usable labels | Control and reported name |
| Recover from error | Problem and correction are explained | Error state and recovery steps |
| Finish | Success is identifiable | Confirmation state and message |
Suppose the system accepts the enquiry but displays no clear confirmation. Repeated submission might follow even when the earlier input controls work. Repairing that uncertainty is part of the task. The test should establish the intended result without publishing real student or family information.
Choose text alternatives according to an image’s purpose. A decorative flourish and a diagram explaining a process do different jobs. A complex chart may need an adjacent explanation or data presentation, not an unhelpfully long filename repeated as alternative text.
The WAI images tutorial distinguishes image purposes. For media, consider the information carried through audio and video rather than assuming a transcript, captions and audio description are interchangeable.
In a teaching example, a demonstration silently shows a required control changing colour. Captions alone would not explain that visual instruction if no corresponding speech exists. Ask what information a learner would miss when one channel is unavailable, then provide an appropriate equivalent. Also examine zoom, readable contrast and layout rather than treating text alternatives as the whole accessibility task.
An original audit samples twenty task scenarios and finds five that fail a stated check. That is five failures in the tested sample, or 25%. It is not a proof that the whole service is “75% accessible”. The untested scenarios and the seriousness of each barrier still matter.
One failure that blocks payment or enquiry completion may have a different impact from a small content issue. Track affected tasks and users alongside counts. Keep the numerator, denominator and sampling method visible.
The WAI evaluation overview explains the role of tools and human evaluation. Automated checks can reveal some issues; they cannot decide every question of meaning, usability or complete conformance. Combine appropriate methods rather than allowing a single score to close the investigation.
A successful test describes a particular version and environment. New content, embedded services, design changes and form updates can introduce barriers. Record the version, browser or assistive technology used where relevant, the steps and the observed result.
Give each confirmed issue an owner, repair plan and retest condition. If a menu fix is made, retest the original failure and nearby journeys that use the same component. A changed screenshot alone is not evidence that the underlying interaction works.
Invite clear feedback while protecting privacy. A person should be able to report the task and barrier without being required to disclose unnecessary medical or personal information. A feedback route complements proactive testing; it does not transfer the responsibility for finding all barriers to disabled users.
Task A: Twenty scenarios are tested; five fail. After repairs, two still fail when the same sample is retested. Calculate the sample failure rate before and after. Check: 25% and 10%. State the limit: neither figure alone establishes site-wide conformance or equal severity.
Task B: A booking form works on the first page, but a third-party calendar cannot be operated by keyboard. Has the complete booking journey passed? No. Investigate the actual required calendar interaction and an effective repair or equivalent route; do not count the first page as the whole service.
Transfer task: A new language version is introduced. Keep the task-based method, but recheck labels, instructions, reading order, content expansion and error messages. A translation does not inherit every tested property automatically. Explain which evidence can be reused and which needs new observation.
Design and complete tasks
- Websites — connect accessibility with the wider service.
- WCAG and Global Connectivity — examine cross-border participation.
- Accessible Online Form Design — follow completion and recovery.
- Accessible E-Commerce — investigate a transaction journey.
- Accessible E-Learning — connect lessons with assessments.
Testing, content and sustained access
- Accessibility User Research — involve people respectfully.
- Video Accessibility — distinguish media requirements.
- Accessible Website Maintenance — preserve working journeys.
- Accessibility Statements — make claims match evidence.
- Barrier Feedback and Resolution — connect reports with verified remedies.
Does an automated pass prove accessibility?
No. It supplies evidence about what the tool checked, not every required criterion or user task.
Should every image have a long description?
No. The appropriate treatment depends on purpose and context. Decorative and complex informative images need different decisions.
What should I do first?
Choose one important journey, define its success state and test it with an appropriate mix of technical checks and user evidence. Keep the error path in scope.
- WCAG 2.2 — the technical standard.
- WAI evaluation resources — methods and limits.
- WAI labels tutorial and images tutorial — practical content guidance.
Continue through Education and How X Works. The transferable skill is to follow the whole task, identify the barrier and verify the repair.