Further thinking on web applications, keyboard shortcuts, and why we should expect some discussion over what defines an application.
I made an addendum to yesterday’s musing on Accesskeys that I think may be more important than the original point of the article.
To answer that, a more fundamental question needs to be addressed: is an application that runs inside a web browser a traditional application, or a web page? By that I mean, is it fair to say that a web application deserves to break usability standards that one would expect from a web page by virtue of being an application, or should standard browser models apply equally despite functionality? How self-contained (and unlike a browser) can a web application reasonably become?
Let’s consider desktop applications. In Photoshop, when I hit Cmd + L the Levels palette pops up. In Firefox, the same key combination causes the Location bar to be selected. Since I can’t think of a single useful reason to have a Levels palette in Firefox, that’s fine by me. But there are cases where genuine conflicts arise: in most applications, for example, I hide the current window by hitting Cmd + H; in Photoshop, this simply hides my layer guides, and the discrepancy bugs the heck out of me.
I suppose in an ideal world, all applications would share common shortcuts and there wouldn’t be any conflicts. That’ll be the ideal though, since it’s a big world and there are a lot of reasons why it’ll never work that way, varying from different program functionality (eg. Layers vs. Location) to limited options (Cmd + Ctrl + Option + M to mark an item unread? Nobody needs those kind of finger gymnastics).
In the case of the web application, which takes precedence: a browser’s defaults (and by extension, a user’s configuration of the browser, or that of third-party software), or the application’s built-in controls? In traditional applications, we expect deviation between applications due to the mentioned factors and more, so is it such a stretch to expect the same of web applications?
I think by now, many realize that web applications are a special instance where it may just be okay to break standard browser functionality, since things like linkable pages and the back button often don’t make sense in the context of a process-based application, and doubly so in an environment where sensitive information is displayed (think banking).
But on the other side of the coin, there are also people who will adamantly oppose anything that breaks browser defaults. Or at least strongly resist them and eventually give in to reason. Or just think it’s a bad idea. Well, actually, there are people all across the spectrum — just look at the CSS font sizing issue for a similar case where opinion is divided across a multitude of options.
And even if some form of a shortcut conflict management strategy were to formulate, it’s impossible for the developer to know in advance precisely which keyboard shortcuts are commonly relied upon by the user; a key conflict for a Firefox user might not be a problem for an Internet Explorer user running JAWS, and vice-versa.
Some conflicts may be more harmful than others. If a user’s standard shortcut for “switch to another application” is overridden to mean “close current window” in an application it potentially leads to data loss, making it a bad replacement that should be reconsidered. Alternatively, multi-modal options might be feasible that offer the user an ability to switch between application defaults, browser defaults, emulation modes, and other scenarios.
In any case where the potential for conflicts exist, however, the user must have the option of customizing or turning off keyboard shortcuts through site/application preferences. Defaults should be chosen as carefully as possible to minimize the inconvenience, but some groups of users will require further control.
It might be relevant to point out that Accesskeys in their current form are gone from the XHTML 2.0 spec, replaced last summer by something far more powerful. The access attribute removes the responsibility of managing conflicts from the designer and places it in the hands of the browser, and ultimately the user. Would be relevant, that is, if it weren’t for the fact that XHTML 2.0 will continue to be an idea (at most) for a long time yet.
Inevitably though, I think this is one we’re going to have to settle the long way — by experimenting and seeing what works. Ultimately I’d expect it to resolve the same way the font-sizing issue has: there will be various models to choose from, and which method you pick will be determined by your overall development philosophy.