06.01.06
Posted in Web Dev, Reference, What I'm Reading, Accessibility at 9:49 pm by Spencer
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.
Permalink
02.13.06
Posted in Web Dev, AJAX, Reference at 8:17 pm by Spencer
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.
Permalink
01.17.06
Posted in Web Dev, Reference at 8:58 pm by Spencer
If you have a valid Seattle Public Library card, you can get free online access to books from O’Reilly, Peachpit, AdobePress, Macromedia Press, New Riders, Microsoft Press, and many more.
Just go to http://webpac.spl.org/rpa/webauth.exe?rs=stb and log in.
The King County Library System also offers a similar service.
Online books / eBooks: http://catalog.kcls.org/search/dElectronic+book+collection./
delectronic+book+collection/-2%2C-1%2C0%2CB/
exact&FF=delectronic+book+collection&1%2C3855%2C
Databases: http://search3.webfeat.org/kclsmain.html
Permalink
01.04.06
Posted in Web Dev, Reference at 9:56 pm by Spencer
sIFR and Anchors Can Be Friends! Marc over at the Crossroads blog (basically consisting of only the one post) provides an excellent article on issues affecting link accessibility and how to modify the standard sIFR Javascript and ActionScript to fix it. Great work.
Note, of course, that this pertains to accessibility for links in a sIFR context. One of the great boons of sIFR (aside from eliminating hours of boring Photoshopping) is that ascii text treated with it is 100% accessible. Er, except the link thing, to some extent.
Note: Well, that’s what I get for going off half-cocked. Turns out the anchor hack fails miserably in Firefox 1.5 — the sIFR-ized text has a tendency to disappear entirely (sometimes) in that browser. I’ll investigate further to see if I can jimmy the whosis. But meanwhile, caveat emptor and (always) test thoroughly before going live, kids.
Marc’s contribution makes a fine companion to Marko Dugonjic’s excellent two-color sIFR hack, so’s you can have more than one color in a block of sIFR-ized text. For that you’ll need the first article and the second part, which includes some more standards-compliant optimizations.
Note: A couple drawbacks to the 2-color hack are worth mentioning. Foremost, the second color must be encoded into the Flash file itself (via one of the ActionScript files). Changing your site palette will thus mean re-encoding the sIFR. (I’ve not tried hacking the hack to see if it can be repurposed to, say, a CSS class, tho I’m not optimistic since it relies on dynamically swapping in an olde school FONT COLOR=”foo” tag.) Also, integrating the hack is kinda cumbersome in a couple ways. One, it was created for an earlier version of sIFR, and so the “find this and replace it with that” stuff in many cases no longer explicitly applies — which means putting on your reverse engineering hat. Two, part two of the article is revisions to the previous revisions — which means you gotta reverse engineer the changes twice.
Both of these hacks are officially sanctioned included in the sIFR documentation wikki, but is not officially sanctioned by the creators of sIFR. (See comments, below.) I’m also pleased to report that the wiki appears to have been fixed and will now talk to you even outside of bankers’ hours. Hooray! (Or boo…that means I don’t have any excuses when working late or on the weekend.)
(If you don’t know about sIFR, then get thee to the official sIFR site right quick.)
Permalink
