Cognitive accessibility makes important information, choices and digital tasks understandable and manageable for people with differing memory, attention, language and processing needs. Its gold standard is not ‘simple words everywhere’: it is truthful guidance, predictable interactions and a dependable way to recover from mistakes.
This guide follows fictional continuing-education portal Daylight Skills Voucher, where complex eligibility text, lost form entries and an unnecessary countdown prevent otherwise eligible users from completing an application. The solution is to improve how the whole journey works, not merely rewrite its homepage.
It complements Digital Accessibility Testing Services, Accessible Forms Design Services and Plain Language Editing Services. This sector article concentrates on cognition-aware service design and ongoing user agency.
What you should decide before commissioning a service
- **User goal:** What must someone understand, choose and complete?
- **Barriers:** Which memory, attention, reading and recovery demands are created by the interface?
- **Standards:** Which WCAG requirements apply and which COGA recommendations are supplemental?
- **Proof:** How will real users and qualified reviewers verify independent task completion?
Chapter navigation
23-chapter practical index
Understand cognitive needs and information — Chapters 1–6
- Cognitive access means a person can understand and act
- Recognise that cognitive needs vary widely
- Keep normative WCAG criteria separate from supplemental guidance
- Use clear information architecture before simplifying sentences
- Write with plain language while preserving necessary precision
- Replace vague calls to action with clear choices
Choices, forms and recovery — Chapters 7–13
- Keep navigation in consistent, recognisable places
- Show one meaningful step without concealing the whole process
- Let people avoid mistakes before requiring corrections
- Make error recovery calm, specific and possible
- Avoid redundant questions within the same process
- Support account access without unnecessary memory tests
- Give people time and control without artificial pressure
Help, comprehension and participation — Chapters 14–19
- Make important information stable and easy to revisit
- Provide meaningful confirmation and reversible next steps
- Offer help in context without shaming the user
- Support more than one way to understand a complex idea
- Treat numbers and choices as practical decisions, not puzzles
- Use respectful language without diagnosing interface users
Evidence and lasting usefulness — Chapters 20–23
1. Cognitive access means a person can understand and act
A fictional continuing-education organisation launches the Daylight Skills Voucher portal. The eligibility page uses long policy sentences, a blinking urgency banner, several unfamiliar subsidy categories and a countdown timer. A user picks the wrong route, goes back and loses the information already entered. Nothing is technically ‘broken’: the system simply demands more memory, interpretation and correction effort than some visitors can manage.
The gold standard of cognitive accessibility services is a product that makes important information understandable, guides people through meaningful choices and supports recovery from mistakes. It is not a claim that one design serves everyone perfectly or that an individual must disclose a diagnosis before receiving help. The fictional voucher system demonstrates how seemingly minor interface decisions combine to prevent real people from completing ordinary tasks.
What the user should be able to do: an applicant can explain available choices, select a suitable route, review information and finish without relying on a staff member to decode the website.
Back to chapters · Next chapter
2. Recognise that cognitive needs vary widely
Cognitive accessibility concerns differences in memory, attention, language processing, learning, problem solving, perception and understanding. A person may prefer concise text but still need full technical details, or may benefit from predictable controls without wanting simplified content. It is unhelpful to define one universal cognitive user profile.
W3C’s cognitive-accessibility overview describes how digital design can create or remove barriers for people with cognitive and learning disabilities. Designers should involve people with relevant experiences and avoid stereotyping conditions or assuming intelligence from a person’s reading speed. The design goal is options, structure, clear language and dependable task completion, not labelling every user.
What the user should be able to do: the brief states tasks and observed barriers rather than ranking users by presumed ability or asking for unnecessary personal diagnoses.
Back to chapters · Next chapter
3. Keep normative WCAG criteria separate from supplemental guidance
WCAG 2.2 contains testable success criteria, including relevant requirements for labels, errors, navigation, redundant entry and authentication. W3C also offers cognitive accessibility design patterns that go beyond minimum conformance. Both are useful, but they have different status and must not be marketed as identical rules.
Making Content Usable for People with Cognitive and Learning Disabilities is a W3C Working Group Note providing supplemental guidance, not an additional mandatory WCAG success-criterion set. A website can satisfy some formal criteria while remaining confusing in important ways; meeting an optional pattern does not cancel a required criterion. Report standards conformance and broader usability outcomes in separate, honest terms.
What the user should be able to do: every design recommendation is labelled either against a relevant WCAG requirement or as additional user-centred guidance.
Back to chapters · Next chapter
4. Use clear information architecture before simplifying sentences
A site can contain short, easy words yet remain difficult to navigate when topics are grouped unpredictably. People need an understandable route to eligibility, application, evidence requirements and the decision they are making. A menu that mixes audiences, departments and product names may force repeated trial and error.
For Daylight, organise pages around user questions: Am I eligible? What support is available? Which details do I need? How do I apply? A hierarchy should remain consistent as users move through steps. W3C’s cognitive guidance on finding content encourages predictable location and effective navigation. A user should not need to memorise the website’s internal organisational structure to choose a voucher.
What the user should be able to do: new users can locate the eligibility explanation and application without being told which government-style department name to search for.
Back to chapters · Next chapter
5. Write with plain language while preserving necessary precision
Clear text should identify the main decision early, use familiar terms where suitable and explain specialised language when needed. Plain language does not mean omitting conditions, removing technical safeguards or treating adults as children. An applicant needs both an understandable summary and access to the details that govern the actual choice.
ISO 24495-1:2023 is the published international plain-language standard for primarily textual information. It does not automatically certify an entire digital interface or replace accessibility standards. For the fictional voucher, ‘You may qualify if…’ followed by a short explanation can be clearer than one dense paragraph of cross-references, provided the eligibility information remains accurate and complete.
What the user should be able to do: a reader can state the main rule and find the precise exceptions without guessing which condition was silently omitted.
Back to chapters · Next chapter
6. Replace vague calls to action with clear choices
Buttons reading ‘Proceed’, ‘Learn’, ‘Continue’ and ‘More’ can be ambiguous when a person is unsure which service they selected. A useful control describes the action and what it affects. If two routes lead to different obligations, the distinction belongs near the choice rather than only in a policy document elsewhere.
Daylight could label its options ‘Check course eligibility’ and ‘Apply for a training voucher’, followed by concise descriptions. The interface should not push a learner into completing a form before explaining whether it fits their goal. W3C’s understandable controls guidance recommends familiar patterns and identifying a control’s purpose. Familiarity helps users spend attention on the decision, not on decoding interface jargon.
What the user should be able to do: participants can predict what each prominent button will do before they activate it.
Back to chapters · Next chapter
7. Keep navigation in consistent, recognisable places
When buttons, links and help move unpredictably among pages, people must repeatedly relearn the interface. Consistency is especially important during longer application journeys that users might leave and return to later. A redesign between steps can feel like entering another organisation’s site.
Use a stable top-level navigation, clear current-step indication and meaningful back and forward controls. WCAG 2.2 Consistent Help at Level A addresses the relative order of certain repeated help mechanisms, with its precise conditions. The broader design lesson is predictable assistance, not a requirement that every screen contain identical decorative elements. Test at different supported screen sizes and interface states.
What the user should be able to do: a returning applicant can find help and their place in the process without recalling last visit’s exact visual layout.
Back to chapters · Next chapter
8. Show one meaningful step without concealing the whole process
Long forms can feel overwhelming when every detail appears at once, but splitting them into too many unexplained stages creates another burden. People need to know the total journey, what each step asks and whether earlier answers remain available. Progress indicators should communicate reliable facts, not artificial urgency.
A Daylight form might show eligibility, personal details, course selection, documents and review as five named stages. Provide a summary of what is needed and a clear path backward. Do not show a false ‘almost finished’ bar when substantial work remains. Break sections at meaningful boundaries and preserve context. The aim is a manageable process whose structure users understand, not an excessive number of clicks.
What the user should be able to do: a participant can tell which step is current, what remains and how to review previous entries without losing data.
Back to chapters · Next chapter
9. Let people avoid mistakes before requiring corrections
Design can prevent mistakes by using clear field descriptions, visible requirements, appropriate examples and input methods suited to the information. Long mandatory reference numbers or arbitrary formatting rules increase memory and transcription demands without necessarily improving accuracy.
W3C’s cognitive pattern on supportive forms recommends minimising unnecessary information, indicating required fields and accepting reasonable input formats. For Daylight, a mobile number field should explain why it is needed and accept common formatting variations where the system permits. Avoid demanding the same factual declaration twice merely because different departments built adjacent form stages.
What the user should be able to do: typical applications contain fewer avoidable field errors, without weakening legitimate validation or privacy safeguards.
Back to chapters · Next chapter
10. Make error recovery calm, specific and possible
A generic red banner saying ‘Invalid application’ does not tell a user which problem occurred or how to fix it. Error messages should identify the relevant field and explain the next action. A user who made a mistake should remain able to continue without repeating unrelated work.
For the fictional voucher, ‘Please add a course start date’ is more useful than ‘Error code 402’. Provide review and correction at an appropriate stage. W3C’s cognitive undo guidance emphasises checking work and returning after changes, while normative WCAG criteria separately address error identification and suggestions. The design should reduce anxiety by making mistakes reversible where lawful and practical.
What the user should be able to do: applicants resolve a representative missing document or wrong date without contacting support or restarting.
Back to chapters · Next chapter
11. Avoid redundant questions within the same process
Requiring people to re-enter the same data at different steps adds unnecessary cognitive effort and creates inconsistent records. It is particularly frustrating when the interface has already received and validated the information. Some repeat entry may be justified for security or because earlier information is no longer valid, but those exceptions should be deliberate.
WCAG 2.2 Redundant Entry, criterion 3.3.7, at Level A, requires previously entered information to be auto-populated or available to select within the same process, subject to specified exceptions. Daylight should not ask for an email address on every page as if the previous one never existed. Use sensible privacy protections when retaining application data.
What the user should be able to do: a user can advance through steps without reconstructing details they have already provided, except where a stated exception genuinely applies.
Back to chapters · Next chapter
12. Support account access without unnecessary memory tests
Passwords, authentication codes and puzzles can create barriers for people who cannot readily recall or transcribe details. Authentication still matters for privacy and security, but it should be evaluated for accessible mechanisms rather than designed around unaided memory alone.
WCAG 2.2 Accessible Authentication (Minimum), criterion 3.3.8, at Level AA, includes defined alternatives and assistance mechanisms. It does not categorically ban passwords or all passcodes. For Daylight, check whether supported password managers and copy-paste can be used where relevant, and whether any extra cognitive test meets the criterion. A secure login that a legitimate applicant cannot complete is not a satisfactory service experience.
What the user should be able to do: participants can sign in or recover access through an approved, operable path without solving an arbitrary memory challenge.
Back to chapters · Next chapter
13. Give people time and control without artificial pressure
Countdowns, automatically advancing slides, disappearing help and unexpected logouts can remove a person’s opportunity to read, deliberate or correct. Some services have legitimate timeouts or limited appointment windows, but the requirements should be clear and their effects manageable.
Tell users what is time-limited and why. Where applicable, support extension, saving or warning before session expiry. A flashing scarcity message in the fictional learning voucher does not make the eligibility decision better informed. WCAG Timing Adjustable has defined criteria and exceptions that must be applied accurately. Avoid making a marketing timer behave like an official submission deadline when no such rule exists.
What the user should be able to do: an applicant can read and complete the ordinary form at an appropriate pace, and is warned about relevant session constraints.
Back to chapters · Next chapter
14. Make important information stable and easy to revisit
People may need to consult an eligibility threshold, allowable course type or required document several times while applying. If help disappears as soon as focus moves, users must rely on working memory. Important definitions should remain findable at the point of action without covering the form or forcing someone to navigate away.
Daylight could give a short expandable explanation beside the relevant course-selection decision, with a stable link to the full policy. Ensure the same terms mean the same thing throughout the application. The design should not hide critical qualifications behind an icon without a name. Let users revisit supporting information and resume work. This helps people compare options without recalling every sentence from the landing page.
What the user should be able to do: a user can answer why a course qualifies using information available during the decision, not from memory of an earlier screen.
Back to chapters · Next chapter
15. Provide meaningful confirmation and reversible next steps
A completed submission should give clear evidence of what happened. A generic success animation without the selected course, reference or next action leaves a user unsure whether the voucher application was saved. People may submit again unnecessarily, creating duplicate records or anxiety.
Show the actual submitted status, relevant reference when available, expected next step and how to amend mistakes within the service’s true terms. Do not invent an approval date or imply funding was granted when the system only received an application. The confirmation should remain available in accessible formats. A friendly message is useful only when it accurately describes the action completed.
What the user should be able to do: a participant can explain whether the application was submitted, approved or still being reviewed without asking staff to interpret a celebratory graphic.
Back to chapters · Next chapter
16. Offer help in context without shaming the user
Support may include short examples, guided explanations, phone or chat contact, an assisted service route and documentation. Users should not be forced to reveal a diagnosis to see help that can reasonably be offered to everyone. A support mechanism is effective when it answers the immediate obstacle without making the person abandon all progress.
Place help where the difficulty occurs and keep repeated mechanisms predictably positioned. Staff also need clear boundaries for accessing an applicant’s personal information. Daylight could offer a concise definition of ‘approved course’ and a contact route for unusual circumstances. Avoid an automated chatbot that confidently invents policy exceptions. Accessible assistance should be accurate, respectful and connected to the authoritative service owner.
What the user should be able to do: a visitor can request clarification without a public disclosure of health details or restarting the task.
Back to chapters · Next chapter
17. Support more than one way to understand a complex idea
Some users benefit from a short summary, others from a flowchart, audio, symbols or an example. Alternative forms should preserve material meaning rather than simplify away important conditions. A visual diagram cannot be the only route when another user needs structured text.
For the fictional voucher, a short explanation could be paired with an optional step-by-step illustration and a text list of the same eligibility decisions. W3C’s Content Usable note encourages multiple, appropriately designed ways to present key concepts. These are supplemental patterns rather than automatic WCAG conformance obligations. A qualified subject reviewer should confirm that every alternative describes the real programme.
What the user should be able to do: people using text, visual and assistive routes can identify the same required eligibility conditions.
Back to chapters · Next chapter
18. Treat numbers and choices as practical decisions, not puzzles
Rates, fees, eligibility limits and multiple options can impose mental arithmetic and comparison burdens. When possible, present a direct calculation with a plain explanation of what is included and which facts may change. Avoid forcing applicants to infer a cost from several unrelated percentages scattered across pages.
Daylight could show the advertised course fee, stated voucher amount if applicable and a clear indication of what the applicant would still owe, subject to verified rules. A calculator should show inputs and assumptions and let users correct them. The service must not invent eligibility or imply a personalised entitlement without sufficient data. Make arithmetic transparent rather than turning important decisions into an unlabelled puzzle.
What the user should be able to do: a user can compare two supported course options and explain the material price difference without redoing hidden calculations.
Back to chapters · Next chapter
19. Use respectful language without diagnosing interface users
People with cognitive or learning differences are not a single group, and many do not have a formal diagnosis or may choose not to disclose one. Testing should ask whether a service makes sense and supports a task, rather than rank an individual’s intelligence or describe an applicant as deficient.
W3C’s overview of cognitive and learning differences explains the diversity of needs, adaptive strategies and barriers. Recruit relevant user participants ethically, obtain consent and compensate appropriately. Ask where confusion arises and which information would help. A service should not require disability paperwork merely to show plain-language guidance that can improve usability for all.
What the user should be able to do: participants can share difficulties freely, and findings describe design problems without intrusive personal labels.
Back to chapters · Next chapter
20. Test with users and WCAG checks as complementary methods
Automated tests and expert WCAG review can reveal particular technical failures, while task-based user testing can identify confusing choices, unhelpful wording and memory demands that may not map neatly to a normative criterion. Neither method alone covers every need.
W3C’s Involving Users in Evaluating Web Accessibility recommends appropriate user participation alongside standards evaluation and warns against treating a small sample as representative of everyone. For Daylight, observe applicants completing realistic choices, not just answering whether they like the design. Record specific barriers, coping strategies and successful alternative routes, with participant privacy protected.
What the user should be able to do: the team can distinguish formal criterion failures from additional usability problems and can reproduce important blockers.
Back to chapters · Next chapter
21. Measure successful completion without manipulating people
Clicks, session duration and abandonment can suggest where a process needs investigation, but they cannot by themselves prove why a person left. A short session may mean the service was easy or the applicant gave up before starting. Success metrics need context and meaningful user outcomes.
Review successful task completion, corrected errors, time limits, support requests and comprehension of actual decisions. Avoid setting a commercial target that pressures people into selecting an unsuitable course or hides legitimate cancellation options. The service’s goal is informed agency, not maximum conversion regardless of consequences. Explain the limits of any study and avoid presenting a small group’s results as proof of universal access.
What the user should be able to do: improvements are judged by whether users can make accurate decisions and recover from mistakes, not by a single flattering conversion metric.
Back to chapters · Next chapter
22. Maintain cognitive access as the service changes
A portal may pass a well-run launch review and later introduce confusing navigation, a new countdown or a revised policy with harder language. Maintaining accessibility means assigning owners to content updates, shared components, help text and release testing.
Keep a source-to-interface map for critical decisions, revisit high-risk journeys after material changes and provide a route for users to report barriers. Train staff to write clear error explanations and recognise when a new legal condition needs better presentation. A technical regression suite cannot detect every linguistic misunderstanding; combine it with periodic, appropriately scoped task review. The goal is sustained independent use over time.
What the user should be able to do: new courses or eligibility changes do not silently erase the clear choices and recovery paths that previously worked.
Back to chapters · Next chapter
23. The gold standard is understandable, independent choice
Return to the fictional Daylight voucher. Users now receive a clear summary before detailed rules, step-by-step form guidance, a stable help option and a route to correct mistakes without re-entering unrelated information. Timers reflect real constraints instead of manufactured urgency, and the final message distinguishes submission from approval.
Cognitive accessibility services earn their gold standard when design helps people make informed decisions and maintain agency. The result is not childish language or a compulsory one-size-fits-all interface. It is respectful communication, predictable interaction, genuine choice and recoverable tasks, supported by standards and tested with people who actually need to use the service.
What the user should be able to do: applicants with differing reading, memory and attention needs can finish the same legitimate process while understanding what they agreed to.
Worked case: an eligibility journey that can finally be completed
Daylight is fictional. The table describes observable differences between a visually completed form and a service where applicants can make informed decisions.
| Application stage | Original difficulty | Meaningful remedy |
|---|---|---|
| Understand eligibility | Dense text and unexplained internal terms | Clear summary with correct full conditions available |
| Choose a course | Similar labels and hidden price conditions | Direct comparison with meaningful choices |
| Complete personal details | Repeated inputs and disappearing help | Reused data, stable guidance and supported formats |
| Correct an error | Red banner and lost work | Specific explanation and reversible correction |
| Submit and return | Generic success and uncertain status | Accurate receipt, next step and status distinction |
Deliverables matrix for a cognitive accessibility project
| Workstream | Accountable role | Acceptance evidence |
|---|---|---|
| Content and eligibility | Subject owner + plain-language editor | Users can accurately explain core conditions |
| Task and form design | UX + software product owner | Predictable, recoverable journey and saved work |
| Standards review | Qualified WCAG evaluator | Criteria evaluated within declared scope |
| User research | Ethical research lead | Observed decisions and barriers with caveats |
| Maintenance | Service manager | Changes reviewed and previous usability protected |
A practical cognitive accessibility checklist
- Describe audiences by tasks and needs without intrusive diagnosis assumptions.
- Identify important decisions and present plain-language summaries with full detail.
- Keep navigation, help, controls and terminology consistent.
- Make multi-step work resumable and avoid unnecessary repeated entry.
- Use real timeouts only when justified and handle errors reversibly.
- Provide accurate confirmation, status and legitimate human support.
- Apply WCAG requirements and supplemental COGA guidance without conflation.
- Observe meaningful user tasks and describe study limitations honestly.
- Retest after relevant policy, content or interface changes.
Frequently asked questions
The following answers clarify what services and formal standards can and cannot establish for cognitive accessibility.
1. Is cognitive accessibility just simplifying all text?
No. Clarity helps, but users also need predictable navigation, understandable labels, memory support, recoverable tasks, manageable timing and alternatives for important information. Some users need technical detail and should be able to reach it. Plain-language summaries must preserve real eligibility conditions and warnings. The aim is accurate independent choice, not removing complexity that matters to a person’s decision.
2. Does a WCAG 2.2 Level AA pass guarantee cognitive accessibility?
No. WCAG has criteria that help cognitive accessibility, including error support, redundant-entry limits, accessible authentication and predictable help. W3C also publishes supplemental COGA design patterns that are not required for WCAG conformance. A product can meet a defined technical target and still present unnecessary cognitive barriers. Report normative conformance and broader, user-tested usability separately.
3. What is the status of W3C Making Content Usable?
It is an informative Working Group Note with objectives, patterns and user research, not an additional normative WCAG standard. The patterns help product teams address needs that are not fully captured in testable WCAG 2.x success criteria. Apply them to practical tasks and test the result. Do not claim a product is W3C-certified because it follows selected cognitive patterns.
4. Is ISO 24495-1:2023 a digital accessibility certificate?
No. ISO 24495-1 provides plain-language principles for primarily textual information. It does not cover all forms of communication and explicitly leaves digital accessibility technical detail to other standards. It can improve readability of the voucher terms but cannot prove that the form’s keyboard, screen-reader, security or confirmation behaviour works. Use it together with appropriate WCAG evaluation and real task testing.
5. Can a long application be split into multiple steps?
Yes, when the steps have meaningful purposes and users can understand progress, review earlier entries and recover without unnecessary data loss. Splitting a form into dozens of tiny pages can create more memory burden rather than less. The correct design depends on the task, its real complexity and the audience. Explain what remains before asking the user to commit time or provide documents.
6. Does WCAG 2.2 prohibit asking users to repeat their data?
WCAG 2.2 Redundant Entry at Level A generally requires information already entered or supplied within the same process to be available for reuse, with exceptions such as essential re-entry, security and invalid prior information. It does not abolish all verification. Implementers should apply the criterion’s exact wording and protect personal data when auto-populating or retaining information.
7. Are countdown timers always inaccessible?
No. Some services legitimately have timed activities or session security constraints, with WCAG criteria and exceptions relevant to them. Artificial scarcity timers and unexpected timeouts can nevertheless exclude people. Explain genuine deadlines, support adjustment or warning where required, and avoid deleting completed work unnecessarily. A timer should reflect the service rather than pressure users into uninformed decisions.
8. Should users have to declare a learning disability to see help?
Generally that should not be the default for ordinary assistance. Clear explanations, examples and accessible controls can help many people without collecting a diagnosis. Specific accommodations or eligibility schemes may involve lawful processes, but those are different from hiding basic help behind sensitive disclosure. Design around tasks and user needs, maintain privacy and consult qualified advisers for actual legal obligations.
9. Can AI chatbots solve cognitive accessibility on their own?
They can sometimes clarify terms or guide navigation, but they may invent policy conditions, misinterpret personal situations or obscure the authoritative source. A chatbot should not be the only access route when accurate eligibility information exists in structured text. Keep a stable, human-understandable path, explain uncertainty and make escalation possible. Review AI assistance against the real programme and its current rules.
10. How should cognitive accessibility be tested?
Combine relevant WCAG technical checks with realistic tasks observed with a varied and consenting set of users, including those who experience memory, attention, reading or processing barriers. Ask what they think a control will do, whether they understand eligibility and how they recover from mistakes. A few users can reveal important problems but do not establish population-wide success.
11. What information belongs in a vendor handoff?
A responsible deliverable includes a user-task map, source content, design patterns adopted, relevant WCAG criteria, plain-language rules, error and recovery states, technical acceptance evidence, results from appropriate user testing and unresolved limitations. Identify who maintains the product when policies or forms change. A slogan claiming ‘simple for everyone’ cannot replace this evidence.
12. How is this different from Accessible Forms Design Services?
Accessible Forms Design focuses on constructing one usable form: labels, field types, validation, submission and recovery. Cognitive Accessibility Services is broader, including how people understand an entire product, compare choices, navigate information, manage time and remember decisions across workflows. They complement each other. A perfect form cannot compensate for a misleading eligibility explanation on the preceding page.
Primary standards and eduKate reading
- W3C Cognitive Accessibility Overview
- W3C Content Usable Working Group Note
- W3C Supplemental Guidance Index
- W3C Design Forms to Prevent Mistakes
- W3C Make Errors Easy to Undo
- WCAG 2.2 success criteria
- WCAG 2.2 Redundant Entry
- ISO 24495-1:2023 Plain Language
- W3C Involving Users in Evaluation
- eduKate — Accessible Forms Design Services
- eduKate — Digital Accessibility Testing Services
- eduKate — Plain Language Editing Services
- Gold Standard Sectors & Services Directory
Standards note, October 2026: W3C COGA Content Usable is supplemental guidance beyond normative WCAG 2.2 criteria. ISO 24495-1:2023 provides plain-language principles and does not certify a complete digital product. Real legal, privacy and accessibility duties differ by service and jurisdiction. This article provides design and evaluation guidance, not a clinical assessment or a claim that one interface meets every person’s needs.