Role-based access for an accessibility team means assigning each person the right level of permission based on what they actually do. Auditors record issues. Developers fix them. Project managers oversee progress. Leadership reviews reports. The Accessibility Tracker Platform supports these distinctions so the right people see the right data without stepping on each other's work.
A well-configured access structure reduces confusion, protects audit integrity, and keeps remediation moving. The setup itself takes minutes once you map roles to responsibilities.
| Role | Typical Permissions |
|---|---|
| Account Owner | Full access across all projects, billing, and user management |
| Project Manager | Project-level access, assign issues, generate reports, invite team members |
| Auditor | Create and edit issues, upload audit data, mark issues for validation |
| Developer | View assigned issues, update remediation status, leave comments |
| Viewer | Read-only access to project data, reports, and dashboards |
Why Role-Based Access Matters for Accessibility Work
Accessibility projects involve people with different skill sets working on the same dataset. An auditor records WCAG 2.1 AA issues. A developer reads those issues and writes code fixes. A project manager tracks progress. Leadership wants a report.
Without defined roles, everyone has the same view, the same edit rights, and the same risk of accidentally overwriting audit data. Role-based access fixes this by mapping permissions to responsibilities.
It also protects audit integrity. The auditor's findings are the source of truth for conformance. If a developer can edit an issue record before fixing it, the audit trail becomes unreliable.
What Roles Should an Accessibility Team Include?
Most teams running an accessibility project use five core roles. The names can vary, but the responsibilities are consistent.
Account Owner. Usually the person who set up the workspace. Manages billing, controls user invitations across the account, and has access to every project.
Project Manager. Owns a specific project. Invites team members, assigns issues, monitors remediation progress, and pulls reports for leadership.
Auditor. Conducts the WCAG evaluation or uploads audit findings from an external provider. Responsible for the accuracy of issue records.
Developer. Receives assigned issues, applies code fixes, and marks issues ready for validation. Does not edit the original issue description.
Viewer. A read-only role for decision-makers, legal counsel, or external reviewers who need visibility without edit rights.
How to Map Permissions to Each Role
Permissions should follow the principle of least privilege. Give each person the minimum access they need to do their work.
Auditors need to create and edit issues. They do not need billing access. Developers need to update status and add comments. They do not need to create or delete issue records. Project managers need to assign work and invite users within their project, but not necessarily across the full account.
Viewers get a read-only seat. This is useful for in-house counsel reviewing remediation evidence, or for a client reviewing progress on a project run by an outside consultant.
Setting Up Roles Inside the Platform
Inside Accessibility Tracker, role assignment happens at the project level. The Account Owner or Project Manager invites a team member by email, selects the role, and the invitee receives access scoped to that project only.
A developer invited to one project does not automatically see other projects in the workspace. This matters for consulting firms managing multiple clients or in-house teams running parallel projects for different product lines.
Roles can be changed at any time. If an auditor transitions into a project management role, the Account Owner updates the permission level without removing the user.
How Role-Based Access Supports VPAT and ACR Work
When a project includes ACR generation, role separation becomes more important. The auditor's findings feed directly into the conformance report. If a developer or marketing team member can modify issue records, the resulting ACR may not reflect what was actually evaluated.
Keeping issue creation and editing scoped to auditors preserves the chain of evidence. Developers update remediation status, which the auditor then validates. The ACR reflects validated issues, not edited ones.
This separation also supports procurement reviews. Buyers reviewing an ACR want confidence that the document reflects an independent evaluation. A clear access log demonstrates that auditor findings were not altered by the team responsible for fixing them.
Common Mistakes to Avoid
Giving everyone admin access defeats the purpose of role-based access. It is faster on day one and harder to recover from later.
Mixing client and internal access in the same project. If you run consulting work, separate workspaces for separate clients prevents accidental cross-visibility.
Leaving former team members with active access. Review the user list quarterly and revoke access for anyone who has left the team or rotated off the project.
Frequently Asked Questions
Can a single user have different roles on different projects?
Yes. A user can be a Project Manager on one project and a Viewer on another. Roles are assigned per project, not per account, which gives teams flexibility when people work across multiple workstreams.
What is the right role for an outside accessibility consultant?
An external auditor or consulting partner is typically assigned the Auditor role on the specific project they are working on. This gives them issue creation rights without exposing other projects or account-level settings.
How does role-based access affect reporting?
Reports pull data from the project regardless of who recorded it, but the access log shows who created or modified each record. This is useful when leadership wants to verify that audit findings came from a qualified auditor rather than an internal team member without accessibility credentials.
Should developers be able to close issues?
The recommended workflow has developers mark issues as ready for validation rather than closing them outright. An auditor or project manager then verifies the fix and closes the issue. This preserves the validation step that supports conformance claims.
Role-based access is not about restricting your team. It is about giving each person the right view of the work so the project moves cleanly from audit to remediation to validation.
Set up your accessibility team inside Accessibility Tracker. Contact the Accessibility Tracker team to get started.