Slashdot Mirror
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."
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"?
Don't blame Durga. I voted for Centauri.
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.
For more information, click here.
I would prefer to have normally and familiar elements that i can tab through than fancy graphics that don't work as expected.
They look horrible and confusing to me, especially in the example the author has given. If i had come across that form on a page and it said "please select a rating" or the like I would be momentarily confused.
I think there is a good reason why radio buttons and check boxes haven't been styled too much - it's because they are perfect the way they are.
If you want to style a checkbox or radio button atleast make it look like one, get some inspiration from the likes of Opera skins.
I am very glad it degrades well, but javascript is never a solution. The goal of any web developer worth his salt is to make something universally compatible, intuitive, functional, AND good looking regardless of extensions or security settings.
It's a nice hack admittedly. Heck I may even use it on personal sites.
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.
I was using radio buttons for a 1 to 5 rating. So I decided that instead of just boring radio buttons I would use smiley faces with an increasing amount of happiness. I took the smilies from MSN Messenger (our official and only allowed IM, which sucks as much as it sounds). The radio for 1 gets replaced by a crying face, 2 with a frowning face, 3 looks a little confused, 4 is smiling, and 5 has a big grin.
The result was just enough pizzazz to make the form visually appealing as you filled it out. Oddly, I didn't stop to think of it at the time, being in a homogeneous environment, my solution is just as friendly to non-scripting browsers. I use a regular radio button and use the onlick event to put the image over top, a non-scripting browser just wouldn't overlay the image. The only side effect that I hadn't forseen: One employee put in the comments section that she loved the smilies so much she put one of each rating just to see them. She gave us inaccurate ratings (including bad ones) just to see the smilies, and didn't change them before submitting.
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.
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.
Yeah. I was going to perjoratively leave it at the other three, but then I remembered some of the piles of festering crap that have been uploaded to our web server in the past, while I knelt in the background crying and beating my head against the desk.
Seriously - what is it with managers who hire you to be "the expert" in something, then refuse to listen to your advice on scheduling?
Everything in moderation, including moderation itself