For the most part, the web is accessible by default. That means properly structured content should go a long way and be perceivable and consumable by everyone, regardless of how they browse the web.

As we make sites and applications more and more interactive however, accessibility sometimes suffer. Basically, anything that needs to be developed by hand because it is not natively supported by the web platform is at risk of causing accessibility issues down the line. Whether it is because of designers’ lack of awareness, or developers’ shotcoming in face of a difficult technical challenge.

When adding interaction to a page that goes beyond links and forms, we have to be cautious and proceed carefully. First of all, is the solution really the best one or is there something simpler and more straightforward? Interactive widgets such as tabs, dialogs and toggles come at a cost: usability, clarity and performance.

If you must though, rely on battle-tested implementations instead of rolling your own. While a dialog might seem as simple as displaying an element on top of the page, there is actually a lot of work going on there, and unless you’ve read the specifications or are well aware of the intricacies of such widget, you are most likely going to implement it incorrectly.

Here is a collection of unflavoured JavaScript suggestions if you must implement an interactive widget:

If you don’t mind something a bit more rough around the edges, you could check the WCAG Authoring Guidelines which have an entire sections dedicated to understanding the expectations of interactive widgets. Scott O’Hara also maintains accessible components on GitHub. Once again, avoid rolling your own implementation if you can, and use an accessible solution instead.