On Nov. 3, 2008, the W3C‘s Web Content Accessibility Guidelines (WCAG) Working Group published Web Content Accessibility Guidelines 2.0 as a Proposed Recommendation.
WCAG defines how to make Web sites, Web applications, and other Web content accessible to people with disabilities. “Proposed Recommendation” means that the technical material of WCAG 2.0 is complete and it has been implemented in real sites. This is the last step before WCAG 2.0 becomes the official standard.
The WCAG Working Group is welcoming final comments on WCAG 2.0 through 2 December 2008, less than a month away.
I highly recommend that every single person in the web business read this stuff carefully. If you have something constructive to contribute to the discussion, now is the time.
WCAG 2.0 will supersede WCAG 1.0, which has been the operative accessibility standard since 1999. There are some important changes to the standard that all coders, IAs, and designers should take note of, and it’s worth noting that there have been periods of considerable controversy during WCAG 2.0′s adoption process.
Current official working drafts of WCAG 2.0 primer documents:
Read the official announcement. Check the latest changes and status of WCAG 2.0.
This is pretty much gob-smacking news, especially given Microsoft’s open hostility to open source. For those who have sworn like grizzled sailors trying to use the ASP.NET AJAX stuff in something resembling a decent cross-browser fashion, this announcement will no doubt prompt dancing and screams of joy.
jQuery will not be replacing the ASP.NET AJAX libraries but augmenting them, and moving forward the VS crew will be using jQuery to “implement higher-level controls in the ASP.NET AJAX Control Toolkit” and other such like. The new ASP.NET MVC download will also distribute it, and add the jQuery library by default to all new projects. Fortunately, since jQuery is so well architected it already plays very nice with the existing ASP.NET AJAX gizmos.
Updating the jQuery library will reportedly be as simple plopping the new one over the old, though as always you may need to tweak your code slightly or write a compatibility module or something.
Don’t pinch me, I don’t wanna wake up.
Here’s some relevant linkage, lest you think I’m smoking crack:
So, after one too many searches on Google using
site:www.prototypejs.org/api/, I wrote a couple search bar add-ons that simply uses the same Google trick to perform full-text searches of the API docs on the Prototype site.
There are two different versions â€” one for Firefox and one for IE7 (which has a slightly crippled implementation of the OpenSearch protocol…go figure).
Install the Prototype API Documentation search bar add-on here. (Sorry: Firefox and IE7 only.)
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.
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.
And while you’re there, you may also want to visit his similarly thorough posting of Ruby on Rails resources.
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.
Jeremy Keith has a fine post at his DOMScripting Blog in which he makes a fine argument for (gasp!) retaining some basic sanity while drinking all that yummy Ajax kool-aid going around. He even coins yet another buzz word: Hijax.
It really is all very obvious to anyone who remembers the (shudder) browser wars of the late ’90s. Basically:
- Plan for Ajax from the start.
- Implement Ajax at the end.
More specifically, Mr. Keith says:
- First, build an old-fashioned website that uses hyperlinks and forms to pass information to the server. The server returns whole new pages with each request.
XMLHttpRequest instead. You can then select which parts of the page need to be updated instead of updating the whole page.
I know…pretty radical, huh?