Keyboard interaction
A custom widget must support the keyboard interaction specified by its design pattern.
Accessibility Insights for Web, related to WCAG 2.1.1 (opens in a new tab)
Keyboard interaction for custom widgets requires that the widget can be interacted with using only the keyboard. This includes navigating to the widget, activating it, and interacting with it.
This doesn't necessarily require perfect screen reader access for this guideline, this is purely focused on keyboard interaction.
However, by following the appropriate design patterns or using pre-built components, screen reader access is often included.
How to fix
If building custom components, the main considerations can be found covered in Keyboard Navigation where the use of pre-built component libraries can expedite accessibility support.
The other useful tips to consider are covered in Revealing and Closing Content where fully custom components should follow the WAI ARIA design patterns for all custom components.
The crux of this issue is to ensure every component can be interacted with using only a keyboard, but that doesn't mean that mouse options should be removed! It's about ensuring that the keyboard is a viable option for all users.
Component libraries
The issues faced by web developers when trying to come up with a fancy new component are often already solved by existing component libraries. there are many with accessibility built in, and they often come with a lot of customisation options, so it's still possible to make the components look and feel unique.
Libraries such as MUI (opens in a new tab), Chakra UI (opens in a new tab), Radix (opens in a new tab), and Cauldron (opens in a new tab) all have accessibility built in.
While these may miss some complex components, most of these cover a wide array of useful components used in the majority of projects and are a great starting point for any new project.