Building a Culture of Accessibility in Organizations

Building an Accessibility Culture: A Systemic Approach

In many organizations, accessibility is often treated as an "afterthought"—a checklist box that the Quality Assurance (QA) team must tick a few weeks before product launch. This reactive approach not only incurs vastly higher remediation costs but almost always results in a fragile and less inclusive product.

Based on the literature Ensuring Digital Accessibility through Process and Policy by Jonathan Lazar (Chapter 4: A Systems Approach to Change), this article discusses the necessity of systemic transformation. To achieve long-term success, accessibility must shift from the realm of "code fixing" to the realm of "company culture".

---

1. A Systems Approach

Jonathan Lazar emphasizes that accessibility failures are rarely caused by a programmer's lack of technical ability. They are more often caused by systemic failures: lack of policies, inadequate budgets, absence of training, and unreasonable deadlines.

To change this, organizations must adopt a systemic approach that involves every department—from HR (Human Resources) and Procurement to Marketing and C-level Executives.

Core Elements of Systemic Change:

1. Formal Policy: There must be a written, approved, and published digital accessibility policy document stating the organization's commitment to WCAG 2.2 Level AA standards. 2. Procurement Process: Refusing to purchase third-party software that does not provide a valid VPAT (Voluntary Product Accessibility Template). 3. Continuous Training: Providing role-specific training (designers learn about contrast, developers learn about ARIA, content writers learn about Plain Language).

---

2. Shift-Left: Moving Accessibility to the Left

In traditional software development methodologies, testing sits at the far right of the timeline (at the end of the cycle). The Shift-Left concept means moving accessibility considerations to the beginning of the process—to the "left".

• Research Phase: Involving users with disabilities in early User Experience (UX) research.
• Design Phase: Ensuring Figma or Sketch designs include focus rings and annotations before being handed off to developers.
• Planning Phase (Sprints): Making accessibility a part of the Definition of Done (DoD). A feature cannot be considered "Done" if it cannot be operated with a keyboard.

Fixing a color contrast issue during the UI design phase takes 5 minutes. Fixing it after the application is released requires global variable changes, code regression, re-testing, and redeployment, costing dozens of times more.

---

3. Top-Down vs Bottom-Up

Who should drive this change? The answer is both.

The Bottom-Up Movement

Many accessibility initiatives are started by a developer or designer who cares deeply (an Accessibility Champion). They start using `alt` text, fixing heading hierarchies, and spreading awareness to their peers. However, without management support, this movement is highly vulnerable and can die if that Champion resigns.

Top-Down Support

For this culture to survive, there must be Buy-in (full support) from the Executive level (C-Suite). Executives hold the keys to: - Allocating dedicated budgets (for external audits or hiring specialists). - Setting accessibility Key Performance Indicators (KPIs) for all teams. - Providing legal shields and business mandates.

---

4. Building a Network of Accessibility Champions

Lazar suggests forming an Accessibility Task Force or a network of Champions—designated individuals from various departments (not just IT) responsible for ensuring their department complies with accessibility policies.

A Champion in HR, for example, ensures that job portals and internal company documents are accessible to blind employees. A Champion in Marketing ensures every promotional YouTube video has accurate Closed Captions.

---

5. Conclusion

Building a culture of accessibility is not an overnight project; it is a marathon of organizational change. When accessibility becomes part of the company's DNA, it is no longer viewed as a burden or a legal obligation, but as baseline quality.

A product that cannot be accessed by 15% of the global population (people with disabilities) is not a "finished" product—it is a defective product.

---

References

This article is composed by extracting the management frameworks and the Systems Approach to Change advocated by Jonathan Lazar in the book Ensuring Digital Accessibility through Process and Policy. The emphasis on Top-down collaboration and the formation of Accessibility Champions refers purely to the institutional strategies discussed within that literature.