Overview

Accessibility became one of the most important long-term initiatives of my time at Follett.

From 2013 through 2025, I helped support a broad transformation in how accessibility was understood, discussed, documented, designed, and implemented across multiple Follett products.

The effort involved product design, development collaboration, WCAG interpretation, audits, component remediation, design reviews, documentation, training, stakeholder education, and persistent advocacy.

Starting Point

The starting point was challenging.

Follett had no formal accessibility standards in place, and implementation was inconsistent across products. Some areas had partial compliance, while other areas carried legacy technical debt or were shaped by limited accessibility awareness.

Accessibility was often treated as something to address later, after the product had already been designed or built. That meant accessibility issues frequently landed in the technical debt pile instead of being considered as part of the real-time design and development process.

The Cultural Challenge

The hardest part of the transformation was not simply identifying accessibility issues.

The hardest part was changing the culture around accessibility.

The organization needed to move from thinking of ADA and accessibility requirements as after-the-fact obligations to understanding them as part of responsible product development.

Legal risk and the possibility of litigation did create urgency, but the deeper motivation was always the community we served: students, educators, librarians, administrators, and school staff.

Scope Of The Effort

The accessibility effort affected multiple products across the Follett suite and extended into the design system itself.

The work touched at least six major products, six delivery teams, thousands of modules and pages, and hundreds of documented standards.

I was also involved in an advisory capacity for marketing sites, helping extend accessibility thinking beyond product interfaces into broader customer-facing experiences.

My Responsibilities

My role covered both practical execution and organizational advocacy.

• Accessibility audits
• Design reviews
• Component remediation guidance
• Documentation
• Training
• Accessibility advocacy
• Stakeholder education
• Design system standards
• WCAG interpretation
• Developer collaboration

The goal was to help teams understand accessibility requirements early enough to design and build with them, rather than trying to repair issues after implementation.

Design System Integration

One of the most important parts of the work was integrating accessibility into design system thinking.

Accessibility standards needed to show up in components, patterns, color contrast, typography, form behavior, focus states, keyboard navigation, error handling, and documentation.

By embedding accessibility guidance into reusable standards, we helped teams avoid repeating the same problems across multiple products.

Training & Advocacy

Accessibility progress required shared understanding.

All six delivery teams received accessibility training, and accessibility became a more regular part of design and development conversations.

Much of the advocacy work involved helping teams understand that accessibility was not merely a checklist or a legal requirement. It was part of building better educational products for real people with real needs.

Results

Over time, accessibility became more visible and more integrated into Follett’s product process.

• WCAG AA compliance awareness and implementation improved
• Accessibility became part of design reviews
• New standards were established and documented
• Thousands of modules and pages were reviewed or improved
• Six delivery teams received accessibility training
• Hundreds of accessibility-related standards were documented
• Organizational awareness increased across product, UX, development, QA, and leadership
• Accessibility shifted from reactive remediation toward proactive design consideration
• Accessibility became part of product planning conversations

The transformation was large, ongoing, and imperfect, but it represented meaningful cultural and operational progress.

Why It Matters

Accessibility matters because students matter.

It matters to the education community. It matters to students with disabilities. It matters to educators trying to serve all learners. And it matters to anyone responsible for building tools that should not exclude the people they are meant to support.

Education technology exists in a market that, at its best, puts students first. Bureaucracy can get in the way, but the empathy, intention, and motivation are clear.

Accessibility work is one of the clearest ways a product team can turn that intention into practice.

Reflection

I am proud of this work because it required more than technical knowledge.

It required persistence, education, collaboration, and the willingness to keep bringing accessibility back into the conversation until it became part of how teams worked.

The lesson was simple but important:

Accessibility is not a feature. It is a commitment to ensuring that every student has a fair opportunity to learn.