DIGITAL ACCESSIBILITY / COGNITION & CONTENT
Help people find their way, understand choices and recover from mistakes. Explore practical guidance, then use the content clarity workshop to plan and review a real message.
Cognitive and learning access needs vary. A person may need support with language, attention, orientation or memory in a particular task. Do not infer a diagnosis from how someone uses a page.
Supplemental guidance, not extra WCAG pass criteria. W3C’s Making Content Usable for People with Cognitive and Learning Disabilities is a Working Group Note. Its COGA design patterns extend beyond WCAG conformance requirements. Use them alongside the relevant WCAG success criteria and research with people who will use the service.
01 / ORIENTATION
Use familiar controls and consistent names. Show what the page is for, where someone is in a process and what the main action will do. A progress label is useful only when it matches the real journey.
Try: Replace a button named “Proceed” with “Review your course choices”. Keep a visible route back to those choices.
02 / LANGUAGE
Prefer familiar, literal words and direct instructions. Explain necessary specialist terms. Separate actions into manageable steps and give long material a useful summary. Preserve meaning when shortening text.
Try: State the action first, then the information needed and the deadline. Write the month in words when a numerical date could be misread.
03 / MEMORY
Let people refer to earlier choices and avoid having to remember a code or instruction from another screen. Support recognised ways to sign in without unnecessary memory tests.
Try: On a course review screen, show the course name and selected session beside its Edit link. Do not require the reader to reconstruct their choices.
04 / ATTENTION
Reduce unrelated interruptions. Explain prerequisites before work starts. Use meaningful headings so someone can return to the right place after a distraction.
Try: List the information needed before a form opens. Keep promotional messages out of the path between entering details and checking them.
COGA: Help users focus.
05 / RECOVERY
Give clear feedback and a specific way to fix a problem. Allow people to go back and correct entries. Explain what will happen before an action changes or loses work.
Try: A failed save should explain whether a draft remains available and where to retry. Test those claims against the actual system.
06 / CHOICE & SUPPORT
Support familiar presentation preferences and control over changing content. Make help and feedback easy to find. A simpler view can keep the main task clear while preserving access to important detail.
Try: Offer a quiet reading view and a visible way to restore the full view. Test both with the reader’s own tools.
COGA: Personalization and help and support.
Plan one message, compare your drafts and collect evidence from human review. All fields are optional working notes. Your work stays in this tab and is not saved automatically. Download a text report before leaving.
Changing the task type or context keeps both drafts. The tool does not rewrite, translate or judge the meaning of your text. Maximum 20,000 characters per draft is a tool limit, not an accessibility threshold.
Counts are editing cues, not a clarity score. Paragraphs are blocks separated by a blank line. Approximate character counts may count a combined symbol more than once. English estimates use simple word and sentence boundaries and may misread abbreviations, numbers or names.
25 words is a workshop prompt for human review, not a W3C rule or a pass/fail boundary. A longer sentence can be clear; a short one can be confusing.
These six questions are an editorial review aid, not a conformance test. Draft changes keep your review notes, so check that the evidence still describes the current wording. Record observations without names or unnecessary personal details.
The report includes current context, both drafts, observation settings and all review notes. Printing produces a complete report with expanded text. Download before replacing a draft with an example or resetting.
These fictional examples illustrate writing choices. Use them only where their promised behaviour is true. Loading an example replaces the workshop after confirmation if it contains work.
Before: “Non-confirmation of your scheduled attendance prior to the stipulated deadline may result in cancellation.”
Please confirm your library appointment by 4 pm on 18 September 2026 (Maldives time). Select “Confirm appointment” to keep your booking for 21 September at 10 am. If you do not confirm by the deadline, your booking will be cancelled. Need a different time? Select “Change appointment”.
Review: Check the date, cancellation rule and the two action labels against the real service. Do readers understand what happens if they do nothing?
Before: “Session invalid. Reinitiate the transaction.”
You have been signed out after 30 minutes without activity. Your course choices are saved in your account. Sign in again to continue from the review step. If you cannot sign in, select “Get sign-in help”.
Review: This wording cannot fix a timer. Verify the actual time controls and saved state. Never promise saved work unless the system retains it.
Before: “Applicants are required to furnish all particulars and undertake the necessary selection prior to finalisation.”
Register for the introduction to accessible design course. 1. Enter your name and email address. 2. Choose a session. 3. Select “Review registration” to check your details before sending them. You can change your choices on the review page. For help, select “Contact the course team”.
Review: Check whether the course has eligibility rules or costs that must be explained before registration. Confirm that the review page allows changes.
These are selected WCAG 2.2 criteria, with links to their informative explanations. Assess the normative criterion and its exceptions in the actual page or process. A clear message alone cannot establish conformance.
3.3.2 / LEVEL A
Provide labels or instructions when asking for input, including optional inputs. Explain necessary formats or rules. Programmatic relationships and accessible names also need separate checks. Understanding 3.3.2.
3.3.3 / LEVEL AA
When an input error is detected and a correction is known, provide a suggestion unless it would compromise security or the content’s purpose. Understanding 3.3.3.
3.3.7 / LEVEL A
In the same process, make previously entered or provided information available to select or populate it automatically when it is needed again. Exceptions cover essential re-entry, security and information that is no longer valid. Browser autocomplete alone is not sufficient. Understanding 3.3.7.
3.2.6 / LEVEL A
When specified help mechanisms repeat across a set of pages, keep their relative order consistent unless the user initiates a change. This criterion does not require adding a help mechanism to every page. Understanding 3.2.6.
2.2.1 / LEVEL A
For a time limit set by content, meet the applicable option for turning it off, adjusting it or extending it, unless an exception applies. A warning message by itself is not enough. Understanding 2.2.1 and its conditions.
Invite people with varied cognitive and learning disabilities early enough to change the design. Offer accessible consent, instructions, breaks and preferred ways to communicate. Ask people to try meaningful tasks with their usual support. Record barriers and suggested changes rather than testing the person.
Try the revised journey again after changes. A checklist or a few participants cannot establish that every need is met. W3C’s COGA usability testing guidance explains how to involve users.
Test the actual interface in the interaction lab, record a broader review in the testing worksheet, or explore more in the digital accessibility hub.
Sources checked 15 September 2026. The workshop prompts and examples are original editorial aids. They do not assign a reading grade, diagnose a disability or certify accessibility.
