I’ve noticed an increasing trend of applications using custom controls to provide the appearance of cleaner interface. However, these pretty controls come at the price of breaking functionality of their standardized analogs. The biggest offender is the new text box most readily found in WordPress, Gmail, Facebook and to a lesser extent, virtually every Adobe AIR application. Not far behind are AJAX remote function links that do not have a standard html fallback.
I’ve come to rely on standard shortcuts. Ranging from the common Ctrl-C/Ctrl-V for copy and paste, to the X’s Middle Click to paste the last block of highlighted text. I have structured my composition style around these and other shortcuts. When some of them are unavailable I get understandably annoyed. However this is more post than a just rant for selfish reasons. Many of these improvements break other accessibility features.
Links to remote functions that lack a href target are a prime example of a custom control standing in the way of accessibility. In terms of controls, they’re closer to buttons than links. When the link doesn’t provide an href target it will not work unless a pointing device is used to select them. Breaking it in terms of both buttons and links. Common AJAX use depends on the onclick property of an element, usually links for historical reasons. There’s no reason it cannot be attached to any other element. The reason for using links is to provide an a HTML fallback for any number of reasons Javascript being unavailable is the most prominent. However when the HTML fallback is missing the control is useless without a pointing device. There are no good reasons to ignore the HTML fallback when modern frameworks make preparing for the case where AJAX is unavailable a trivial affair.
The major concern is that many developers believe that the standard input controls can not meet their needs. Resulting in many of them taking it upon themselves to roll their own versions of those controls. Despite the fact that nearly all of these custom controls can be achieved with some creative CSS and a little bit of JavaScript working in tandem with the standard input. Lets look at Facebook’s new “What’s on your mind?” input.
When the page is loaded it’s a standard text box:
Facebook's what's on your mind input at page load.
As soon as it gains focus it becomes a div with a whole set of javascript triggers to update on key press events:
Facebook's what's on your mind input after gaining focus
Once it becomes a div the only user interface features available are the ones the developer implemented. Div’s don’t naturally accept pasting, but JavaScript can fake it by watching for the shortcut and adding an entry to the context menu. There are other side effects of this form of a custom control. The most noticeable one are browser enhancements, such as spellchecking on form inputs. Firefox will not check the spelling of this div. That’s because Firefox doesn’t expect divs to be used for form input. Nobody does! That’s why input elements exists. There is nothing this custom text box accomplish that couldn’t be done with CSS and javascript and maintain the standard input behaviour.
Gmail’s compose area and WordPress’s visual post editor have many of the same problems, but both manage to get around most of them some how. These tools get a pass in this area because of the added requirement of rich formatting. With HTML4 there’s no good way of displaying formatting changes in the text area. A developer is limited to either using a markup language and providing a preview pane like StackOverflow does, or using a custom control like Gmail and WordPress use. Expecting the average user to learn any form of markup is unacceptable. StackOverflow’s users are anything but the average user, and probably prefer the level control of their posts offered as opposed to a more WYSIWYG editor. The WordPress developers realized that neither approach is perfect and offer both. Gmail does to, but to use the standard controls one must sacrifice many of the other pleasantries of Gmail’s interface.
Reduced functionality from these custom inputs usually aren’t noticeable unless the user goes beyond the standard shortcuts. However, there’s always a few that get away. Tweetdeck, for example, still doesn’t support undo in a text field via Ctrl-Z.
Very few users are ever impacted by these issues, making them a low priority. However, I can’t shake the feeling that in most cases of these custom controls, much more work went into design and testing of building from scratch, than what would have gone into adding the desired functionality to existing controls.
Comments