Be careful with "this"!

If you've ever struggled with registering JavaScript object methods as callbacks, you're bound to enjoy this recent post by ATRC colleague Simon Bates:

Registering JavaScript object methods as callbacks

I hope it brings you closure.

Transparency in Community Decisions

Transparency should be applied to how decisions can get made in FOSS communities. This can involve different layers; for example, transparency could apply to:

1. Who gets to participate in decision making.
2. How these people are selected.
3. The process of decision making.

In FOSS communities I think transparency should apply to all three where reasonably possible. What do I mean by this? Let's take a couple of examples:

A) Getting hired by a FOSS organization which is integral to the community.
B) Getting commit access to an svn repository.
C) Getting syndication of one's blog onto a planet/aggregator.

A FOSS community might decide on the following transparency for each example:

For A: Transparency of 2 only.
For B: Transparency of 1, 2 and optionally a moderated version of 3.
For C: Transparency of 1, 2, and 3.

How might the transparency by realized?

Let's take example C, the blog syndication; the decision maker(s) should be known, perhaps listed right on the planet. The way the decision makers were chosen should be known, this could exist on a wiki page, perhaps in the governance section of the project wiki site. The decision process could be made transparent by requiring a public trac ticket for every blog that gets added, with the required number of decision makers commenting on the ticket directly, for all to see. As an added bonus, the community could chime in on the ticket with opinions.

Transparency can help avoid conspiracy theories.

Graceful Degradation is Good

Hmmm, what do you do when you impulsively blog something and then change your mind?

My last post, titled "Progressive Enhancement++", looked at how one of the principles of progressive enhancement calls for unobtrusive JavaScript, which calls for graceful degradation. I said I was not fond of this latter principle. That's silly of course! Silly, silly, silly. At least for now.

Progressive Enhancement++

First off, I don't mean to imply Wikipedia is fact.

According to Wikipedia, "Progressive Enhancement consists of the following core principles:
* basic content should be accessible to all browsers
* basic functionality should be accessible to all browsers
* sparse, semantic markup contains all content
* enhanced layout is provided by externally linked CSS
* enhanced behavior is provided by unobtrusive, externally linked JavaScript
* end user browser preferences are respected"

I'll ignore the problems defining what constitutes "content" in the world of DHTML applications, but notice above the reference to unobtrusive JavaScript. According to Wikipedia, one of the basic principles of unobtrusive JavaScript is "Graceful degradation in browsers that are unable to express the behavior layer in the desired manner"

I'm not terribly fond of this latter principle. A bit strange for an accessibility guy eh? Well. JavaScript is a great language, is becoming available in all sorts of places (including browsers on mobile devices), and can now be made accessible using ARIA. In fact, when DHTML is designed well, and using an ARIA enabled browser like Firefox, the experience for users of assistive technology can be greatly improved.

I don't think there is a term for what I see as an alternate design strategy: one that looks a lot like progressive enhancement, but does not strive to work in a JavaScript-less environment.

Mobile Research

I've been meaning to report about my growing involvement in the mobile space.

I'm involved in a mobile device research entity here at the ATRC called SCYP and we just launched our call for proposals. We want to change the world on a shoe string and we need help. Of course I'm steering the project towards free and open technologies... and attending the weekly standups with a swanky new N810 maemo* in hand just might help that along. Oh that, and I'm providing technical oversight for this research entity, which affords me some influence.

Any folks who want to get involved and have a project in mind, or are already doing stuff you think we should know about feel free to comment below or email scyp at atrc dot utoronto dot ca.

*Note: On November 12th I learned I was one of 500 lucky people to be accepted into the N810 maemo device program. Thanks!

Directed Giving at Mozilla

Aaron Leventhal just dropped a note on the dev-accessibility mozilla list that the Mozilla directing giving program is now live!

See Frank Hecker's blog: directed-giving.

In his note Aaron provides a direct link to the Mozilla accessibility donation page:
http://www.mozilla.org/access/donate.html

Accessible CAPTCHA

Every voice is important, except for spammers.

CAPTCHA stands for "Completely Automated Public Turing test to tell Computers and Humans Apart". Here's one that claims to be accessible:reCAPTCHA.

It will be great to see those communities that understand the future is for everyone start using accessible CAPTCHAs. It is also just good business sense.

Dojo 1.0!

Dojo the javascript toolkit version 1.0 is ready for download.

Dojo has three main bits: dojo, the tight handy core, dijit, the accessible widgets, and dojox, the dojo/dijit breeding ground.

Thanks to IBM and Mozilla and others for helping make dijit accessible!