Category Archives: Web Dev

Are Web Accessibility Standards Doomed? WCAG 2.0 Eviscerated

Posted on by

Required Reading.  In another new article from A List Apart, Joe Clark writes a thorough but blistering and dismaying review of the W3C’s long-awaited new iteration of Web Content Accessibility Guidelines, aptly entitled To Hell With WCAG 2.  (The article includes links to all the primary documents.)

To quote some summarizing comments (with bold emphases added):

In an effort to be all things to all web content, the fundamentals of WCAG 2 are nearly impossible for a working standards-compliant developer to understand. WCAG 2 backtracks on basics of responsible web development that are well accepted by standardistas. WCAG 2 is not enough of an improvement and was not worth the wait.

…A lot of loose ends have been tidied up, and many low-priority guidelines are now pretty solid. The problem here is that standardistas already knew what to do to cover the same territory as those low-priority guidelines. Where WCAG 2 breaks down is in the big stuff. Curiously, though, and perhaps due to meticulous editing over the years, the big stuff is well camouflaged and, to an uninformed reader, WCAG 2 seems reasonable. It isn’t, and you as a working standards-compliant developer are going to find it next to impossible to implement WCAG 2.

…WCAG 2 will be unusable by real-world developers, especially standards-compliant developers. It is too vague and counterfactual to be a reliable basis for government regulation. It leaves too many loopholes for developers on the hunt for them. WCAG 2 is a failure, and not even a noble one at that.

While reading the article, I nearly wept.  Over the last few months, in part because of a client highly sensitized to accessibility issues (which is good), I have spent a great deal of effort educating myself about accessibility issues and best practices.  The touchstone for suches has been WCAG 1.0 — now seven years old.  This standards document serves as a mutual enforcement device:  my client can use it to remind me of what I need to do, and I can use it to remind my client of what is reasonable (and possible) to expect.

And that means WCAG 2.0 will be the new touchstone.  Unfortunately, it’s difficult-at-best to understand, impossible to comply with, and — incredibly — does not even include the most rudimentary demands of valid HTML and (hello!) plain language.

And that means that WCAG 2.0 will not achieve its primary function:  improving web accessibility by providing clear, practical (i.e. real-world), and achievable standards for creating web sites and content.

This is a huge issue that is not merely semantic because in many countries — such as Britain and, oh, the entire European Union — a site that is not accessible faces potentially devastating lawsuits or other legal action.  This is not a hypothetical — just ask Target.com, subject of a huge legal judgement on precisely this point.  And, again, a key standards touchstone are the standards put forth by the W3C — an international body that defines stuff like, oh, the HTTP protocol itself.

Stay tuned, and keep aware of emerging developments.  This is a very big deal.

Securing Your JavaScript Against Evildoers

Posted on by

What with the Ajax invasion and all, JavaScript is once again all over the damn place.  The big difference now vs. the ’90s is JavaScript is doing a lot more heavy lifting and — more importantly — interacting with both host server and browser client (i.e. user’s machine) in ways heretofore (mostly) not seen.  And that means along with all the cool stuff and wond’rous toys and tools comes a whole new avenue for mayhem by lowlifes, script kiddies, and really gnarly folks like the Russian mafia.

Server-side programmers — at least the good ones — are already atuned the potentially cataclysmic horrors that can be wrought via insertion attack methods, but in javaScript circles — even the upper aeries of guru-dom — awareness of such dangers is not as pronounced.  This is bad.

Fortunately, A List Apart is doing its part for responsible web development (as usual) and has posted a good 2-part primer on writing secure JS code by Niklas Bivald:

Community Creators, Secure Your Code!

Community Creators, Secure Your Code! Part II

Let’s hope this is the start of a trend of articles and discussion along these lines.

Do NOT Use Internet Explorer…For Now, At the Very Least

Posted on by

In case you haven’t heard, there is a grievous “Extremely Critical” security hole that affects IE 5, IE 6, and IE 7 betas prior to Beta 2 (just released concurrently with the MIX06 conference). This one is not something to be trifled with. If you are a regular IE user you are taking your life into your own hands and should immediately switch to Firefox for the time being, or at least consider one of the stop-gaps below. If you’re curious, here’s the relevant post at the Microsoft Security Response Center Blog.

The problem is with an IE-only JScript/JavaScript thing called createTextRange. The security hole permits evil bastards and their feckless henchmen to easily install keystroke capture programs and, oh, anything they want directly to your computer. No muss, no fuss — just living hell for you.

Since the bug was revealed late last week, hundreds of (obviously) disreputable sites are reported to have modified their code to take advantage of the security hole and install Evil Shit ™ to people’s computers. Microsoft says they are actively targetting such sites with legal action and what all to get them shut down or whatever, but no matter how dilligent they’re actually able to be it’s inevitably like bailing the Titanic with a teaspoon.

