Most real accessibility work is not building a new widget, it is replacing one that exists. The refactor has a fixed order: name the interface, replace it with the simplest natively accessible one, then move the styling onto the new element. Doing it in any other order leaves CSS that no longer applies.
About 1 min of reading
Refactor one widget end to end
Find the worst widget
Before you run it, say out loud what it will print. Then open the answer.
Replace the markup
Before you run it, say out loud what it will print. Then open the answer.
Delete the handlers
Before you run it, say out loud what it will print. Then open the answer.
Verify with the tab walk
Before you run it, say out loud what it will print. Then open the answer.
Markup first, CSS second, JS last and usually deleted. Each step is verified before the next, so a failure is localized to one file.
If the component is only reachable from one page and that page can be redesigned, redesign the page. A component nobody links to does not need to be made accessible.
Swap the div menu for a list of links first, then delete the old rules. If you restyle first, you write CSS for an element you are about to delete.
The old widget had a click handler and a keyboard handler. The new one needs neither. Deleting the JS is the win; porting it is usually a mistake.
Refactor one interface, run the six checks, commit. Two at once means a regression could be in either and the bisect is wasted.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.