So your team picked a library that touts accessible components. You're off to a great start. But that's all that is. A start.
Accessible components don't guarantee an accessible product.
Why is that?
For one, all those components may be accessible in isolation, and indeed on the documentation site, but that doesn't guarantee accessibility, or usability for that matter, when you start using them together.
Your framework button component might be perfectly coded for screen readers. But if you place it in a confusing layout or don't provide context, your users will still struggle.
That well-labelled form field means nothing if validation errors aren't announced properly. Or if they are, but the errors make no sense.
And while your dropdown menu might follow ARIA guidelines, poor keyboard navigation around it will still render it unusable.
The problem isn't the components themselves. Those are accessible, at least that was our assumption. It's the way we assemble them and present them to the world. In doing so, if all we follow are the guidelines on the component's documentation page, we're essentially just going through a checklist.
And accessibility isn't a checklist.
It's a continuous consideration that extends beyond individual components.
Design systems can provide the building blocks. But they fail miserably when designers and developers use them as an excuse to not consider the whole and test with real people. It's still up to you to ensure everything works together seamlessly.