There are a couple 3rd-party (non official!!) fixes floating around out there, but latest word from Microsoft is they will likely not release a bug fix until April 11 — a full two weeks away. Be advised that using 3rd-party fixes may not quite plug the hole, can cause other unforeseen problems, and/or cause tomcat urine to magically appear all over your leg. Or they may totally do the trick. For their part, Microsoft warns “Some of these [3rd-party] solutions make modifications to Windows itself to bypass the attack vector of the vulnerability.” Anyway, caveat emptor, yo.

If you insist on using IE anyway, for godz sakes at least wade through IE’s Options and disable “Active Scripting” (aka JavaScript). That’s Tools > Internet Options > Security tab > Custom Level button > and scroll down almost to the bottom under Scripting and set Active Scripting to “Disable”. While you’re there, and just below that, set Allow Paste Operations Via Script to “Prompt” (if not “Disable”). You should prolly also scroll all the way to the top again and get paranoid with those ActiveX settings. OH, and definitely disable Java in IE for now. Once you’re done, click Apply, then click OK, and click OK again when you’re back to the Security tab. Whew! Oh yeah…then cross your fingers and wait two weeks for the fix.

Um…or just use Firefox in the meantime.

Oh yeah, and there’s a couple other major security holes in IE that were recently revealed, too. One of them involves how IE interacts with Java, and another involves what are called HTAs — MS-proprietary “HTML applications” that have full privileges on the box running them.

Man, coming hot on the heels of the Vista postponement and resulting shake-up of high-mucketies, this has been a bad couple weeks for Microsoft.

Variably-Sized Pop-Ups with No onclick

Posted on by

This is a variation on Jeremy Keith’s script in DOM Scripting (Friends of Ed / Apress, 2005), pp. 86-88. (The same chapter is available on the official book site.)

While Keith’s original was intended as an example of other concepts and not a be-all-end-all pop-up script, it has some noteworthy limitations.

  1. The dimensions of the pop-up are hard-set in the JavaScript, thus making all pop-ups the same size. Also, modifying the sizing requires delving into the script’s innards.
  2. You cannot concatenate CSS classes — you can only style based on the one class name (“popup” in the example) or globally for all A tags, thus limiting your ability to custom style any given link. Also, attempting to add additional class(es) breaks the pop-up functionality.
  3. The pop-up’s window name is also hard-set in the innards of the script — all secondary pop-ups can only target the original pop-up.

My variation addresses these limitations while retaining all of the original functionality and adding only 7 new lines of code, plus 4 global variables for easily setting key default values (class name to trigger on, width, height, and window name).

I also threw in a couple lines in the generic popper-upper script itself to center new pop-ups — a personal preference that can be removed or modified as is your want. (Fwiw, the same approach I use for applying custom sizing could also be applied for custom positioning.)

Caveat: At this writing, I’ve not just yet tested this in Safari or IE7 (or IE5/Win), but it’s working well in FF and IE6.

Update:  Yep, works in everything — even (gasp!) IE5/Mac.  Meanwhile, watch this space for an updated and more flexible version.

For full details and sample markup, visit the examples page. (Unfortunately TinyMCE — the otherwise excellent HTML editor used in WordPress — is either too stupid or too smart for its own good to allow me to post valid HTML samples here.)

Or — download script file with inline code notes, and/or download the optimized script file (with usage notes).

Roundup of JavaScript Libraries

Posted on by

Okay, it’s a little old (November last — so not that old, tho these days it’s all relative), but I only recently came across it and man do it kick but.

eDevil (aka Saddam Azad, 18 year old Bangladeshi code whiz) has compiled an exhaustive roundup of JavaScript libraries, providing info, download and (gasp!) documentation links for a huge number of libraries, Ajax toolkits, and a few good tricks to boot.

And while you’re there, you may also want to visit his similarly thorough posting of Ruby on Rails resources.

FireBug Ajax/DHTML Debugging Tool for Firefox

Posted on by

It’s brand-spankin’ new (and the developer owns up, calling it a “pre-pre-pre-alpha release”), but man the FireBug extension is right handy.

Some initial caveats:

Some users report the XMLHttpRequest Spy feature works fine when using the Prototype library but apparently maybe not so much when using roll-your-own XHR functions.

While the dev says FireBug “only shows you errors and log messages that came from the page you’re looking at,” I noticed today that is not necessarily so. I was working with pop-ups, so it could be this early version gets confused when dealing with child windows. I didn’t get all empirical with it, so your mileage may vary.

Web Accessibility Laws Around the World

Posted on by

Web accessibility is always a Good Thing, but depending on your (or your client’s) context it can also be a Legal Imperative complete with Dire Consequences for failing to toe the mark. Those of us with clients in Britain or Australia, for example, or within the governmental sphere must be especially mindful about accessibility when building sites.

It ain’t exactly fun, but one incredibly useful resource for learning the intricacies of legal accessibility requirements can be found here on UI Access’ accessibility resource links page. (The rest of the site is worth visiting, as well.)

