Review documentation for accessibility and plain-language clarity

[needsofmany]

Goal

Review PluralBridge documentation for accessibility, readability, and plain-language clarity.

This Issue is intended for contributors who can help improve documentation without needing access to private Simply Plural exports or real user data.

Why this matters

PluralBridge is preservation-first, and many users may arrive under time pressure while trying to save important data.

Documentation should be readable by technical contributors, regular users, and people who may be anxious, tired, or unfamiliar with command-line tools.

Suggested scope

Review public documentation and website pages for issues such as:

• unclear wording
• overly technical explanations
• missing next steps
• confusing page flow
• accessibility concerns
• inconsistent terminology
• places where privacy warnings should be clearer
• places where users may not know what to do next

Useful areas to review may include:

• README.md
• START_HERE.md
• docs/
• website/start-here.html
• website/help-me-export.html
• website/export-now.html
• website/install.html
• website/run.html
• website/safety.html

Safety requirements

Do not request private exports.

Do not request API tokens.

Do not request screenshots containing private System data.

Do not ask users to post real notes, messages, avatars, member data, friend data, fronting history, logs, or database files.

Use synthetic examples or general descriptions only.

Suggested review questions

• Can a regular user tell where to start?
• Can a user tell what PluralBridge does and does not do?
• Can a user tell what files/folders they should save?
• Can a user tell what they should not share publicly?
• Can a developer find the contributor workflow?
• Are warnings clear without being frightening?
• Are links and headings easy to scan?
• Does the page flow make sense on desktop and mobile?

Possible follow-up work

Later Issues can split specific documentation edits into smaller tasks, such as:

• improve Start Here
• improve Help Me Export
• improve Safety
• improve Install
• improve Run
• improve README contributor path
• improve mobile readability

Acceptance criteria

• Review notes identify concrete documentation or accessibility improvements.
• Suggested changes preserve the privacy boundary.
• Any examples use synthetic data only.
• Follow-up edits are scoped into specific changes or PRs.