ilisium
WorkspaceBring your agent
All project proposals

Open-source software

Access Repair

Help one consenting open-source team repair a specific user journey that people cannot currently complete accessibly.

What the team would deliver.

A reviewable patch for one user journey, regression checks, and a before-and-after usability report.

Make one agreed journey usable with the relevant keyboard and assistive-technology setup, and give maintainers evidence they can review.

A bounded path to that result.

Suggested work packets for an initial team to scope and review together.

  1. Agree on one journey

    Find a willing maintainer and choose a bounded interaction such as completing a form or navigating a dialog.

    Output An agreed scope with expected behavior and review ownership.

  2. Record the barriers

    Reproduce failures with the relevant input and assistive technology, then separate causes from symptoms.

    Output A prioritized issue list with repeatable steps.

  3. Repair and check

    Implement small reviewed changes and add regression coverage where it meaningfully protects the interaction.

    Output A focused patch and a repeatable check set.

  4. Validate with people

    Repeat the journey, gather consented observations, and hand the evidence to the maintainer.

    Output A before-and-after report and an explicit maintainer review decision.

Different strengths. Shared work.

People

Maintainer
Approve scope, review the implementation, and decide whether to integrate the patch.
Accessibility reviewer
Define the relevant interaction checks and assess the repair using assistive technology.
User tester
Where available, test the journey from lived experience and consent to how observations are recorded.

Their AIs

Audit assistant
Map the journey, collect reproducible failures, and identify likely semantic or interaction causes.
Repair assistant
Draft focused code changes and meaningful regression checks for human review.
Evidence assistant
Organize before-and-after checks and flag cases still requiring manual evaluation.

These are proposed responsibilities. People choose their tools, review contributions, and authorize changes; this page does not connect or run an AI.

What would count as done.

  • The app's maintainers agree to the target journey and contribution scope before the team starts work.
  • The original barriers are reproduced with documented devices, browser, and assistive-technology versions.
  • A reviewer can complete the agreed journey after the repair and verify that the reported barriers are resolved.
  • Maintainers review the patch and the evidence; automated scan results alone do not establish accessibility.

What the record would contain.

  • Maintainer-approved scope and reproducible descriptions of the original barriers.
  • A source revision and patch, with checks tied to the affected interaction.
  • Keyboard and assistive-technology test notes with environment details.
  • A human review that states what improved, what remains untested, and what still fails.

Help shape the brief.

Explain what you would contribute, what needs to change, or what would make this outcome useful. Scope and participation would be agreed before work begins.

Discuss Access Repair

Opens your mail app. Sending an email does not enroll you or reserve an assignment.