Elegant Fix for PNG Alpha Transparency in IE 5 and IE 6

Posted on by

Internet Explorer’s lack of support for alpha transparency in PNGs is the bane of many a web developer. This vexation will only increase upon the relase of IE7, which will support it. (I can attest to this.) Professionals burdened with contracts requiring support for the elder versions of IE — albeit only in the interim with IE6, though longer for IE5/Mac (yes yes, I know Microsoft has finally given its official kiss of death to it, but you know how it goes) — will gnash their teeth and wail and pollute a thousand blogs with a million tirades. Yeah well, life’s tough. Chew harder.

Of course, IE6 and younger will support PNG transparency…so long as you employ the incredibly annoying (albeit useful) AlphaImageLoader filter in your CSS. (Word to the wise: the bloody thing blows up real good if you use double-quotes to enclose the SRC reference and attributes. You have to use single quotes or [cringe] no quotes at all.) Okay, there’s also a gnarly deal involving an HTC file, but while it works I won’t dignify it with any further comment on assumption that you (or I) are coding under circumstances that don’t cotton to such a thing for whatever reason. Apparently there’s also a Flash-based fix…but puh-leez.

There are some good AlphaImageLoader code-arounds like this one from A List Apart, which works quite well. But that and all of the others I’ve seen still depend on custom markup within the body of the document. For example, in the ALA hack you have to give each image its own ID (which must be page-unique, of course) and provide for specific treatment of that ID in your CSS. If you’re building brochure ware, that’s a little inelegant but it’ll work. But what if you’re dealing with images coming from a CMS? You can’t reasonably hope to automate that. Or what if your client will be updating images on static pages? Do you really want to have to train them in div this, ID that, add CSS another…and hope they actually remember all this? What if you just have a distaste for code bloat?

Well, in that case three cheers for Bob Osola and his “PNG in Internet Explorer” fix…from, um, way back in June 2004. It leverages a couple proprietary (but gracefully degrading) Microsoft tags, a little JavaScript and, in some pinches, a 1×1 transparent GIF. The result? Add a HEAD link to some external JavaScript and plop your transparent PNGs in your BODY and forget about it. No custom divs, no CSS bloat. It will even work in IE/Mac.

…Okay, with a few (mostly) relatively minor caveats. JavaScript has to be enabled…but ALA’s solution requires the same, and anyway if a user has disabled JS they’re A) savvy users and B) will be expecting degraded experience anyway. Also, Bob’s out-of-the-box code chokes on rollovers…but he has a fix available in the HTML source of his Mouseover Demo (though judging by the latency there may be some optimzation that could be applied). More significantly, transparent background images are not fully supported and may cause some problems with links over non-transparent portions of the image. However, I’ve used Bob’s fix with non-repeating BG images in a UL-based navigation tree with no trouble whatsoever. So on this point, your mileage may vary. Finally, and yeah this may drive some folks batty, CSS rules applied to the IMG selector get lost during the on-the-fly conversion. But even this has a workaround provided by the benificent Bob. And me personally, I do everything I can to avoid anything like this beyond your basic border: 0.

I suggest only a couple-few user tweaks to Bob’s out-of-the-box code. First, the conditional comments. (IE recognizes these as code to process, all other browsers treat them as garden variety HTML comments.) Bob’s examples (granted, a little dated) suggest using the following:

<!–[if gte IE 5.5000]>
<script type=”text/javascript” xsrc=”pngfix.js” mce_src=”pngfix.js” ></script>
<![endif]–>

This tells IE “if you are Greater Than or Equal to version 5.5000 then…” link to pngfix.js. At this late date, I’d just use:

<!–[if lt IE 7]>
<script type=”text/javascript” xsrc=”pngfix.js” mce_src=”pngfix.js”>
<![endif]–>

In other words: if you are IE and you’re Less Than version 7, then do the do. True, since the AlphaImageLoader filter is supported only by IE 5.5 or later, this may cause some issues for 5.0 users. But in my own testing, fwiw, it actually worked just fine. (Hopefully I won’t live to eat those words.)

My other two main suggestions involve the JavaScript. The most important one, IMHO, is to combine the two different solutions into one code set. To explain, there’s two different sets of JS — one for yer basic PNG, and another for imagemaps and graphical form buttons. Just merge these two code sets into one. There’s no sense in adding another HTTP request if you don’t have to, and they will peacefully coexist together just fine. (I’m assuming the same can be applied to the aforementioned Mouseover fix, but I admit I haven’t actually field tested that just yet.)

Lastly, to squeeze out a couple more kilobytes, just strip out the tabs, carriage returns, and unnecessary spaces from the JS source. Of course, you should first scour the code to make sure everything has all the semi-colons and containing curly brackets that (really) should be in there anyway.

I’ll update this post later to provide a link to my own version of the optimized JS code. But right now dinner beckons.