Setting up roles for a team inside accessibility platform software involves defining permission tiers, assigning users to those tiers, and connecting each user to the projects and tasks relevant to their work. Most platforms ship with preset role templates (admin, manager, contributor, viewer) that an account owner configures during initial setup, then refines as the team grows. The goal is to give each person the access required for their responsibilities without exposing settings or data they do not need.
| Element | What It Covers |
|---|---|
| Role Templates | Preset permission groups such as admin, manager, contributor, and viewer. |
| User Invitations | Email-based invites that connect a user to a role and one or more projects. |
| Project Assignment | Linking users to specific audits, products, or properties they will work on. |
| Permission Scope | What each role can view, edit, assign, or export within the platform. |
Start With the Account Owner
The first user on the account is the owner. This person holds full permissions across billing, integrations, project creation, and user management. Most accessibility platforms allow only one owner, though admins can be added to share top-level access without billing control.
Before inviting anyone else, the owner should map out the team. List who is conducting evaluations, who is fixing issues, who is reviewing progress, and who is reading reports. That list becomes the basis for role assignment.
Understand the Standard Role Tiers
Most accessibility platforms organize permissions into four tiers. The names vary, but the structure is consistent.
- Admin: Full access to settings, projects, users, and billing. Can create and delete projects, invite users, and configure integrations.
- Manager: Project-level oversight. Can assign issues, change status, generate reports, and add contributors to assigned projects.
- Contributor: Works on issues directly. Can view assigned projects, update issue status, add comments, and attach evidence of remediation.
- Viewer: Read-only access. Can see dashboards, audit reports, and progress data but cannot edit anything.
Invite Users and Assign Roles
Once roles are mapped, the owner or an admin enters the user management area of the platform and sends invitations by email. During invitation, the inviter selects a role from the dropdown and chooses which projects the user joins.
The invited user receives an email, sets a password, and lands inside the platform with access scoped to their assigned role. Most platforms allow role changes after the fact, so an initial assignment is not permanent.
Connecting Users to Projects
Role tier controls what a user can do. Project assignment controls where they can do it. A contributor assigned to one project sees only that project.
The same contributor added to a second project gains access to both. This separation lets a single platform serve agencies managing multiple clients or enterprises managing multiple products without exposing data across teams.
Match Roles to Real Work
Role assignment becomes useful when it reflects how the team actually operates. A developer fixing issues needs contributor access to update status and attach pull request links. A QA reviewer needs manager access to verify fixes and reassign issues that did not pass review. An executive reading monthly progress needs viewer access to dashboards.
Over-assigning permissions creates risk. A contributor with admin access can accidentally change settings or delete projects. Under-assigning creates friction. A viewer who needs to comment on issues will request access changes weekly.
Adjust as the Team Grows
Roles are not static. When a contractor finishes a project, downgrade them to viewer or remove them from the project entirely. When a contributor takes on review responsibilities, promote them to manager. Most platforms log role changes, so an audit trail exists for compliance documentation.
For organizations with strict access requirements, look for platforms that support custom roles. Custom roles let an admin define a permission set that does not match any preset, such as a contributor who can export reports but cannot edit issue status.
Document the Setup
After roles are assigned, write a short internal reference describing who has which role and why. Include the permission tier, the projects each user can access, and the date of last review. This document becomes part of the accessibility program record and helps onboard new team members without rebuilding the structure from memory.
Role configuration is one part of platform setup. Strong role design supports faster remediation, cleaner reporting, and a clearer line between who owns what across the program.