Recently, I recommended shortcut keys for a web application and somebody in the room asked if that was even possible. I replied “of course” and cited a couple examples. Gmail immediately came to mind since it was one of the first web apps I encountered with shortcuts. While shortcuts like CTRL+S or ⌘+P are common in desktop apps, they are less so in web apps. However, they can be a huge time saver for repetitive functions and have there place in sovereign applications.

Since that conversation, I have been thinking about how this actually gets done. I knew that HTML has an accesskey attribute and wondered if it was as easy as adding some of these attributes where needed. While this works as advertised, it requires two control keys in many browsers (e.g. CTRL+OPTION), which might not be desirable.

Another method uses javascript to watch for key combinations. keymaster.js seems to do this quite well. There’s also a jquery hotkeys plugin that does the same thing. With these, one can create easier shortcut key combinations, and even override shortcuts defined by the OS and/or browser. Although, one should think twice before overriding OS/browser functionality.

The Codepen for my little experiment appears below…

See the Pen OPxdYK by JP Reardon (@jpreardon) on CodePen.

Anne Gibson’s article, Reframing Accessibility for the Web, is a worthwhile read for anyone involved in web development. In it, she urges us to stop thinking about accessibility as something we do for “disabled people”; rather, it is something we should do for people.

Why? Because we all benefit, even those who don’t identify as being disabled:

WebAIM discusses a phenomenon where a large group of people are asked if any of them have a visual disability. Very few audience members say that they do, even when a sizable number of them wear glasses or contacts. Despite the fact that they (and I) wear assistive technology to see, we don’t see ourselves as “people with a disability.”

Anne also offers some good strategies for reframing accessibility by making it part personas and testing.

Brad Frost has some solid advice in his Style Guide Best Practices post.

The benefits of style guides are many: they establish a common language, make testing easier, save time and effort, and create a useful reference to keep coming back to. And most importantly, it lays a future-friendly foundation for your organization to modify, extend, and evolve over time.

Each point he makes is important, but there are two that seem to get overlooked in many style guide projects: Make it Cross Disciplinary and Make it Last. I’ve seen too many style guides that were directed at one, narrow audience. This means that other groups involved with the product are forced to make their own guide. The chances of these multiple guides matching up 100% are pretty much nil. At the same time, many style guides are not built for maintainability, which is important as a product changes over time.