Accessibility Guide for Project Managers (PM)

Accessibility Guide for Project Managers (PM): Managing Risk and Budget

For a Project Manager (PM) or Scrum Master, digital accessibility is often viewed as a "threat" to the three main pillars of project management: Budget, Time, and Scope.

In reality, accessibility only becomes expensive and slows down a project when it is treated reactively—that is, when an audit is conducted two weeks before the launch date. Based on insights from Web Accessibility: WCAG 2.2 made easy by Olga Revilla (Section: Implementing Web Accessibility Policies), this article breaks down how a PM should orchestrate accessibility from day one.

Related Insight

IT Procurement and VPAT Documents

1. Preventing Cost Escalation with Shift-Left

The golden rule in software risk management is: The cost of fixing a bug increases exponentially as time goes on.

Design Phase (Cost: $10): A UI/UX designer fixes a button's color contrast ratio from 3.0:1 to 4.5:1 in Figma. It takes 2 minutes.
Development Phase (Cost: $100): A developer realizes the color is non-compliant, has to consult the designer, rewrite CSS variables, and rebuild the component. It takes 2 hours.
Post-Release Phase (Cost: $10,000+): The product is audited by a third party, and global contrast failures are found. The team must halt new feature development, overhaul the main Design System, retest hundreds of pages, and potentially face legal lawsuits (such as EAA or ADA compliance).

As a PM, your job is to ensure validation happens in the Design Phase. You are the gatekeeper who refuses to let a design enter the Sprint Backlog if its accessibility hasn't been validated.

2. Structuring Accessible Acceptance Criteria (AC)

A User Story in Jira or Trello should never be considered "Done" if it does not meet inclusion standards.

Instead of creating one giant ticket named "Make the Website Accessible" (which is impossible to complete in a single Sprint), a PM must break it down into Acceptance Criteria for each individual ticket.

Example User Story: Login Modal Feature

As a user, I want to be able to log into my account via a popup modal.

Standard Acceptance Criteria:

Related Insight

Building an Accessible Design System

UI matches the Figma design.
Connects to the authentication API.

Accessibility-Enhanced Acceptance Criteria:

When the modal opens, keyboard focus moves directly to the "Email" input.
Keyboard focus is trapped inside the modal and cannot "leak" to the background page while the modal is open.
The modal can be closed by pressing the Escape key.
The 'X' (Close) button has an aria-label="Close login window".

3. Time Allocation and Sprint Velocity

PMs often ask: "How much extra time (Story Points) should I add for accessibility?"

Olga Revilla emphasizes that during the first few months (the transition period), your team's velocity will inevitably drop by about 15-20%. Developers need time to read WAI-ARIA documentation, and designers need time to check contrast. The PM must absorb this drop gracefully and communicate it to Stakeholders as an "Investment in Learning."

However, after 3 to 4 Sprints, when the team starts building Reusable Accessible Components, velocity will return to normal. Re-using a compliant <AccessibleButton> component repeatedly requires zero extra time.

4. When to Use External Auditors?

As a PM, you must be realistic about your team's capacity. Internal automated tools (like Lighthouse or Axe) only catch 20-30% of errors. The rest requires manual testing by experts.

Budget to hire Third-Party Accessibility Consultants at these crucial touchpoints:

Initial Design/Wireframe Audit: Before a single line of code is written.
Core Component Audit: When the Design System or main UI framework is completed.
Pre-Launch Audit: To issue official compliance certificates or a VPAT.

5. Conclusion

Accessibility project management is not about becoming an HTML expert or mastering legal regulations. It is about integrating quality checklists into daily work routines (Agile/Scrum), protecting developers' time to learn, and setting the standard that "Done" truly means "Usable by everyone".

References

The risk management strategies, the Shift-Left concept, and the integration of accessibility into Agile methodologies are adapted from the Implementing Web Accessibility Policies chapter in the literature Web Accessibility: WCAG 2.2 made easy by Olga Revilla. The specific structuring of Acceptance Criteria refers to managerial industry standards emphasized within that book.