ometere123/the-skills-bible/accessibility-inclusive-design-specialist

Accessibility and Inclusive Design Specialist

Purpose

Design experiences usable across visual, auditory, motor, cognitive, speech, situational, and technological differences.

Use this skill when

• Accessibility must shape early design decisions.
• A product serves broad or vulnerable populations.
• Interaction, content, motion, colour, and layout need inclusive review.

Do not use this skill as the primary workflow when

• The task is code-level accessibility testing only.
• Accessibility is being requested as a final compliance checkbox.
• Qualified user research is required but unavailable.

Required inputs

• Product purpose, audience, domain, constraints, and success measures.
• Available research, personas, jobs, journeys, analytics, support findings, and product decisions.
• Current information architecture, flows, screens, content, prototypes, and implementation.
• Brand assets, visual references, prohibited patterns, and desired product character.
• Platforms, devices, input methods, viewport contexts, languages, and accessibility needs.
• Data shapes, permissions, roles, system states, latency, errors, and operational constraints.
• Design-system, component, engineering, delivery, and release constraints.
• Specific focus inputs for: inclusive-use contexts, perception, keyboard and switch operation, focus and sequence, touch target and motor access, content and cognition, motion and vestibular safety, assistive-technology semantics, alternative formats, inclusive validation.

Classify missing information as blocking, important, or optional. Inspect available product evidence and the implemented experience before requesting information that can be verified directly.

Core operating principles

• Start with the product's purpose, users, context, and emotional promise before selecting visual conventions.
• Translate research and product strategy into observable behaviours, flows, hierarchy, states, and design decisions.
• Create a visual thesis for each product instead of defaulting to familiar dashboard, card-grid, gradient, or component-library patterns.
• Use hierarchy, composition, typography, colour, imagery, spacing, and motion as one coherent communication system.
• Design the complete experience, including onboarding, loading, empty, error, permission, offline, success, and recovery states.
• Preserve accessibility, localisation, privacy, trust, and safety from the first concept rather than adding them after visual approval.
• Treat responsive design as intentional re-composition across contexts, not merely shrinking desktop layouts.
• Use prototypes and usability evidence to validate interaction and comprehension before implementation hardens assumptions.
• Make design decisions traceable through principles, specifications, examples, tokens, states, and acceptance criteria.
• Judge distinctiveness by whether the interface expresses this product's domain and purpose without sacrificing usability.

Workflow

1. Inclusive-Use Contexts

• Define the objective, user consequence, inputs, constraints, and evidence for inclusive-use contexts.
• Inspect current research, flows, screens, content, components, analytics, support evidence, and implementation before proposing change.
• Produce at least two materially different options when the decision affects product identity or workflow structure.
• Record the chosen direction, rejected alternatives, rationale, risks, responsive behaviour, accessibility implications, and validation method.

2. Perception

• Define the objective, user consequence, inputs, constraints, and evidence for perception.
• Inspect current research, flows, screens, content, components, analytics, support evidence, and implementation before proposing change.
• Produce at least two materially different options when the decision affects product identity or workflow structure.
• Record the chosen direction, rejected alternatives, rationale, risks, responsive behaviour, accessibility implications, and validation method.

3. Keyboard And Switch Operation

• Define the objective, user consequence, inputs, constraints, and evidence for keyboard and switch operation.
• Inspect current research, flows, screens, content, components, analytics, support evidence, and implementation before proposing change.
• Produce at least two materially different options when the decision affects product identity or workflow structure.
• Record the chosen direction, rejected alternatives, rationale, risks, responsive behaviour, accessibility implications, and validation method.

4. Focus And Sequence

• Define the objective, user consequence, inputs, constraints, and evidence for focus and sequence.
• Inspect current research, flows, screens, content, components, analytics, support evidence, and implementation before proposing change.
• Produce at least two materially different options when the decision affects product identity or workflow structure.
• Record the chosen direction, rejected alternatives, rationale, risks, responsive behaviour, accessibility implications, and validation method.

5. Touch Target And Motor Access

• Define the objective, user consequence, inputs, constraints, and evidence for touch target and motor access.
• Inspect current research, flows, screens, content, components, analytics, support evidence, and implementation before proposing change.
• Produce at least two materially different options when the decision affects product identity or workflow structure.
• Record the chosen direction, rejected alternatives, rationale, risks, responsive behaviour, accessibility implications, and validation method.

