Scaling Accessibility Knowledge Across Healthcare: CVS Health's Knowledge Base Evolution

Overview

CVS Health operates one of the largest healthcare ecosystems in the United States, with digital properties serving millions of customers across pharmacy, health services, and insurance platforms. As the company's accessibility practice matured, a critical challenge emerged: how do you ensure consistent accessibility implementation across dozens of product teams, each working on different healthcare touchpoints?

As a senior accessibility experience designer, I was tasked with creating a comprehensive internal knowledge base that would serve as the single source of truth for accessibility standards, guidelines, and best practices across the entire organization. The project involved evaluating different platforms and ultimately designing a content creation workflow that transformed how CVS Health approaches accessibility knowledge management.

The Challenge

CVS Health's digital ecosystem is complex—spanning consumer-facing pharmacy apps, provider portals, insurance platforms, and internal healthcare tools. Each product team had developed their own approaches to accessibility, resulting in:

• Fragmented Knowledge: Accessibility guidance was scattered across team wikis, email threads, and individual expertise
• Inconsistent Implementation: Similar features across different products had vastly different accessibility approaches
• Steep Learning Curves: New team members spent weeks hunting down accessibility requirements buried in various documentation systems
• Compliance Gaps: Without centralized standards, some teams inadvertently missed critical accessibility requirements for healthcare applications
• Scale Challenges: Healthcare regulations require meticulous documentation, but existing knowledge management systems couldn't handle the complexity

The stakes were high. Healthcare accessibility isn't just about compliance—it's about ensuring that people managing chronic conditions, disabilities, or health emergencies can access critical services when they need them most.

The Vision

The goal was ambitious: create a living knowledge base that would serve as the definitive resource for accessibility at CVS Health. This wasn't just about storing information—it needed to support the entire lifecycle of accessibility work, from initial design decisions to post-launch auditing.

The vision included:

• Comprehensive Coverage: Every aspect of accessibility work, from regulatory requirements to implementation patterns
• Searchable and Discoverable: Teams could quickly find exactly what they needed without navigating complex information architectures
• Living Documentation: Content that stayed current with evolving standards and internal practices
• Workflow Integration: Seamless connection to existing development and design processes
• Cross-Functional Accessibility: Resources for designers, developers, product managers, and QA teams

The Evolution: Finding the Right Platform

Phase 1: SharePoint Foundation

We started with SharePoint, leveraging CVS Health's existing enterprise infrastructure. The initial implementation focused on basic documentation storage and team collaboration features.

What Worked:

• Enterprise security and compliance features
• Familiar interface for many teams
• Robust permission management

What Didn't Work:

• Limited content organization capabilities
• Poor search functionality
• Clunky editing experience that discouraged content contributions

It quickly became clear that SharePoint's document-centric approach wasn't serving our needs. Teams struggled to find information, and the editing process was so cumbersome that subject matter experts stopped contributing content.

Phase 2: Confluence Expansion

The move to Confluence represented a shift toward wiki-style knowledge management. The platform's strength in collaborative editing and content organization seemed like a natural fit for accessibility documentation.

What Worked:

• Better content organization and navigation
• Collaborative editing features
• Improved search capabilities
• Easier linking between related topics

What Didn't Work:

• Still lacked workflow integration with development processes
• Version control was limited for complex content updates
• No easy way to maintain content accuracy across frequent regulatory updates

Confluence served us well, but as the accessibility program grew, we needed something more sophisticated that could integrate directly with how teams were already working.

Phase 3: GitLab Innovation

The transition to GitLab marked a fundamental shift in approach. Instead of treating the knowledge base as a traditional wiki, we reimagined it as a content creation system that could integrate directly with development workflows.

Why GitLab:

• Version control for documentation
• Integration with existing development processes
• Powerful native features for issue management and review workflows
• Markdown-based content creation that developers were already comfortable with

The GitLab Implementation

Content Architecture

Working with information architects and technical writers, I developed a modular content structure where each accessibility pattern, guideline, or requirement lived in its own markdown file. This allowed for:

• Atomic Updates: Changes to specific requirements didn't require updating entire documents
• Reusable Components: Common accessibility patterns could be referenced across multiple contexts
• Natural Cross-References: GitLab's linking features ensured that related content stayed connected and discoverable

Review and Validation Workflow

Every content update followed a structured review process using GitLab's native features:

1. Merge Request Creation: Contributors proposed changes through standard GitLab workflows
2. Subject Matter Expert Review: Accessibility specialists validated technical accuracy using GitLab's review tools
3. Editorial Review: Technical writers ensured clarity and consistency
4. Stakeholder Approval: Product leaders confirmed alignment with business requirements
5. Issue Integration: GitLab's issue tracking connected documentation updates to specific product needs

Workflow Integration

The breakthrough was leveraging GitLab's issue management and linking capabilities to connect the knowledge base directly to product development workflows. Teams could reference specific accessibility requirements directly in their GitLab issues, and the knowledge base would surface relevant guidance based on labels and project associations.

Content Management Through GitLab Features

By weaving together GitLab's native capabilities, we created a robust content management system:

• Version Control: Full history of all documentation changes with clear attribution
• Issue Generation: Teams could create issues directly from documentation gaps or questions
• Review Workflows: Built-in merge request process ensured content quality
• Project Integration: Documentation lived alongside code repositories for seamless reference

The Results

The GitLab-based knowledge base had immediate impact on how CVS Health approaches accessibility:

• Streamlined Design Workflows: Accessibility designers could now reference and update requirements within the same system used for product development
• Enhanced Design and Development Visibility: Both design and development teams gained clear windows into accessibility requirements and established patterns, reducing guesswork and implementation gaps
• Integrated Process: Teams began referencing accessibility guidance as part of their regular GitLab workflows rather than as separate documentation
• Consistent Implementation: Shared patterns and guidelines led to more uniform accessibility approaches across products
• Faster Decision Making: Product teams could quickly find and apply relevant accessibility requirements without hunting across multiple systems

Workflow Transformation

The most significant impact was on accessibility design workflows themselves. Instead of maintaining separate documentation that teams might reference occasionally, accessibility requirements became integrated into the tools and processes teams used daily. This integration meant that accessibility considerations became part of natural project planning rather than afterthoughts.

Design teams gained visibility into technical implementation details, while development teams could easily access design rationale behind accessibility requirements. This transparency improved collaboration and reduced the back-and-forth typically required to implement accessible features correctly.

Team Impact

The GitLab approach resonated particularly well with development teams who appreciated having accessibility documentation integrated into their existing workflows. Design teams noted improved visibility into implementation requirements, while product managers found it easier to reference specific accessibility guidance during project planning.

The integrated approach eliminated the common problem of accessibility documentation becoming outdated or disconnected from actual product development practices.

Final Thoughts

This project demonstrated that successful accessibility programs need more than just good intentions and compliance checklists—they need systems that make it easier to do the right thing than to take shortcuts.

The journey through different platforms taught us that knowledge management is most effective when it integrates with existing workflows rather than creating parallel processes. By treating accessibility knowledge as a living system that works within the tools teams already use, CVS Health built a foundation for more sustainable accessibility practices.

The GitLab approach proved that with thoughtful platform selection and workflow design, documentation can support teams instead of burdening them, making accessibility guidance a natural part of product development rather than an external requirement.