Arg, your final result is unclickable in Opera! I can guess it’s maybe because Opera (my version) agrees that pointer-events do exist (so something like modernizr would think it’s supported), but doesn’t actually do anything with them. Worse than IE9 there.
I only know this because Lea Verou mentioned it in a CSS talk where, for the first time, I heard of wonderful pointer events, which I use in code all the time to disable clickables who don’t actually have a disabled property, or do but then I can’t style it.
I have used something similar to your technique for fancy checkboxes and radios. http://www.muldi.nl/ict-accessoires-phone-en-tablet-accessoires-tablet-accessoires/6/ I had to make kinda big sprites for these, for focused-but-unchecked, focused-and-checked, disabled.
I think it was based on cssninja’s implementation, and does suffer the zoom issue (blurring, which yours should not as you use SVG).
My implementation used a container around each label-input pair, and IE didn’t like, so I had to make certain IE8 didn’t get all my padding and positioning and stuff.
Originally, the creators hoped it would die eventually, the way the PhoneGap people hope some day their software no longer gets used (…because not-needed). HTML5 specs have added many roles and states to HTML elements, meaning they are the same as those in ARIA.
However as we know, HTML is limited, and HTML5 cannot replace ARIA. It simply doesn’t cover every case and tends to leave us with little more than divs and spans and anchors to create complex applications or widgets. This is where ARIA is most necessary because basically, you’re making a new thingie and need a way to tell the underlying OS what these are and what they should do. Each OS has a list of controls, states, permitted behaviours/listeners and whatnot on things. For example, the reason a browser knows what a checkbox is isn’t because of HTML (I should say, not only because of HTML), but because the Operating System knows what a checkbox is (and so therefore the browser, other desktop applications, etc).
This is why when a screen reader user is using a browser to access a web page with a checkbox, that underlying accessibility layer of the OS is able to tell the SR “this is a checkbox, and its state is checked|unchecked”.
Here is a better and deeper explanation.
I see the execution of it as being no more or less finicky than any other browser/OS-implemented thingies. Few things work completely the same cross-everything. Watch:
Yes, I know Bram, met him and Abbott twice, I think. Have you ever met a non-friendly labrador?
I haven’t talked with Bram about ARIA, but it wouldn’t surprise me if his beef with it is when it’s used as a substitute for regular semantic HTML (like when Google pulls this shit:
<span role="link">click me!</span>+a pile of onclick listeners), or when developers make something like a menu* or other quite complicated widget but don’t follow the spec entirely. Screwing up one role or state or not following the rules of which elements with roles can contain which other roles, etc, will break compliant browsers and readers. Another known issue is developers using application roles on things because the name suggests “put this on whatever you think is an application” without understanding that an application role means “hijack the built-in AT keyboard functions so the developer can replace them with his/her own listeners”. Which for things some people might consider applications (a modal dialog with a form in it) shouldn’t have this role as it prevents simple things like reading text or navigating.
But, the point of trying native/semantic first (good practice, like mobile-first or content-first), It’s why as a developer I’d probably try to spend the time seeing how I could keep the label being a label and the first option being an option in your dilemma first. (or multilemma? since there are multiple ways of doing this)
* re menu: here I don’t mean a navigation menu, although people seem to be ARIA-ing these up as menus. By “menu” I mean like the menu you get when you right-click somewhere. An application menu. These need some special ARIA junk on them to fully reflect what they’re doing, or no ARIA at all, but adding some or adding it incorrectly will completely break it for someone. I wish the specs were clear on what “menu” means, despite the fact that it only talks about “controls” inside them etc.