Skip to main content

Decide what a Reader can edit, create and reach in a workspace.

Goal

Let a read-only member contribute to specific work, without giving them the run of the whole workspace.

When to use this instead of changing their role

A Reader reads everything and changes nothing. An Editor changes everything. Most collaborations sit between the two: a freelancer working on one audit, a developer who maintains the accessibility plan, a client who reviews and comments.

Granting rights piece by piece keeps the rest of the workspace read-only for them, which is usually what you actually meant.

Preconditions

  • You are an Owner or a Moderator of the workspace.
  • The person is an active Reader in it. These settings do not apply to Editors, Moderators or Owners: their role already grants everything.

Steps

  1. Open the workspace Members settings.
  2. Find the person, open their row menu, and choose Manage access.
  3. Audits they can edit - tick the audits this person may change. Every audit is readable already, so ticking one adds editing, not visibility.
  4. Create audits - off by default. Turn it on and they can start their own audits, which they then own and can edit. It does not let them edit anybody else's. Audits they create count against the workspace quota.
  5. Journeys - No access, Read, or Edit.
  6. Accessibility plans - No access, Read, or Edit.
  7. Click Save changes. Everything is saved together, in one step.

Verify success

  • Ask the person to reload. A granted audit now shows its editing controls; the others still show the read-only notice.
  • An area set to No access disappears from their navigation entirely, and its address returns nothing if they try it directly.

Effect on billing

On Enterprise, a Reader with no write right anywhere occupies no paid seat. The moment you grant them audit editing, the right to create audits, or Edit on journeys or plans, they take a seat. The Members list shows which people are paid and which are free, so the cost of a grant is visible before the invoice is. See product / plans and roles.

Common pitfalls

  • Granting to hide things. Grants add editing; they never restrict reading. To let somebody see one audit and nothing else, do not add them to the workspace at all: share that single audit with them instead.
  • Promoting to Editor for one audit. An Editor can change every audit in the workspace. Grant the one audit instead.
  • Forgetting the create right. A Reader who cannot create audits has no "New audit" button anywhere; the button reappears as soon as you turn it on.
  • Expecting a revoked grant to remove their own audits. Audits somebody created stay theirs. Withdrawing that is a matter of reassigning the audit, which happens when they are removed from the workspace or leave it.

Related

Last reviewed: 2026-09-05