What does your app still decide?
Define the steps and the controls to highlight in your code. Your app decides when to offer the tour, who sees it and what happens when a person finishes or skips it.
Keep an explanation available when a control is hidden or changes names. The tour should help the person do the task, and the normal page still needs to work when they close it.
Which controls and words should you verify?
Driver.js documents options for keyboard control, closing and button labels. Use clear labels in the language of the page. Verify how the tour opens, advances, closes and returns focus to the normal task.
Options provide behavior you can configure. Test keyboard and screen-reader use on your own pages, including cases where a highlighted control is unavailable.
What moves with your app?
Driver.js is MIT-licensed. Tour definitions and wording can stay with your code. If you decide to store dismissals, progress or analytics, your app needs to decide where that information lives and how to move it.
How can you find a broken tour on paper?
Sketch a fictional workspace and two tour steps. Use no installed library, real app or connections.
- Hide a control in one drawingShow how the person can keep going if the tour’s second target is unavailable.
- Mark the keyboard routeDraw the path from the tour launch to Close and back to the next control on the page.