Inclusive Participation

Participation is part of the design process #

Plan collaboration while choosing the problem, priorities and interaction model, rather than inviting people only to approve a finished screen. Participants can shape which task matters, whether the vocabulary is understandable, how a recovery path works and what the team should build next.

Material’s Building for all reference covers user needs and co-design. W3C WAI describes involving people with disabilities throughout development alongside technical evaluation. This page applies those ideas to MobTranslate’s task, evidence and language boundaries. It supplies a process and an unexecuted example plan; it does not claim that a study or community review has happened.

Consider people and contexts without turning them into labels #

These dimensions are prompts for collaboration, not mandatory demographic fields or a complete classification of people. Ask what support and context matter for the task. Do not infer a sensitive attribute from a name, device or observed behavior. Overlapping circumstances and individual preferences can matter more than a broad category.

Agree the task, decision power and evidence #

Before collaboration, say which decisions can change, who owns them and how feedback will be answered. If the team cannot change a constraint, state that openly and explore alternatives. Close the loop with what changed, what did not and why; do not turn participation into a ceremonial endorsement.

Who is excluded and what can change #

Before recruiting, ask who else could benefit, which needs the current task misses and how people who are often overlooked can participate throughout development. Say which feedback can change priorities, behavior and messaging; keep asking these questions after the initial idea or launch.

Describe harms as concrete task failures: losing entered work, being unable to inspect a source, mistaking a machine draft for an attested entry, or interpreting a selected setting as publication permission. Assign a repair owner and define what observation would show improvement.

When a tool uses models, investigate bias in source coverage, evaluation examples, refusals, ranking and confidence presentation. Technical metrics and a polished explanation cannot authorize language publication or represent everyone’s experience. Keep qualified language review, consent and product usability as distinct decisions.

Make participation itself accessible #

• Ask for preferred communication, interaction setup, format, location and support. Do not require people to disclose a diagnosis to request an adjustment.
• Offer accessible written material in advance, readable consent information, captions/transcripts where appropriate, and enough time for the person’s chosen method.
• Agree breaks, stopping and compensation or practical support before asking someone to spend time. Do not invent a funded recruitment commitment in an unfunded plan.
• Provide a remote/asynchronous alternative when useful; verify that the chosen meeting, document or prototype tool actually works with the participant’s setup.
• A participant may use a support person or decline recording. Adapt the method instead of treating that choice as failed participation.
• Use public interface fixtures or agreed non-sensitive material. Source recordings, identifying account data and cultural material need their own retention and access decisions.

Run an observable task instead of asking for approval #

Use a concrete goal such as finding a record, explaining its source/review status, changing a draft and recovering from an invalid replacement. Start from a known build and state. Let the participant use their preferred setup; ask neutral follow-up questions when an action or interpretation is unclear.

Record the action and result separately from a hypothesis about the cause. A failure can involve content, code, browser, assistive technology, setup or the general task model. Preserve uncertainty and investigate the boundary that would decide between explanations. Combine these observations with technical checks rather than turning either one into a universal accessibility claim.

Plan and report with a bounded scope #

This copyable template is an unexecuted plan for English interface fixtures. Replace its placeholders with agreed details before real participation. It deliberately records permission states rather than fabricating approval, a participant identity or a study result.

• A report names the build, tasks, methods, relevant setup, findings and limits. Keep permitted participant explanations distinguishable from team interpretation.
• One person’s successful task or workaround cannot establish usability for everyone using similar technology. Retain contradictory observations instead of averaging away a barrier.
• Do not publish identifying notes, quotes, screenshots or recordings merely because they were used during a private session.
• A simulated review or automated pass in this styleguide does not establish language authority, cultural permission or actual participant involvement.

{
  "status": "unexecuted plan template",
  "task": "Find a public fixture record, inspect its source link and recover from a failed replacement",
  "productBoundary": "public English interface fixtures; no qualified language or publication decision",
  "participantChoice": "Preferred participation format, support person, breaks and stopping are agreed before a session",
  "methods": [
    "accessible task walkthrough",
    "participant-chosen interaction setup",
    "technical accessibility checks"
  ],
  "evidenceFields": [
    "build and route",
    "task and starting state",
    "participant-chosen setup without identifying details",
    "observed action",
    "observed result",
    "participant explanation in permitted form",
    "barrier hypothesis",
    "repair owner",
    "verification and remaining scope"
  ],
  "permissions": {
    "participation": "not obtained",
    "recording": "not requested",
    "publicQuote": "not requested",
    "languagePublication": "not established"
  },
  "outputs": "Private, agreed notes and bounded repair evidence; public reports contain only permitted, non-identifying material"
}

Prioritize barriers and close the loop #

Prioritize whether a barrier prevents task completion, creates harm or loses work, how often the triggering condition occurs, and whether a reliable alternative exists. Record an owner and a verification condition. Avoid relying on a vote count when an overlooked interaction setup reveals a task-blocking problem.

Return an accessible summary to participants under the agreed arrangements. Explain repairs and remaining constraints, and arrange follow-up for the decisions that need it. A revision of the UI requires its own relevant verification; an earlier observation is not a blanket approval for later changes.

Failures to avoid #

• Do not simulate a disability and present that as the experience of people who use the relevant interaction setup.
• Do not recruit only people who can navigate the prototype’s existing barriers.
• Do not ask a participant to validate a language or cultural claim outside their established remit.
• Do not ask for sensitive personal data simply to fill this dimension table.
• Do not claim that a few observations establish population-wide performance or formal standards conformance.
• Do not count a meeting, a copied plan or an automated test as proof that the real task outcome was achieved.

Verification and handoff #

• Check that the task, changeable decisions, support, stopping, permissions and practical arrangements are understandable in the chosen format.
• Fix obvious technical barriers before sessions, then combine actual observations with standards-based checks.
• Verify the repair in the relevant browser, assistive-technology and content context, with actual returned/persisted outcomes where required.
• Retain source and review provenance separately from usability findings.
• Confirm that the report and any shared material respect the agreed scope, and preserve open findings for the next revision.

Related guidance #