Designing an Internal Accessibility Knowledge Hub for Every Discipline
Client
Concentrix
Year
2026
Most accessibility resources cover the basics everyone can find on the internet. What does not exist is a resource built around the specific components, patterns, and client scenarios that different disciplines actually encounter in their own work, whether designing a component, building it, or writing about it. I identified that gap, proposed the solution to my manager and design lead, received approval from both, and built the Concentrix Accessibility Hub: an internal knowledge platform in Figma Sites intended from the start for every discipline globally, not just design, with written guidance, real client case studies, and interactive Figma Make prototypes.
Scope of Work

Context & Goals
Concentrix is a design consultancy working across many clients and sectors. None of them, healthcare or otherwise, had a shared internal resource for accessibility beyond what anyone could find on the internet. My own remediation work on an enterprise healthcare client gave me the depth of experience to build one, but the need for it existed company-wide, across every client and discipline. Generic resources teach the standard. They do not help someone apply it to the specific component, platform, or edge case in front of them. The goal was a platform anyone at Concentrix would actually open when they had a question rather than searching Google: specific and actionable content, intuitive IA, and a reading experience that made dense accessibility information approachable to non-specialists as well as designers.

Constraints
Loop and SharePoint, Microsoft's internal documentation and collaboration tools, were already approved for use company-wide, requiring no new approvals, but too limited: no visual flexibility and no Figma Make integration. Figma Sites was the only option that offered creative freedom and native Figma integration in one place, but it was in beta.

Process
Content research
Audited existing web accessibility resources before building anything. Most organize content around the standard, not around how a designer encounters a problem. The remediation work across six client platforms gave me direct knowledge of which scenarios and edge cases actually come up. Client-specific details were anonymized, but the value was showcasing real patterns from real remediation work rather than generic examples. That is the depth advantage no public resource can match.
Information architecture
The hub is organized around how someone actually encounters a problem, not around WCAG criteria. Foundations is the entry point. Knowledge Library goes deeper on specific topics, always leading with the user need before the criterion. Guidelines and Patterns is component-by-component guidance with real Do and Don't examples. Three sections marked coming soon: Tools and Resources, Learning and Enablement, and Community.
Interactive prototypes
Static text alone cannot explain interaction-based accessibility. Figma Make prototypes are embedded directly in articles covering color, buttons, links, and form inputs, with use cases and live examples readers can interact with rather than just read about
Key Design Decisions
Figma Sites over established internal tools
Loop and SharePoint would have been faster to launch and needed no new approvals, but both would have made the hub feel like an internal wiki. Figma Sites offered layout flexibility, visual design control, and native Figma Make integration. The instability risk of using a beta was real but manageable. The reader experience was worth it.
Human-first before WCAG
Most accessibility resources organize by criterion: 1.4.3 minimum contrast, 2.4.7 focus visible. The hub inverts this: article starts with the user, explains the design problem, shows it with an interactive prototype, then names the criterion. People learn through problems and examples, not through standards and numbering, whether they design the component, build it, or write the copy for it. Each article also cross-links to related articles, because accessibility concepts are interconnected and a reader looking into contrast should reach keyboard navigation in one click.
Coming soon as roadmap, not placeholder
Three sections launched as coming soon with clear descriptions rather than empty. An empty section signals incompleteness. A labeled section with intent signals a living platform, not a finished document.

Trade-Offs
Three months alongside existing project work meant tight content scope. Five articles and three active sections at launch was the right balance: useful from day one without launching something half-finished. Coming soon sections are honest about what is not there yet.
Figma Sites in beta meant accepting instability risk for a platform intended for teams across disciplines globally. Not an issue so far, but something to monitor as the hub grows.

Outcomes
Presented at the Concentrix Design All Hands: a live demo of Figma Sites and the embedded Figma Make prototypes to 40+ designers across the globe
Recognized at the Concentrix Argentinian Townhall in June 2026
Described by the team as clear, immediately useful, and polished enough to be a standalone product
A community of over 20 designers and managers from other client teams across Concentrix has formed around the hub since launch, participating in monthly syncs and engaging with new content.
Reflection
The most interesting challenge was not the design. It was the content. Building something people would actually use required making real decisions about what to include and what to leave out. Generic accessibility information is everywhere. The hub only earns its place if it contains things no one at Concentrix, regardless of discipline, can find elsewhere: specific components, specific client scenarios, specific judgment calls from real projects. That is the standard I held every article to, and it is the reason the feedback described it as feeling like a product rather than a document.


