Recently, we’ve been working on HTML, CSS, and JS-based wireframes for a healthcare application, and we came upon an interesting interface problem: dealing with content that, on first glance, would beimplemented using HTML <select> elements. After more research, we realized that we weren’t dealing with simple lists of choices that usually lend themselves to a <select> - we were dealing with lists that contained many options, and options that sometimes needed to show detailed descriptions - two user experiences that aren’t so great on smaller screens.
After implementing a rough off-canvas approach wherein the user could click a button (“choose your doctor”), and an off-canvas “panel” would push in from the right of the screen, I started to second guess the accessibility of off-canvas approaches, and I also started to wonder if off-canvas was even the correct interaction and implementation for the problem we were trying to solve.
I was also dealing with something that was slightly different than an off-canvas “menu”, which is what the majority of tutorials around the web usually cover. Due to source order, I couldn’t easily wrap my off-canvas content in a container and wrap the non-off-canvas content in another to achieve that “push” effect that has become somewhat synonymous with off-canvas interactions. Cloning & re-inserting stuff with JS was an option, but one that didn’t feel like the best solution to me, either, because I had concerns about performance and perceived performance.
So, I started to dig into it a bit. My first step was to do a quick run-through with a screen reader, and I had some mixed results, so I took to Twitter to ask some questions. Then, I ended up having a great conversation with some of our friends including Dave Rupert, Todd Parker, and Dennis Gaebel. The result: off-canvas stuff can be done with accessibility in mind, and source order challenges can possibly be addressed via flexbox. Awesome.
Surprisingly, the next morning, I came across a post on Medium that very closely described our original interaction problem! It’s always interesting to see how others approach problems - especially when you’re trying to solve a similar (or the same problem). That post doesn’t go into the code that ultimately got implemented, but it does give a great overview of the decisions leading up to implementation.
As we build out more complex interfaces in a responsive way, we’ll likely continue to explore off-canvas content as a way to solve interface problems. Thanks to everyone who chimed in and helped me think through this! If anyone wants to talk more about this stuff, ping me on Twitter: @patrickfulton