Check Boxes and Radio Buttons Conquered by DHTML

Philip Howard writes "Pretty much every form element has been conquered by CSS so far, letting us create stylish, integrated forms to tie in closely with our site designs for that UI polish graphics artists love to have. Radio Buttons and Check Boxes, however, have resisted most attempts to style them consistently, accessibly and elegantly- perhaps because nobody cares enough to come up with the solution. However, these elusive form elements have finally been conquered with a simple combination of CSS and Javascript and a little HTML wrapper. The solution is easy and quick to implement, is accessible (working with tab and space) and elegantly degrades where CSS and/or XHTML is not available."

Comments

Is this a good thing?

[AtariAmarok]

Is it a good thing to have controls that deviate from the standard so much that they aren't even recognizable anyore, like the green/grey round toggle button that replaces the checkbox on the sample page? Why disguise standard controls so the user will have to spend some time trying to find out what the standard controls are "hidden as"?

Spiffy

[generic-man]

The examples look very nice. I still think the bigger problem is that web applications have absolutely no UI consistency between them, though. On one web site, select-boxes cause a form to be immediately submitted when a selection is made; on others, you have to click "Go." On one web site, check boxes look like boxes with check marks; on another they look like stars; on another they look like glowing orbs (not very colorblind-friendly).

This is the sort of thinking that leads to such UI atrocities as Winamp, iTunes for Windows, and Firefox for Mac OS X: all three of these ignore most of the native widget drawing capability in the name of creating a pointlessly slick, cross-OS-consistent experience.

I for one welcome the arrival of XAML and XUL: ways to describe forms that every OS will render using its own navigation and widget capabilities. It'll be as awesome as the time Java solved that problem for everyone everywhere.

Re:Not really new, but interesting

[MarkEst1973]

Is anyone really browsing the web from their cell phone? PDA? The resolution and functionality in these things are terrible. We have a decade of hard experience behind us building good web browsers. Let's build one into devices that want to surf the web.

The same goes for screenreaders. I have to make my applications Section 508 compliant everyday because we're a gov't contractor. It sucks. If Mozilla and IE know what elem.innerHTML is and can render it, why can a screenreader not work like a real goddamned web browser? Then it too would know what my elem.innerHTML is and can read it accordingly aloud to the non-sighted user.

There are real 508 problems for blind folks. Implementing a "skip nav" hidden link to bypass the multitude of primary navigation links is standard. If we can pass the user around the page like that, why not include more dynamic pieces in the page and present a non-visible menu for blind people? "Press 1 for My Profile, Press 1 for ... blah blah blah". As they press a button, *javascript and dhtml* take them around the page, reading more parts of the menu.

In my mind, a very accessible app would be more like a phone VRU to a blind person. But what's the problem? JAWS doesn't know shit about a page beyond html markup. It was only in the past few years that they managed to handle nested tables well. So blind people are lost when it comes to even Section 508 compliant websites, because screenreaders as they exist today suck.

Rich web applications (a la GMail, Google Maps, Flikr, Backpack, and other AJAX style applications) are a rennaissance of web programming. They are increasing usability at the expense of accessibility. The vast majority of users are sighted and on a PC. I don't think the solution is to code down to the lowest common denominator, but to build up the other dumber clients of web apps.

Re:Not really new, but interesting

[Pete]

Well, I am actually coding it to be standards-compliant. And it is. It just doesn't YET work correctly in KHTML/KJS or Opera (believe it or not, neither of those engines are perfect - of course, neither is Gecko/Spidermonkey, but G/S is less imperfect :-)). But they're getting closer - it seems that every time I test a new Konq or Opera release, more things work correctly.

This is not your usual web application. It's all a single page, and almost every user action is handled with asynchronous XMLHttpRequests. It's pushing the envelope a fair bit, yes - but my boss is happy and so I'm happy too :). It is pretty amazing what you can do with Ajax when you don't have to be held back by IE limitations.

What if your employer opens the site up to a new partner, which only uses MSIE? What now?

Well, it's pretty damn simple. If they want to use the app, they use a supported environment *shrug*. Just like any other software vendor. Except it's about a billion times easier to install and run an alternative browser than it is to install and use an alternative operating system on your computer (when my boss was demonstrating to a potential client, it took him all of two minutes to (a) download, install and run Firefox and (b) get our app running on the newly-installed Firefox).

In some ways it's easier if you think of it like the web application is a "real" application. It's just that you install Firefox (or Mozilla, or K-Meleon) on your desktop to "run" the application (instead of, eg. a Java or .NET runtime environment). And of course in the near future our app will work with every major browser except IE.