6. Content And Cognition

• Define the objective, user consequence, inputs, constraints, and evidence for content and cognition.
• Inspect current research, flows, screens, content, components, analytics, support evidence, and implementation before proposing change.
• Produce at least two materially different options when the decision affects product identity or workflow structure.
• Record the chosen direction, rejected alternatives, rationale, risks, responsive behaviour, accessibility implications, and validation method.

7. Motion And Vestibular Safety

• Define the objective, user consequence, inputs, constraints, and evidence for motion and vestibular safety.
• Inspect current research, flows, screens, content, components, analytics, support evidence, and implementation before proposing change.
• Produce at least two materially different options when the decision affects product identity or workflow structure.
• Record the chosen direction, rejected alternatives, rationale, risks, responsive behaviour, accessibility implications, and validation method.

8. Assistive-Technology Semantics

• Define the objective, user consequence, inputs, constraints, and evidence for assistive-technology semantics.
• Inspect current research, flows, screens, content, components, analytics, support evidence, and implementation before proposing change.
• Produce at least two materially different options when the decision affects product identity or workflow structure.
• Record the chosen direction, rejected alternatives, rationale, risks, responsive behaviour, accessibility implications, and validation method.

9. Alternative Formats

• Define the objective, user consequence, inputs, constraints, and evidence for alternative formats.
• Inspect current research, flows, screens, content, components, analytics, support evidence, and implementation before proposing change.
• Produce at least two materially different options when the decision affects product identity or workflow structure.
• Record the chosen direction, rejected alternatives, rationale, risks, responsive behaviour, accessibility implications, and validation method.

10. Inclusive Validation

• Define the objective, user consequence, inputs, constraints, and evidence for inclusive validation.
• Inspect current research, flows, screens, content, components, analytics, support evidence, and implementation before proposing change.
• Produce at least two materially different options when the decision affects product identity or workflow structure.
• Record the chosen direction, rejected alternatives, rationale, risks, responsive behaviour, accessibility implications, and validation method.

Decision rules

Required outputs

• Inclusive-Use Contexts artefact with rationale, variants, responsive behaviour, and acceptance criteria.
• Perception artefact with rationale, variants, responsive behaviour, and acceptance criteria.
• Keyboard And Switch Operation artefact with rationale, variants, responsive behaviour, and acceptance criteria.
• Focus And Sequence artefact with rationale, variants, responsive behaviour, and acceptance criteria.
• Touch Target And Motor Access artefact with rationale, variants, responsive behaviour, and acceptance criteria.
• Content And Cognition artefact with rationale, variants, responsive behaviour, and acceptance criteria.
• Motion And Vestibular Safety artefact with rationale, variants, responsive behaviour, and acceptance criteria.
• Assistive-Technology Semantics artefact with rationale, variants, responsive behaviour, and acceptance criteria.
• Alternative Formats artefact with rationale, variants, responsive behaviour, and acceptance criteria.
• Inclusive Validation artefact with rationale, variants, responsive behaviour, and acceptance criteria.

Product-design quality gates

• Purpose gate: The interface expresses a specific product promise, audience, domain, and desired user feeling.
• Research gate: Important design decisions are grounded in evidence, explicit assumptions, or planned validation.
• Structure gate: Information architecture, navigation, flows, hierarchy, and state transitions are coherent.
• Distinctiveness gate: The result cannot be mistaken easily for an unrelated generic SaaS, Web3, AI, or admin template.
• Consistency gate: Typography, colour, spacing, shape, imagery, iconography, and interaction follow a coherent visual language.
• State gate: Loading, empty, error, success, permission, offline, partial, and recovery states are designed.
• Accessibility gate: Perception, operation, comprehension, motion, input, and assistive-technology needs are addressed.
• Responsive gate: Each important context has deliberate composition, density, navigation, and interaction behaviour.
• Trust gate: Consequential actions, data use, consent, security, status, uncertainty, and reversibility are communicated honestly.
• Delivery gate: Specifications, prototypes, assets, tokens, acceptance criteria, and design QA support faithful implementation.

Evidence standard

For consequential design conclusions, identify the exact product version, target users, task, platform, viewport or device, language, data state, permission state, research source, prototype version, design-system version, and implementation reviewed. Distinguish observed user evidence, analytics, accessibility findings, stakeholder requirements, design judgement, and untested assumption. Do not present aesthetic preference as user evidence.