mindforks

Wanted: Mozilla Accessibility Developer

2011-03-21T12:02:00.003-04:00

Best. Job. Ever.

Accessibility provides one of the most interesting and rewarding software development careers. This statement is biased to be sure, but consider these examples of problems in web browser accessibility:

Exposing JavaScript driven web applications to screen readers.
Making new HTML accessible, for example: canvas and video.
Gathering information from the layout engine asynchronously but supporting desktop clients synchronously.
Caching information about web content and reporting relevant changes to assistive technology desktop clients.
Communicating the changes of a mutating DOM performantly and securely; choosing the right data structures and optimizing our traversal and filtering algorithms.

The web browser is a large and complex program. In order to do a really good job with providing web accessibility through the browser you should understand how everything works, including the layout engine itself. There is no end to the learning process and the depth of real world computer science-y goodness.

Pretty soon we'll work to provide an enjoyable eyes-free experience with Mobile Firefox on Android. We'll need to refactor our accessibility engine for out of process content. We'll need to help design and drive the next web and desktop accessibility APIs. We'll help define speech on the web. We'll do this because it helps people with disabilities participate in the open web and because we love it.

Sound intriguing? If interested please send a plain text résumé to: the first letter of my first name joined to my entire last name, at mozilla dot com.

Asynchronous Accessibility?

2010-11-05T13:56:00.008-04:00

Our current gecko accessibility engine (GAE) happily serves chrome and content information through synchronous desktop accessibility API such as MSAA/IA2. For example a screen reader makes a synchronous IPC call over COM via MSAA/IA2 into our process where we (GAE) grab the information requested and return it (pass it back).

Firefox will almost certainly be moving web content rendering out of the chrome process. Communication between chrome and content processes will be done asynchronously because users like their browsers to be responsive. Desktop accessibility API is implicitly synchronous. In addition to the chrome (browser UI) process, content processes contain a lot of juicy information (i.e DOM) that needs to be served through desktop accessibility API.

What to do?

Hypothesis 1:
Forward messages between the chrome and content processes.

H1 conclusion:
Fail. Google tried this and it is too slow.

Hypothesis 2:
Cache all the chrome and content information in one process.

H2 conclusion:
Google is now doing this with some success. If a screen reader is detected, they cache the accessible DOM tree(s) in the main browser process. Cache latency can lead to screen readers getting stale information sometimes, but it is expected that firing desktop update events will mitigate this.

Hypothesis 3:
Create asynchronous desktop API.

H3 conclusion:
Yeah, this might be a pipe dream.

I am currently thinking about something like H2, but that would allow assistive technology to transition to H3. In terms of pictures, here is my thinking:

This minimalist figure shows boxes for chrome, and content processes with asynchronous connections to box that represents an accessibility process called "Async Accessibility" (needs a better name). This box butts up to another box that essentially represents our current gecko accessibility engine, which in turn has a synchronous connection to assistive technology (over desktop API).

If we then begin providing desktop access to "Async Accessibility", my hope is that progressive AT could begin using this API when they are ready. As I write this I admit I have serious doubts this would actually happen, but I want to get this thinking out there.

This figure shows AT using asynchronous API to access "Async Accessibility" through some as yet undefined API and usage pattern.

In some ways H2 and H3 are similar, with H2 being more straightforward. I haven't attempted to estimate the engineering effort for either approach but there is a good chance we'll end up with something closer to H2. It all depends on resourcing and time, and how quickly our desktop firefox moves to multi-process content and how long we might support a single process mode.

I'd like to thank Josh Matthews (jdm) for sanity checking this before I posted it. Feedback is welcome. I'm hoping to iterate on this and to ultimately develop a solid implementation plan by mid December.

Thanks for reading.

Firefox 4 beta - AT Vender Relief

2010-09-28T09:52:00.005-04:00

Success. Earlier this month I posted an alert about the temporary Windows screen reader bustage with our Firefox 4 betas. Since then Marco posted a status update about our temporary and long term fixes. We worked together, along with the screen reader developers to provide 3 solutions. The first is a temporary hack, and the other two are long term fixes and probably generally useful anyway:

The "emulation" hack. For known AT that require them, we resurrected the windows that were recently removed from Firefox. We intend to only create these windows for legacy AT so that users don't necessarily need to pay for upgrades for their software to use Firefox 4.
The speedy document accessors fix. We added quick methods to get parent and child documents, and indexed access to documents.
The QueryService fix. Provide a special service ID for getting the accessible object that represents the browser tab content document that contains the accessible object queried. Here's some sample code to illustrate how you might use this service:

static const GUID SID_IAccessibleContentDocument = {0xa5d8e1f3,0x3571,0x4d8f,0x95,0x21,0x07,0xed,0x28,0xfb,0x07,0x2e};

// Assuming you have a CComPtr<IAccessible> accessible
CComQIPtr<IServiceProvider> serviceProvider = accessible;
CComPtr<IAccessible> accessibleDoc;
serviceProvider->QueryService(SID_IAccessibleContentDocument, IID_IAccessible, ( void**) &accessibleDoc);

If the 'accessible' is in web content then 'accessibleDoc' represents the main content document that contains 'accessible'. It works in all cases we tested, including special documents like about:addons, as well as documents with iframes where we still always return the main content document. This support is in our nightly builds and will come with FF4 beta7. I hope this will make it easier to manage your cache and context switching.

Thanks for reading.

Firefox 4 beta - AT Vendor Alert

2010-09-01T11:43:00.015-04:00

Hello friendly accessibility technology vendors and developers.

As of the Firefox 4 beta 5, the child windows associated with browser tabs have been removed thereby breaking the expectations of most windows screen readers. Regretfully, the timing of this change and the substantial impact it has on AT caught the Mozilla accessibility team by surprise. Unfortunately this change is a critical step in our browser's technical roadmap. The good news is that this issue was quickly discovered during our a recent beta cycle and now we can work together on a fix!

Let's fix this the right way. We probably shouldn't have AT relying on window classes to indicate where browser tabs are, however convenient it might have been years ago. I think, depending on how this per browser tab separation has been used in your code, we can provide an even better solution perhaps even allowing some hack removal on your side. We've very recently been in contact with most of the main AT vendors, and some have what sounds like a fix already in hand. We want to make sure we protect all our users from potential bustage, so we want to hear from all accessibility technology developers that use Windows accessibility API and have been relying on per browser tab window classes.

Something to look for... anywhere you have code checking for a specific window class "MozillaContentWindowClass" your code will almost certainly now be broken for FF4 beta5+. Note this class used to correspond to the HWND of the child content window that received focus whenever the top level window gained focus. To see how things look now I recommend Microsoft's UISpy tool. Be sure to run this against the most recent FF 4 beta or nightly.

We have time but must move swiftly. Please contact us directly or on our accessibility community mailing list.

Thanks for reading.

Wanted: Mozilla Linux Accessibility Developer

2010-08-19T11:34:00.006-04:00

The Mozilla Corporation is seeking a software developer for an exciting opportunity to hack in our Linux accessibility layer. The successful candidate will make core code additions and improvements to the accessibility engine used by the award winning Firefox browser, and other gecko based applications.

Requirements:
C, C++
Team player with good communication habits

Bonus:
Atk, AT-SPI
Familiarity or fascination with assistive technology (AT)

Scope of work:
6 month contract. Rate negotiable.

Details of work:
Your primary duties will consist of working with the Mozilla team to fix gecko Linux accessibility bugs. This may include performance profiling of Firefox, Thunderbird, at-spi, and AT such as the Orca screen reader against cases where there is user perceivable slowness. You will work with the Mozilla accessibility team and the Linux accessibility community (primarily the Orca team) to prioritize and fix the most critical bugs. You may also be able to help bring the existing Orca + Firefox automated tests to an acceptable level and design and assemble an automated nightly test setup. You may also have the opportunity to collaboratively make improvements to the Linux accessibility infrastructure (at-spi2).

If interested please send a plain text résumé to: the first letter of my first name joined to my entire last name, at mozilla dot com.

Self Voicing Apps and Screen Readers could live together

2010-04-09T11:32:00.002-04:00

Screen readers are applications that interrogate the desktop, applications, and events, in order to provide users with an aural rendering.

Self voicing applications already render aurally; and as a user interacts with the application, they control what is spoken.

These worlds can collide, and traditionally folks have been leery of self voicing applications. I think of this in the same way as an application might not follow the visual conventions of a given platform/desktop.

But.

What if there was a standard way for screen readers to hook into the TTS system and find out what text is being queued for speech? Then, if the text came from a self voicing application, the screen reader could pull it from the queue and incorporate it as it sees fit.

So like an application should pay attention to "desktop integration", so too an aural application could pay attention to "screen reader integration" except by somehow allowing screen readers to intercept.

Thoughts?

Thanks for reading.

Mozilla at CSUN 2010

2010-03-29T21:14:00.008-04:00

First of all, check out my colleague Marco's recap of CSUN 2010. I'll try add to his report, while avoiding redundancy.

Uhm. Wow. That was rough. Three days of people loving Mozilla.

Meet ups

I landed at CSUN on Thursday afternoon and left on Saturday morning. In the short time I was there I took quite a few notes and looking over them now I see they comprise a long to-do list. I won't bore you with that here. I met with accessibility hackers from such places as GNOME, RIM, Adobe, Novell, Deque Systems, GW Micro, IBM, The Paciello Group, and of course my colleagues from Mozilla, Marco and Alexander. Cheeky Brad Taylor used beer to lure me into an interview. The rest of the to-do list came from interactions with users and suppliers. It was amusing to see how they reacted when I asked them questions like "how can we do better"; gathering it was sort of a refreshing change of pace from the booths that are selling product.

Cloud
No, this bit isn't about accessibility in the cloud. Compared to last year's CSUN, I felt a bit of a dark cloud unfortunately. Dreams of a full open source stack for accessibility have taken a hit recently, with Oracle closing Will Walker's position as GNOME Accessibility Lead, and other funding sources tightening up. Promising Caribou creator/hacker Ben Konrath has been an innocent victim of frozen grant funds within the group that contracted him. This is happening as the GNOME accessibility infrastructure is being ported to d-bus and other exciting and hairy issues loom, such as GNOME 3.0, and GNOME Shell. Novell has been doing more than its share in accessibility, but will that continue? I'd really like to see a coordinated funding strategy among the distros. I can dream can't I?

Sunshine
I am keenly aware of how lucky I am to work at Mozilla. More than ever I am resolved to make the most of it, to seize the days, and to help move the accessibility needle as much as we can. We have a tough road ahead of us with the web moving ever more to visual media, we'll see more usage of canvas, and (hopefully) SVG. We see people excited about video, and captioning. We should continue to support accessibility innovation in web video, to leverage things like javascript access to annotation tracks and sync information. Could be wicked times.

Memorable Moments
In his blog Marco mentioned speaking with a humorous gentleman through a sign language interpreter. Witnessing this, I was deeply moved for some reason.

Dinner with Joanie, the current Orca (Linux screen reader) maintainer, followed by debugging a pesky Orca+Firefox bug.

Finally meeting Charles McCathieNevile, Matt May, Flavio Percoco Premoli, Bryen Yunashko, Mike Gorse, and many others. I hope to see them all again.

Chatting with Steve Faulkner about some shared W3C pain.

Sharing a flight back to Toronto with Greg Fields (RIM accessibility) and planning a UI meetup.

OK that's enough! Sorry. Thanks for reading.

Accessibility Diagnostic Jetpack

2010-02-19T21:11:00.006-05:00

I put together a little jetpack that tells you if Firefox's accessibility service is actually running in your browser. It is basically David Baron's "about:accessibilityenabled" extension but as a jetpack. If you want to give it a whirl, strap it on.

You'll need to grab Jetpack if you don't have it already. Alternatively you can just use David Baron's handy about:accessibilityenabled extension.

Aside: we've noticed the gecko accessibility service is being used in some unusual places, for example, by some desktop anti-spyware; leading to unnecessary performance degradation. If you discover that our accessibility service is unexpectedly running in your Firefox session, please consider contacting me so we can figure out why...

Thanks for reading.

Accessible SVG is closer than you think

2010-01-13T10:58:00.004-05:00

[Firstly, my apologies for not blogging more often (blame twitter). I have a number of unpublished blogs that I've let get stale so I'm going try not to save unpublished blogs anymore. We'll see how that goes. Anyways, here's one I probably should have written late last year...]

Sometime in early December, Aaron pinged me to discuss the topic of SVG accessibility. This led to a quick Firefox experiment (tweeted here) using the cutting edge HTML5 parser and WAI-ARIA. Note this demo is especially uninteresting if you don't use a screen reader. Long story short, it works and will work even better with a little gecko love. Web developers that have already invested in learning ARIA can apply this knowledge to SVG elements, add some JavaScript, and have a pretty striking and accessible application. Note: please don't look to my experiment for "striking" visuals... that's just not my thing... you have to use your imagination here.

I wonder, given the momentum HTML5 canvas currently has in the web developer playground, if the ability to inline SVG in HTML will breathe new life into SVG? As far as accessibility goes, it is certainly something for which I can hope.

Oh and if someone wants to fix up my demo, feel free, and please drop me a line... and I'll link to yours. I'm a total SVG noob.

Keyboard control of html5 video elements

2009-09-04T10:04:00.011-04:00

HTML 5 introduces the video and audio media elements. Playback is manipulated by the user with browser supplied controls (indicated via the controls attribute), or with author supplied controls. In the case of browser supplied controls the current Firefox implementation is described here, and an idea for potentially improved keyboard support is suggested.

Show here is a screen shot of a video with no controls shown. In this case the reason they are not shown is because the mouse pointer is not hovering over the video. Hovering over this now won't show the controls; it is just an image after all.

This next image shows a blown up view of the controls that appear when the mouse hovers over the video. I've also hovered over the volume control here to show reveal the volume slider.
Point at what you need, click what you want, move away, and enjoy your video. Nice. When the mouse user doesn't want to interact with the video, the controls slide away leaving an uncluttered video viewing experience. The gotcha here is that not all users are mouse users, and not all devices have a mouse (or touch screen).

Are you a keyboard user?

We have you covered. You can tab to the video element. The controls are not shown but the you can manipulate the video using some intuitive keystrokes such as arrowing left and right to go back and forward, space to toggle play and pause, and up and down arrows to control volume etc. Sighted keyboard users can enjoy uncluttered interaction with the video, while screen reader users can of course enjoy the same interaction regardless of visual clutter.

We still have some concerns:

1. Discoverability. Once a user has tabbed to a video, it is difficult to tell that the video has focus and there is nothing indicating that the video is keyboard controllable.

2. Feedback. The feedback after a user action is not as rich as the feedback when using the controls. For example, pressing right arrow to advance the video doesn't tell you how far ahead we went, or where we are in the overall length of the video.

An Idea...

Keep the current functionality but add a secondary keyboard interaction model. Once a user has tabbed to the video element then the video is directly controlled via the existing keystrokes. If the user hits tab again, the controls appear, and the first control is focused. A regular keyboard interaction model ensues for the controls (tab navigation, and per control keyboard manipulation). Tabbing past the last control leaves the video element entirely, moving to the next element in the document tab order.

Pros: Discoverability is solved. Feedback is solved.

Cons: It increases the number of items in the overall document tab order. Additional source code is required.

Thoughts?

Innovation and Usability in Firefox

2009-04-22T12:08:00.007-04:00

This is almost a bait and switch... but not quite.

Where I see Frank's Mozilla Accessibility Strategy document providing direction for Firefox/gecko is in the Mozilla development process as it applies to pushing the web forward. Your friendly gecko accessibility team currently consists of 3 core members: Marco Zehe, Alexander Surkov, and some newbie. This team is a vital part of bringing the web to everyone, but also, by its existence, it has the potential to create a false sense of security; sort of a "the accessibility special forces has our back" cushion. To some extent that cushion exists, but you have to make sure you're sitting on it. So what am I getting at?

In a nutshell please see Marco's call for ping-age.

This is happening.

That's great.

Please do it more often.

I'm looking at you too #labs and #ux, cuz accessibility breeds innovation, and accessibility is usability.

Thanks for reading.

CSUN's 2009 Accessibility Conference

2009-03-22T03:53:00.006-04:00

Late last week I attended the 2009 Technology & Persons with Disabilities Conference, a conference which most of us accessibility folks call "c-sun" as it has been held at CSUN for over 20 years. What makes this an exceptionally important conference for accessibility is that it brings users, developers, educators, clinicians, visionaries, and policy makers together in one place. Thankfully a lot of them seem to love Firefox... and for good reason; more on that later.

I was particularly jazzed about getting time in the same room with other Firefox developers: Alexander Surkov, Marco Zehe, and Aaron Leventhal. We spent some mornings, afternoons, and evenings together discussing the past, present, and future of web accessibility, children, wives, and vodka. When people had faded into their rooms, Alexander and I used the later hours to hack together and discuss gecko accessibility code design. His patch reviews are even faster than usual when he's sitting next to me.

Mozilla works hard "to ensure that the Internet is developed in a way that benefits everyone". It seems pretty clear Mozilla, especially with the work in WAI-ARIA for DHTML, has developed a reputation for pioneering accessibility. As UI issues arise on the web people are looking to Mozilla for answers, and we are keen to work with other communities to find the right solutions. To this end I made sure to get some face time with people at CSUN that I think will help, including Henny from Opera, and JP from Microsoft. In some cases attendees made sure to find me. Flattering. Anyways, I won't bather on much longer as I think Marco will be giving a much better report soon.

Smiling in the picture up above are: Marco Zehe, David Bolter (me), the NVDA developers Mick Curran and James Teh, Aaron Leventhal, and Alexander Surkov (Eitan was absent for this photo). I quite like how Marco's cane glows like a Jedi weapon in this shot.

May the force be with us.

Firefox Accessibility Goals

2009-03-12T16:21:00.006-04:00

Ahhh Spring.

As we approach the ides of March, it is time for the Mozilla accessibility community to reflect, and to plan for the next quarter and beyond. Here are the high level goals we are thinking are priorities for next the few months:

OS X
DHTML (WAI-ARIA 1.0 compliance)
Stability and test coverage

None of these are new high level goals, but each one has important new work waiting underneath. By the end of the month we hope to have this new work listed as concrete goals which we can use to organize our efforts. We'll report on that later. Other ongoing fluid goals, such as supporting community projects will continue to be high priority.

All this planning is based on user feedback so feel free to leave a comment on this blog or drop a note on Mozilla's accessibility list... we're listening. Oh! If you happen to be at CSUN next week, please come find one of us at the Mozilla booth!

Thanks for reading.

ARIA User Agent Implementation Task Force

2009-02-27T12:53:00.004-05:00

Today we kicked off the first meeting for the "ARIA User Agent Implementation Task Force" (UAI-TF). Our primary goal is browser compatibility in our WAI-ARIA implementations for DHTML accessibility -- vital stuff. The group is very lean and today there was representation from browser people at Microsoft and Mozilla.

If you are an Opera, Webkit, or Safari accessibility developer please consider joining us.

Aside: a big shout out for Aaron Leventhal for planting the seeds of this, and for the excellent and detailed document he created to guide browser developers on ARIA implementation.

Call for review: WAI-ARIA

2009-02-24T15:02:00.006-05:00

If you are somehow involved in supporting interactive web content, please consider reviewing one or more of these W3C documents related to accessibility.

For everyone involved in web content, this is the document with actual "Last Call Working Draft" status:
Accessible Rich Internet Applications (WAI-ARIA) 1.0 - Last Call Working Draft
http://www.w3.org/TR/wai-aria/

For web application ninjas:
WAI-ARIA Best Practices - updated Working Draft
http://www.w3.org/TR/wai-aria-practices/

For browser developers:
WAI-ARIA User Agent Implementation Guide - First Public Working Draft
http://www.w3.org/TR/wai-aria-implementation/

It is important that these documents are understandable and consistent. The deadline for having an impact via your comments is April 17th, 2009. Official channel is: public-pfwg-comments@w3.org (see this email for details).

Go ahead browser, make my day...

2009-01-30T10:40:00.007-05:00

This command (I use OS X) takes the patches in my mercurial queue (which I tend to name bug-#) and opens a browser tab for each.

hg qseries | sed 's/bug-/https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=/' | xargs open

There's probably 94 better ways to do that but meh, and barely blog worthy perhaps... but this way I'll have a record of the command for when I forget. And smart people can add comments showing me better ways :)

I guess having FF restore my session is a good one.

7 things

2009-01-24T09:32:00.007-05:00

I think Steve Lee was first to tag me with this fun 7 things meme.

My Seven

I lived most of my childhood on a family goat farm in rural Ontario, Canada. I loved fetching buckets of water for the goats and watching them drink deeply. One incredibly clever goat tried to murder me in various ways, but really it was sort of a Pink Panther - Cato relationship. Thankfully "Jody" was lousy at martial arts.
I now live in Toronto, a male in a house dominated by 3 strong women.
I'm a soccer player in the land of hockey.
The first computer I touched was one of the very first IBM PCs which my friends father had brought home from Geac. That night I lay awake thinking of that cool monochrome text glowing on the display. After a few years of selling farm-fresh free range chicken eggs my first computer was a Radio Shack CoCo2, and some 'older kid' I knew from the store gave me his old 6809 assembler programming cartridge. He had started dating. I saved my programs on cassette tape.
Yeah I was on the highschool programming team one year. Being the youngest, when we got our task list our leader gave me an easy one and I wrote out the algorithm on paper for when it came time to type it in (we shared one computer). We ran out of time working on the first task (the hardest). There is a lesson here somewhere.
My career plan was to build strategy based computer games until a guest lecturer introduced me to the world of accessibility technology.
I still have that country-boy trust in people.

The Rules

Link to your original tagger(s) and list these rules in your post.
Share seven facts about yourself in the post.
Tag seven people at the end of your post by leaving their names and the links to their blogs.
Let them know they’ve been tagged.

Passing it on, in no particular order:

Joining the Mozilla Accessibility Team

2009-01-10T20:12:00.004-05:00

For my readers, all 5 of you, I want you to know the rumors are truthy. The Mozilla Corporation has come to an arrangement with the ATRC that will allow me to spend some time focusing on helping Marco and Surkov with Firefox accessibility!

We're scattered nicely. Marco works in Germany, and Surkov in Siberia. I'm working out of Mozilla's Toronto office where, in one week, I've managed to spill shawarma juice on Beltzner's chair, ramble irrelevantly and incoherently to Jeff Muizelaar about C++ object layout compiler differences[1], and order the sandwich melt instead of the dry rub ribs at CGL. What was I thinking?

Things I've learned: some spouses do in fact let their husbands brew beer in the kitchen, seriousness combined with fun is serious fun, having an espresso machine in the office is genius, the world stops for women's five pin bowling, if an Olympian uses chemical enhancements then they should compete in an evening gown, and finally, I'm going to learn a lot. I'm used to working with smart people... but these guys are sick!

[1] My current bed time reading is "Inside the C++ Object Model" by Lippman. I wish I'd read this 12 years ago. I recommend it to anyone interested in C++ object layout, compiler optimizations and so on... fantastic... but my next book choice will be fiction.

ATRC ARIA efforts in 2008

2008-12-30T09:15:00.027-05:00

With funding from the Mozilla Foundation and IBM, in 2008 the ATRC continued to help communities add support for accessible DHTML using ARIA. This meant a whole whack of little things, including frequent emails and chats, and some other things, like code commits, testing infrastructure work, document editing, and committee work.

My primary role was to help make sure Web2.0 communities knew about ARIA, and to help them with any implementation work through what amounted to a mutual-mentorship. I'll discuss deliverables related to this evangelism-ish goal first, and then move on to some more specific community work. Then come back at the end with some brief thoughts on the evangelism aspect.

Initially and iteratively I worked with Aaron Leventhal on strategic ways to spread awareness of ARIA. At some point we realized developers needed a place to go for sample code, and hey, code talks, baby.

codetalks.org

We started to see additional people and communities providing great resources about ARIA. As specification and best practices work continued in the W3C, we realized it would be nice to provide a central hub for all the ARIA activity and evangelism that was happening "in the wild". Together this community created a 'vendor neutral' wiki: wiki.codetalks.org, as well as an svn code repository, and bug database. These sites are hosted by the ATRC, and we plan to continue hosting them as long as they are useful. Aaron created a free-aria google group for, not surprisingly, the free discussion of ARIA. Oh, by the way, any readers good with logo design?

W3C PFWG ARIA team

Given my prior work on Dojo Toolkit Accessibility, and my colleague Joseph Scheuhammer's work on the Fluid Project, we were invited to join the ARIA specification efforts as 'invited experts'. Our input to the discussions came primarily from actually trying things out, and our work on Dojo and jQuery.

DHTML Style Guide

The ATRC continues to attend and contribute to the DHTML Style Guide meetings which address keyboard bindings for DHTML widgets.

jQuery UI

A core contributor is leading the ARIA effort here, and I feel it is in good hands, with a decent community effort; so in a sense, "job done!" The community has not finished of course, but we've got a pretty clear roadmap ahead, and we've made some good progress. As a major redesign (in UI) moves forward so does the opportunity for further ARIA support. We've added the core ARIA support and it takes about a day or two to add ARIA support, with automated tests, to a jQuery UI 'plugin' (think 'widget' or 'component'). Adding polished keyboard interaction can take longer. The ATRC's Fluid Project team, having already worked through a lot of keyboard and navigation issues on top of jQuery, is now moving this know-how upstream and working with the jQuery UI community.

Dojo (Dijit)

We continued to work with the Dojo community on dijit, the mature and accessible widget set, with a focus toward helping sustainability. Joseph was our main resource for this work and initially focussed on grid widget keyboard accessibility (non-trivial) and spent a fair amount of time doing QA, including manual tests. Later he created automated UI tests using a robot currently found in Dojo's test harness: D.O.H. and has worked to move ARIA smarts into Dojo core.

ARIA Evangelism

One thing I've struggled with in the evangelism part of our grant is knowing when we are successful, or even when we are finished. Other browsers and toolkits are adding ARIA support, but how much did the ATRC help make that happen? Did we use the right amount of pressure? Did we help enough? I think we'll never know.

One thing I do know is that the Mozilla Foundation likes to seed activities that fit its wonderful manifesto/mission. I can say that in this respect the Foundation has been very successful here, and that the ATRC continues to pursue and win funding that will allow us to continue to focus efforts on open web accessibility now and into the future.

Finally, all this experience is helping me in my current gecko work!

Browser Accessibility Acid Test?

2008-12-17T09:47:00.005-05:00

We're on our way! Thanks to funding from the Mozilla Foundation, Eitan Isaacson has built a tool for comparing browser accessibility implementations. His latest post titled "Apples and Pairs" provides some examples of its usage.

Thank you Eitan!

My Wordle

2008-12-11T12:52:00.009-05:00

What should the alt text be? I think I give up...

Image made by http://www.wordle.net/

Indoor Positioning using Wifi

2008-11-26T15:39:00.007-05:00

Have you ever wanted to pull up a floorplan on your mobile device to help you find your way?

Jorge Silva, our mobile lead here at the ATRC, and students Jamon Camisso, and Yura Zenevich gave a lunch talk the other day to show off the state of their Wifi based indoor positioning system. It seems they have managed to get within 5 meter accuracy using existing WiFi points and some nifty statistical algorithms. Jamon is looking at how this technology might tie into geolocation efforts such as Mozilla's Geode. We'll also look at connecting with efforts in GNOME, AEGIS and other projects. Exciting stuff.

Here's the quick upload of the talk in five parts. Captions are coming, and apologies for the lighting.

This work is done as part of the SCYP project and like many innovations is coming from an accessibility angle. I think this work provides a nice foundation for all kinds of student engagement here at the University of Toronto and elsewhere.

Thanks for reading.

There's something about prototypal inheritance...

2008-11-21T22:31:00.015-05:00

Let's look at some JavaScript, and today I'll ask Crockford to pass the sugar:

Object.create = function (o) {
    function F() {}
    F.prototype = o;
    return new F();
};

Now let's create an object a, and a two objects b and c based on a.

var a = { name: "a" };
var b = Object.create(a);
var c = Object.create(a);
c.name = "c";

At this point both a and b have name "a", and c has a customized name "c". Now lets change a:a.name = "foo";Objects a and b now have name "foo", and c still gets to keep name "c" (a good language design decision methinks). Since a is just a mutable object we wield this sort of godly power to change or inject DNA. Every time I come back to it, it tickles me.

Using .attr for ARIA in jQuery UI

2008-11-09T13:42:00.007-05:00

Last week I found some time to hack on jQuery UI again. After talking to Scott we decided to pull the ariaRole, and ariaState API out of UI core, and put the browser normalization for ARIA right into the popular attr function where it belongs.

At this time, jQuery UI is a dependency for this enhanced attr function. We add the ARIA smarts in ui.core.js via proxy function, like this:

// proxy attr
var attr = $.attr;
$.attr = function () {
    // if aria usage then normalize
    // else
    attr.apply(arguments);
};

See the patch for the real deal. You might notice that we actually only proxy if a naughty browser/version is sniffed. Let's hope this ARIA normalization business won't grow too big and complex when the other browser ARIA implementations roll out. If we can keep it small and tight the attr enhancement really belongs in jQuery core. Or maybe it belongs there regardless? If you are doing Web2.0 development you're probably going to need it.

Here's an example of how one might use chaining to add the ARIA role of "tab" to all elements with a class "ui-accordion-header), and the ARIA state "aria-expanded=false", and add the ARIA role "tabpanel" to the next sibling of each (which happens to be the panels).

$(".ui-accordion-header")
    .attr('role','tab')
    .attr('aria-expanded','false')
    .next()
    .attr('role','tabpanel');

Working with Scott González and others on jQuery has been a very meaningful aspect of my Mozilla Foundation grant. Thanks Mozilla.

Thanks for reading.

Google Health with WAI-ARIA support!

2008-10-17T09:28:00.006-04:00

T.V. Raman reports the latest Google ARIA addition goes to Google Health. See also the related article in eWeek. It makes good business sense, and is a good move for many reasons.

Google's approach, of sending ARIA over the wire only when necessary, intrigues me, but I think there must be a better way of automating the decision. Are users comfortable setting "enable screenreader support" as a preference? It seems many people are generally concerned about giving away too much information about themselves...

T.V. lists the key-bindings for using this Web 2.0 application and they look like they gel with the DHTML Style Guide. Nice work Google.

The W3C draft specification: WAI-ARIA continues its emergence as the solution for providing Web2.0 experiences for everyone.

AEGIS! AEGIS! AEGIS!

2008-10-16T20:49:00.007-04:00

The AEGIS website is live.

Finally I can tell the world!!! This is that "big project" I've been waiting ages to talk about.

AEGIS stands for: (Open) Accessibility Everywhere: Groundwork, Infrastructure, Standards. Think third generation accessibility meets desktop, rich web, and mobile.

You'll start seeing lots of chatter soon on mailing lists, blogs etc. In a future post, I'll go into more detail about the role the ATRC will play as a Canadian partner in this important work.

Hmmm, I wonder if I'm allowed to use the logo in a blog...

WAI-ARIA evangelism, dojo, jQuery

2008-10-08T11:36:00.008-04:00

A portion of my time these days is spent evangelizing the Web2.0 accessibility solution: WAI-ARIA (for Accessible Rich Internet Applications). In 2007 I had a lot of fun working with Becky Gibson, Simon Bates, and others to make the dojo toolkit widgets (dijit) fully accessible with keyboard control, high contrast mode support, and ARIA semantics. In the end we ended up doing a most of the code, and the testing, ourselves. We knew even then this was not ideal and what is really needed is to make accessibility part of the core widget design and creation process. If not that, then at least to engage a few core dijit contributors, ones that have been around a while, and will stick around in the foreseeable future. Becky, and another colleague of mine, Joseph Scheuhammer continue the Dojo accessibility effort now. Dojo accessibility is still healthy.

Now it is 2008, and I'm onto a new project, with a role that essentially boils down to: help glue a viable ARIA ecosystem together -- connecting browser, toolkit, and AT (assistive technology) efforts. One piece of this puzzle is helping the jQuery community add ARIA semantics into jQuery UI. In this particular effort I am enjoying working with my colleague Michelle D'Souza who is also busy keeping the Fluid team engine running with her agile-fu. What is different this time is that we are trying our hardest not to dive in and write the code, and to avoid being perceived as the accessibility silver bullet.

Enter Scott González, respected jQuery UI contributor. In tackling ui.dialog we worked with Scott (and to a lesser extent Paul Bakaus), to add keyboard and ARIA support. With Scott's help we put some basic support for ARIA into ui.core, and added a role of "dialog", and aria-labelledby property that points to the dialog's title ID. This means that when focus goes to the dialog, a screen reader will announce that focus is in a dialog, and the user can query for the name of the dialog. Two function calls and we go from zero, to full accessibility. What is important here, is that Scott was keen to jump in on this work, and in the end he came away with an understanding of ARIA (and we came away with a better understanding of jQuery UI).

It would be relatively simple for us to go ahead and add ARIA semantics to the rest of jQuery UI, but we shouldn't. We absolutely must be patient and it is paying off. Scott is helping organize the jQuery ARIA effort, which is awesome! Equally awesome, the filament group is joining... but more on that later.

Thanks for reading.

IE8, ARIA, Quirks?

2008-09-30T10:18:00.011-04:00

Aaron revives an important issue in his recent post: Legacy defeats consistency in IE 8’s Web 2.0 accessibility effort.

Despite agreement that it would be great if web developers could have a consistent standard way of supporting WAI-ARIA, it looks like syntactically (at least) is out. Browser ARIA implementation (how events, semantics, and structure are exposed to platform API) consistency is yet to be determined. Thankfully there is a harmonization effort built around a shared wiki document: ARIA User Agent Implementors Guide. Please for the sake of all things good...

Aside: Currently "IE8 Standards Mode" is expected to be the "default mode", unless you add a meta tag: <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> or have a doctype that triggers quirks mode. What if you are building a DHTML widget library? What mode are you going to be in? What about mashups? More normalization... sigh... Does it always have to be this way?

Thanks for reading.

Moz@ATRC

2008-09-26T14:17:00.010-04:00

Several days ago Tim Riley, and Jono DiCarlo, both from MoCo visited our lab here at the ATRC. As a sort of swearing-in I took them to our services pod where they got to try out some assistive technology. I took a few pics, and decided to try out my free download of Comic Life for OS X. It is a visual tool that is incredibly intuitive and simple to use (but not very accessible I'm afraid).

The first few frames show Jono, and Tim with shiny dots on their foreheads. These dots are picked up by a camera resting on the top of the screen, and allow the operation of the mouse pointer via head movement. We hooked them up with the open source Dasher input software. I think they both got a kick out of trying this and other Assistive Technology. The last frame shows them meeting with more of my group at the University of Toronto, where we discussed QA, automated testing, and UI design in open source communities.

Thanks for reading.

Mozilla DevDays Toronto

2008-09-17T21:49:00.008-04:00

On Monday and Tuesday I attended the Mozilla DevDays Toronto event. This blog isn't so much about the content (which was video taped for later posting) as it is about the essence of my reaction to the event.

In a nutshell, Mozilla DevDays Toronto was extremely valuable to me. All the talks I attended were good, but as is so often the case, I found a lot of value in hallway conversations and breakout meetings. Asking key Mozilla people my half-baked questions in person miraculously ended in fully baked answers, with icing and sprinkles. I'm thinking half-baked questions have to be delivered in person. Mark Finkle thanks for the tips and demystifications about distinguishing XUL dom events, and about XPCOM wrapper decisions.

Day two's talks on automated testing were an awesome introduction to xpcshell, mochitests, chrome tests, asynchronous tests, and ref tests in Mozilla. Note there is an extension developer addon that has an xpcom-ready JavaScript shell (or you can use xpcshell from the command line if you build Firefox yourself).

It was great to see timr again, and to meet jono, mfinkle and others; faces to names as they say. (Tim and Jono ended up touring my workplace today, where we showed them Assistive Technology and chatted about Ux design, automated testing and QA. I'll post on that when I upload my pics off the camera.)

Let's not forget humph! Thanks Dave, I know these events take a lot of effort to pull off, and I want you to know that (at least from from my angle) you put on a high value event!

Thanks for reading.

[UPDATED to fix a name. Sorry!]

Capability

2008-09-11T21:34:00.004-04:00

On a recent thread over on wai-xtech, T.V. Raman brought up the notion of talking about capabilities instead of disabilities. I like this. I'm reminded of my old post which played with the definition of disability.

Furthermore, a request for adaptation should never have to be a statement about the physical individual. It should be a statement about a preference in context. I want captions when watching television with the volume down, and I want a ramp when pushing a stroller.

GWT ARIA News

2008-09-09T14:30:00.003-04:00

Alex Rudnick from the Google Web Toolkit Team has recently posted on the topic of ARIA and GWT 1.5. Specifically he states

To make applications built with GWT more easily accessible, we've added accessibility support to the GWT library by baking ARIA roles and states into our widgets

Great stuff. Not everything in the youthful ARIA ecosystem of browsers, desktop, and assistive technology is fully working; but we'll get there if we all work together.

Thanks for reading.

Join the free ARIA Community

2008-09-09T10:01:00.003-04:00

Aaron Leventhal has created a Google group: free-aria (reminder: ARIA is the technology for an accessible Web2.0). This is a great place for working discussions. Please read Aaron's related blog.

We really need people willing to help build and organize our test cases, as well as people with the skills to do the testing.

If you want to help but aren't sure how, feel free to email me.

Thanks for reading.

Google Chromer to join ARIA browser group

2008-09-08T22:08:00.009-04:00

Jonas Klink from Google will join the WAI-ARIA browser harmonization effort! This small and lean group, spearheaded by Aaron Leventhal currently meets weekly to discuss the details of how user agents should expose WAI-ARIA semantics and events to the desktop platform accessibility layer. We have representation from Firefox, Safari/WebKit, Chrome/WebKit, IE, and Opera; as well as some representation from JavaScript toolkit ARIA development (me).

The current work is focused on contributions to the ARIA User Agent Implementors Guide created by Aaron. This document captures practical implementation details based on the experiences of the Firefox accessibility developers in pioneering browser ARIA support.

Thanks for reading.

Planet Accessibility!!!

2008-09-05T10:23:00.004-04:00

"Blog feeds from the contributors of accessibility through technology."
http://www.planet-a11y.net/

Thanks Bryen Yunashko (suseROCKS), and Flavio Percoco Premoli (FlaPer87), for this fine contribution to our growing community!

Google's Browser?

2008-09-01T22:02:00.008-04:00

It seems Google has an open source browser project.

I believe this must be true because a comic strip on the web told me so. While I was reading this comic I wasn't sure what amazed me more, the interesting things I was learning about the technical design of Chrome (the Browser), or the fact that I was enjoying learning about the technical design of Chrome from comic characters.

Is Chrome accessible? Although there was a lot of information about V8, the JavaScript VM, the comic didn't tell me if it had WAI-ARIA support for JavaScript+DOM+CSS based web applications. I was really hoping to see a T.V. Raman, or Charles Chen comic character.

Seriously though, it sounds like the rendering is to be done by Webkit, so perhaps too, the exposure of ARIA semantics in the DOM to desktop Accessibility API will eventually come from Webkit. Of course Firefox has pioneered this stuff, but Aaron is helping the other browsers as much as he can. Today, ARIA is a crucial piece of pushing the web as an application platform.

Thanks for reading.

Scratch-ing an Itch

2008-07-24T13:32:00.005-04:00

I gave a talk a few hours ago at the inaugural Scratch conference at the MIT Media Lab. Having first used Scratch last week, and leaving for the airport at 4am this morning I found myself reflecting...

What am I doing?

The title of the talk is "Scratching All Itches Equally" and originally listed Gregory Rosmaita, Liddy Nevile, and Jutta Treviranus as speakers. Gregory and Jutta couldn't make it so I was asked to jump in.

Here is the description in the program guide:

A discussion of strategies for ensuring that Scratch is usable by all, whether one can see the screen, or use a pointing device or an on-screen keyboard. The goal of the panel is to discuss Scratch’s architectural framework to ensure that it is capable of communicating with operating system accessibility APIs, as well as platform-agnostic APIs, such as IAccessible2 and ATK/AT-SPI (Assistive ToolKit/Assistive Technology Service Provider Interface).

Liddy and I realized that the audience was going to be made up mostly of teachers so we decided to turn the talk into less of an engineering discussion, and more of a brainstorm. We framed the storm in the context of Scratch, and accessibility, or disability in the wide definition.

Over lunch, it was cool to hear people from our talk bringing up topics from our brainstorming to groups who hadn't attended.

What interests me most about Scratch is that it is playful programming that kids (well, not just kids) can pick up rather accidentally in order create and express their ideas. It makes a lot of sense to me that this kind of tool should be made accessible to all children, regardless of culture, gender, or physics. When you only allow a subset of people to participate in creating and making, you lose some of the most valuable and insightful influences; you stagnate.

Thanks for reading.

GOK Maintainership

2008-07-21T11:07:00.002-04:00

Here's my recent post to gnome-accessibility-list@gnome.org:

Gerd Kohlberger has accepted the honour and responsibility of helping maintain GOK, the GNOME suite of on-screen keyboards that, among other things, provides access to the entire GNOME desktop via a single switch.

Gerd has already proven himself in the GOK codebase, is a skillful and thoughtful developer, and I think is the right person to help meet the challenges of maintaining a venerable C program beyond its 7th year. I'm hugely thrilled to have his help!

With the help of others that have emerged in the GOK community recently, these are happy days for GOK. A huge shout out to the helpful people who meet regularly in #a11y. THANKS!

This feels good. Thanks for reading.

FF3 is for everyone!

2008-06-18T14:14:00.004-04:00

Yesterday Firefox 3 was released. Congratulations to the entire Mozilla community! I'd like to give a special thanks to Aaron Leventhal, and Marco Zehe who have led the work to make this the most currently accessible browser ever, including bleeding edge support for Web2.0 Accessibility through the ARIA draft standard. Kudos also to the extended Mozilla accessibility community. Outstanding work!

FYI: I switched yesterday from being a minefield user to a FF3 release user, but am still using my minefield profile. So far so good; all my developer add-ons seem to be working as expected.

Thanks for reading.

jQuery UI 1.5 released!

2008-06-09T16:03:00.003-04:00

Congratulations to the jQuery UI community on this important milestone (see Paul's post). I'm really excited about the next major milestone being being fully accessible with WAI-ARIA semantics! We'll be chatting with Paul this week about getting this ball rolling again. Anyone who is interested in helping out, please watch (y)our jQuery Accessibility (Google Group). Good things coming.

Intel Core2 Extreme 3Ghz

2008-06-09T15:24:00.003-04:00

That's right baby... on my desk this morning in the form of a Sun Microsystems Ultra 24! I'm sort of slack-jawed at the awesomeness. I'm thinking I'll configure it for a dual boot with OpenSolaris, and either Ubuntu, or Fedora.

"Code Talks"

2008-05-30T10:28:00.003-04:00

If you build it will they come?

http://wiki.codetalks.org/

We need a new logo.
We need authors.
We need advice on organizing the wiki.
We need to figure out what we want this wiki to be.
We includes you.

Thoughts?

W3C internal ARIA drafts now public

2008-05-29T15:18:00.010-04:00

In April I joined the Protocols and Formats Working Group (PFWG) at the W3C as an "invited expert". In joining I gained access to the internal ARIA drafts. I'm pleased to participate and am particularly happy with our recent decision to go public with our internal drafts: WAI-ARIA, and the WAI-ARIA Roadmap.

But... these are not like the regular public drafts, so please be sure to look for disclaimers as noted in this email: Updated WAI-ARIA Editors' Drafts Now Publicly Available.

Now, let's all get ARIA 1.0 wrapped up soon!

Thanks for reading.

Accessible Web Interactivity Today!

2008-05-22T23:59:00.007-04:00

You can use ARIA to make your DHTML accessible today.

I'm still seeing discussion about old techniques for JavaScript accessibility without any reference to the new draft WAI-ARIA specification and best practices guide. I find this alarming, and I can only conclude we need to do a better job at getting the word out.

WAI-ARIA provides a way to give semantic meaning to the DOM nodes which make up your DHTML user interface. Add ARIA role, property and state information appropriately and your DHTML widgets become accessible to assistive technology such as screen readers, and your whizbang Web2.0 application can reach that many more people. It is just good business sense.

The main browsers and JavaScript toolkits are adding support for ARIA. Let's move forward!

What is this thing we call "design"?

2008-05-20T22:25:00.006-04:00

Today I attended a lecture by Nigel Cross titled, "Designerly Ways of Knowing: Understanding how Designers Think and Work".

For me, the "take home" stuff came near the end when Nigel juxtaposed his analyses of conventional problem solvers, and great designers. Here are my notes:

Conventional problem solvers:

tackle the problem in the 'easiest' way
accept the problem rules
adopt standard problem representations
re-use previous solutions

Expert designers:

tackle the problem in a 'difficult' way
challenge the problem rules
construct novel problem representations
create new solutions from first principles

Where do you fit in?

Mozilla and Accessibility

2008-05-16T21:51:00.004-04:00

Aaron Leventhal has started a thread called: "Mozilla accessibility -- collecting stories & dreams". If you'd like to read what folks say about the Mozilla Foundation and its relentless commitment to keeping the internet a place for everyone, check it out.

Safari/WebKit Accessibility News

2008-04-30T20:30:00.008-04:00

Progress!

Keyboard: It looks like we're getting that much needed DHTML/Ajax keyboard support for Safari/WebKit. Thanks go to Alice Liu et al. for making it possible for us to set tabindex on any DOM element. [bug 7138]

ARIA: WebKit has also joined Firefox2+, Opera9.5+, and IE8 in adding support for WAI-ARIA, the W3C draft specification for making DHTML (Ajax) accessible. Thanks go to Beth Dakin et al. for the initial implementation of basic ARIA roles. [bug 12132]

In related news, I had a nice chat with Alp Toker late this afternoon over on #a11y (irc.gimp.net). He's going to donate time to help drive the work on the Linux accessibility atk/at-spi backend for WebKit. Alp is a WebKit/GTK+ ninja so this is outstanding.

I appreciate the heads up today Maciej.

Thanks for reading.

Firebug 1.2 alpha on FF3

2008-04-25T13:24:00.008-04:00

Updated:
Someone kindly told me that I had a stale firebug! Go here for the latest.

I recently managed to get an alpha firebug (1.2.0a7x) working well on FF3 by also installing the Web Developer add-on and restarting. I've confirmed that this workaround also helped a colleague (using a more recent 1.2.0a22x of firebug). The workaround doesn't appear necessary for 1.2.0a23x. In other words, this post is obsolete. Sorry for the interruption.

Thanks for reading.

GNOME A11y Meeting Summary

2008-04-22T10:38:00.005-04:00

Here is my summary of our weekly GNOME accessibility meeting:

We briefly discussed the pointer grab issue. Can we deprecate XGrabPointer? Frafu and I are to discuss and take this up with the X people if it makes sense. Frafu will likely carry this torch.

We may be getting another evince task proposal.

We also discussed how to organize the meetings moving forward. During the meeting we will: do GOPA status updates, spend a few minutes to meet any new folks on the channel, and finally, discuss a 'hot topic' in GNOME accessibility.

Where: #a11y (gnome irc)
When: Mondays 9:30am EST (13:30 UTC)

Thanks for reading.

Weekly GNOME GOPA meetings!

2008-04-11T14:55:00.007-04:00

Our plan is to meet weekly to discuss GNOME accessibility tasks and share witty remarks. Please join us if you are good at either. There is still lots of work (and money) to share!

Where: #a11y (gnome irc)
When: Mondays 9:30am EST (13:30 UTC)

We met yesterday and ended up discussing magnification. I look forward to seeing Kristian post to the gnome-accessibility-list again about possible magnification work. It would be great to move forward in this area soon.

Go GOPA!

Safari Accessibility

2008-04-02T16:48:00.004-04:00

There is a conversation happening about Safari (and WebKit) Accessibility. It all started with a post to GNOME desktop developer list from Maciej Stachowiak. I added the Mozilla Accessibility list in the cc of my reply.

We all seem to be mostly agreeing, I think...

dojo svn notes

2008-03-31T11:26:00.005-04:00

Late last week the dojo committer svn URL moved and it was fairly straightforward to update my Eclipse settings. I had a clean sandbox so I just blew it away, then went to the SVN Repository perspective, added "https://svn.dojotoolkit.org/view/committer" as a repos, browsed to all/trunk and checked out as a project named dojo-trunk.

I learned there is an svn switch command for changing the prefix for all the URLs in a sandbox instance which would have been good if I had uncommitted local changes.

Aside: I use my macports svn client from a shell for creating patches as it strips the irrelevant directory prefixes.

Uniquely identifying chunks of UI

2008-03-20T12:33:00.006-04:00

To follow up my last post, ARIA's templateid allows a finer grained customization than what Greasemonkeys, JAWS scripters, Orca scripters and others might be used to.

Normally AT customization happens based on which application currently has focus, and in the case of browsers, which URL is currently loaded. Now we can go inside the document.

We can mark a piece of our UI like this:

<div aria-templateid="abc123.org/FooComponent_v1">
    <!-- embedded FooComponent_v1 -->
</div>

Here's how I imagine it will work: when focus moves within this div, the user agent notices this and fires a platform accessibility event. This event ultimately notifies, for example, a screen reader which then checks for a customization script for FooComponent_v1. This script might offer keyboard operation enhancements, instructions on how to work with a FooComponent_v1 or anything else really.

Like many innovations at the edge, I suspect this will empower exciting and perhaps unintended use cases.

Note: there is discussion about renaming templateid for the final ARIA specification. It is fascinating witnessing the web push the boundaries of how we conceptualize an "application", "module", "component", or "widget".

Thanks for reading.

aria-templateid explained

2008-03-18T21:35:00.012-04:00

PLEASE NOTE: some time after this post, aria-templateid was removed from the draft specification by the W3C.

I wondered when an aria-templateid might be used so I asked Richard Schwerdtfeger.

Rich enlightened me using Gmail as an example, whereby Google could define a unique template ID URL such as:

aria-templateid="google.com/gmail".

Whenever an assistive technology (AT) sees this template ID it can provide customization to improve the UX. For example, a screen reader like JAWS or Orca could load a script for adding keystrokes to open the Gmail inbox etc. If another web product embeds Gmail the AT can still pick up the the template id and apply some customization.

Thanks Rich. This rocks.

Maybe what's most cool about aria-templateid is that we can think about tackling web accessibility in innovative new ways via customization.

Could we now essentially "Greasemonkey" the interactive DHTML web space, including mashups, for accessibility? I'll try to post my thoughts on this in the near future.

Well, that's enough for now. Thanks for reading.

Debugging JavaScript evals

2008-03-18T12:58:00.006-04:00

Note to self... when debugging dojo in firefox... always check the script option: "Show eval() sources" in firebug.

You might need to check this after updating minefield and/or firebug.

Thanks for the reminder today Becky.

CSUN 2008 - my regrets

2008-03-17T16:17:00.002-04:00

Sorry to everyone who missed me at CSUN this year. Life got in the way. Next year for sure!

Do bug references taint code readability?

2008-03-17T11:19:00.012-04:00

Sometimes we write code that looks slightly odd or unpleasant, but it works around (or fixes) a bug, a bug which otherwise is perhaps beyond our control (e.g. some interaction issue with a closed source tool). We write the code as best we can to make it self documenting, perhaps adding a short comment to describe why the workaround exists. We write an automated test to protect against regressions. We refer to the bug # in the tests for easier forensics should things go awry. We are fashionable.

Yet we are still worried about someone coming along and shredding our unpleasant fix, forgetting about the regression tests, and reintroducing the bug.

Refer to a bug number in a source code comment?

How fasionable is that? I've googled but couldn't find much on the topic. I've seen it done quite a bit in the Mozilla codebase, and I'm inclined to think it has merit in some cases. I wonder what others think.

Anyway... this blog was inspired by a dojo meeting a few months ago. I let it sit unpublished for a while... until a time when I'm mentally exhausted and just don't care what blatherings I post...

Thanks for reading.

ARIA-ized Google Reader

2008-03-12T21:10:00.004-04:00

Yes! Nice work T.V. and Charles!

Don't read this. Read the Official Google blog: ARIA For Google Reader: In praise of timely information access

Hmmm. I'd like to see more about how to best use AxsJAX for prototyping. Did you guys find getting things to work using AxsJAX and FireVOX covered things quite well? Or did you then find it a lot more work to get things to sound right with JFW and WE? I haven't really played with AxsJAX much but maybe I should?

Go Google Accessibility!

ARIA on Webkit's R(a)dar?

2008-03-12T21:09:00.008-04:00

What does this mean: "rdar://problem/5785134"?

It appeared recently in a comment on the WebKit ARIA bug.

If it is an internal Apple thing how do we keep informed on the status? Tackling this bug would be a great contribution!

Be sure to check out: ARIA UA Best Practices by Aaron Leventhal.

Personalized UI Generation

2008-03-11T13:45:00.014-04:00

Working on campus has its benefits.

On Tuesday I attended a talk by Krzysztof Gajos titled: "Automatically Generating Personalized Adaptive User Interfaces". It was nice to see some solid research being done in this area with particular attention to users who have a motor/dexterity impairment. Here are some of my notes which of course may have wild inaccuracies.

Krzysztof seems to have applied theory in mathematics and algorithms, particularly "decision theoretic optimization" to graphical user interfaces. I'm not talking about Fitt's law. Think: AI meets HCI.

For his problem space he considers 3 things to adapt the GUI to:
1. devices
2. preferences
3. abilities

And things to adapt, or "UI building blocks":
A. Layout
B. Widget
C. Structure
D. Size (this last one he added later in his research)

The context seemed to be mouse based interaction in graphical user interfaces.

Treating GUI design as an optimization problem he developed quantitative metrics and a cost function, essentially with weights to be applied to widgets. For those with an AI background his bag of tricks included: branch-and-bound search and full constraint propagation. The "cost" function I think of as a "utility" function (common in game decision AI). Oh and perhaps most wonderful to hear him say was that "deep down it is a constraint satisfaction problem". Yes! I'm sort of known for saying a lot of things boil down to a constraint satisfaction problem and some of my colleagues would have a good laugh about this I think. Anyways, this isn't about me and I've lost track of what this paragraph is for.

He spoke of the geometric concepts that arise from considering each UI preference an axis in a multidimensional space, and that each preference of one UI element over another is a hyper-plane in that space. Overall the 'shape' of the solution space of elements that solve the preference criteria is a polytope. Way cool stuff to think about at a high level.

He mentioned four elements of UI Design:
a. Perceived effort
b. Cognitive effort
c. Motor effort
d. Aesthetics

In analyzing ability, or motor effort, he optimized for time as opposed to preference:
cost(rendering(UI)) = time

So what did I take away?

1. People without mobility impairments found the time optimized generated GUI ugly.
2. Everyone was more performant using their generated time optimized GUI.
3. Krzysztof is someone to watch.
4. The biggest gain in performance was using a widget or widget set that required less mousery to manipulate, for example: a set of 5 radio buttons, instead of a combo box with 5 options.

Krzysztof really made his algorithms quick and it was interesting to see a demo of UI changing dramatically as he changed a constraint, such as screen size. The widgets, and widget hierarchy changed on-the-fly, for example, widget groups became tab panels in an auto-generated tab container.

But no spinning angry face. Sorry... inside joke.

Thanks for reading.

IE8 embraces ARIA! and... extends?

2008-03-07T14:47:00.007-05:00

Finally making time to post some thoughts about this.

Wow! Thank you Microsoft. Now we have FF, Opera, and IE8 as platforms for accessible web2.0 applications. Notice any browser missing? (See end)

Don't read it please, but the MSDN has an article about support for ARIA markup in IE8.

Now, this is awesome, but... As Anne van Kesteren points out the good news is tainted by the non standard way ARIA information can be accessed in IE's DOM. I'm not going to give an example here since I don't want to accidentally promote potential IE only accessibility syntax where cross platform syntax exists.

We're on the case and are hopeful IE8 will change the docs to promote cross browser accessible DHMTL development (the setAttribute/getAttribute way).

More convenient access can always be provided in the various JavaScript toolkits (or not), but we just need to make sure the IE only way is not spread around in any ARIA educational material. Including the MSDN.

WebKit where is your ARIA support? My nagging continues.

[Updated MSDN link]

ARIA News: Marco's Tips, jQuery, dojo

2008-02-29T09:48:00.007-05:00

Marco has begun his promised blog series on ARIA tips! Marco, a bright new Mozilla employee is someone to listen to; he's close to the metal with respect to making accessibility work and is respected in the accessibility community.

If you are a DHTML developer you must subscribe to Marco's blog; or perish.

Oh by the way it is about time I did some other name drops. Colin Clark and I are going to be talking to John Resig and Paul Bakaus on Monday to see how we can help their community make jQuery UI rock even more with ARIA and other goodies.

We (at the ATRC) continue to help the dijit community add polish to the dojo toolkit's solid ARIA and keyboard implementation.

ARIA support is growing.

GNOME Accessibility Grants!

2008-02-27T10:17:00.001-05:00

Do you care about free software and feel that the functionality it provides should be available to everyone? Do you want to be welcomed into a fantastic community of nice people doing innovative and creative work? Want to help make the GNOME desktop usable by everyone? Want to solve difficult technical problems? Or to write documentation? Would you like some money? Can you get the job done?

More info: http://www.gnome.org/projects/outreach/a11y/

Press release: http://www.gnome.org/press/releases/gop-a11y.html

Uncle Willie needs you!

Revival

2008-02-23T12:32:00.010-05:00

I'm officially back to work now, and will be on campus at the ATRC Research and Development Lab Monday, February 25th.

For now, the bulk of my time will be mentoring and hacking on JavaScript accessibility in both dojo and jQuery; with some time reserved for our mobile applications project, and, of course, GNOME!

Riley is seven weeks old and smiling, sometimes.

Orca a-Live Regions

2008-01-29T14:55:00.000-05:00

The Orca and Firefox accessibility folks have being working hard together to bring the dynamic web to users who don't use a visual display. Today Scott Haeger announced that Orca 2.21.90 includes ARIA Live region support!

Congratulations, and thanks for all the hard work!

Where is David?

2008-01-26T14:58:00.000-05:00

I've had enough requests to prompt this somewhat rare personal post. My second child, another healthy girl, Riley, was born January 6th of this month!

I feel so lucky, thrilled, and tired.

I've saved up some holiday time and will continue to focus on my family until the second half of February. High priority community work that I'm involved with will continue to get enough attention that I'm not a bottleneck, but pretty much everything else is on the backburner. Thanks for your patience.

And thanks for reading.

Red Hat and GNOME Accessibility?

2007-12-21T10:40:00.000-05:00

Oddly, it is a message from Matthew Szulik as he leaves the role of CEO and President of Red Hat that renews my hope that Red Hat takes accessibility seriously. Why?

In reading that it is important at Red Hat to "seek out those who believe that for any democracy to continue, free and unfettered access to information is an unassailable condition for advancement", I'm struck by the term "unfettered", where I take the term to mean accessible and without barriers.

Please tell me that's what he mean't. Please tell me the new CEO and President, Jim Whitehurst will make that a company directive. I think with that directive in hand, Jonathan Blandford and the desktop team could really make a brilliant impact in GNOME accessibility. With the community looking at an accessibility infrastructure refactor, the timing is right.

Sun Microsystems, having laid the GNOME accessibility foundation, are still chugging away with the classy ORCA screen reader, and helping support GOK maintenance; as well as strategic thinking.

IBM, no longer directly involved in Linux accessibility are still involved peripherally, and are tackling accessibility on many fronts.

Ubuntu has seemed to "get it" from day one. Bravo!

The Mozilla Foundation continues to provide vital seed funding for GNOME accessibility work, bringing in great talent to work on gaps.

Novell seems to understand the importance of this and are putting resources behind it.

I'm sure I'm missing some obvious ones; please leave a comment and let me know.

Exciting times! Thanks for reading.

[Edited to fix name of company! Thanks David Z.]

Invigorating GNOME Accessibility

2007-12-17T20:38:00.000-05:00

Teaser: something really cool is coming next year.

A few days ago Behdad gathered some of us GNOME accessibility folks together on IRC to brainstorm which he then summarized and reported back to the board.

Today Brian Cameron posted to the GNOME accessibility list with the subject: "Forming an Accessibility Steering Committee". If you are passionate about accessibility and feel you have the experience and time why don't throw your name in the hat? I imagine one of the things that the committee will help steer is (I'm whispering now...) the cool thing coming next year, but that is only a piece of puzzle.

I don't know what has gotten into Behdad lately but he is definitely helping bring people together around accessibility.

Great job!

Be careful with "this"!

2007-11-29T10:06:00.000-05:00

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

2007-11-27T22:57:00.000-05:00

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

2007-11-24T20:59:00.000-05:00

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++

2007-11-22T16:41:00.000-05:00

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

2007-11-21T20:39:00.000-05:00

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

2007-11-20T14:48:00.000-05:00

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

2007-11-19T13:35:00.000-05:00

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!

2007-11-05T09:59:00.000-05:00

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!

FSOSS 2007 (part 2)

2007-10-27T18:25:00.000-04:00

Wow. The Free Software & Open Source Symposium (FSOSS) sure attracts some interesting people.

I enjoyed all the talks I attended but I want to specifically mention David Eaves' presentation titled "Community Management as Open Source's Core Competency" where he took a critical look at communication and negotiation in open source communities. It was just great. I also enjoyed the colourful session which followed, by Jesse Hirsh, "The Problem with Open Source: Know Your History". During both of these talks I found it refreshing to stand back and take a critical look at the open source communities. I am sorry to have missed the related BOF, but I had a lunch date with Frank Hecker from the Mozilla Foundation to discuss accessibility and to blue sky for a bit; which I thoroughly enjoyed.

Anyways I feel honoured to have been invited by David Humphrey to give a talk on Accessible DHTML, which I had more teasingly titled "Accessible Rich Internet Applications". Simon Bates and I co-presented on Friday and discussed and demonstrated keyboard control, ARIA semantics, and other bits related to our Dojo toolkit work. I think Simon's iterative coding demo showed that adding keyboard and semantics to DHTML is not that difficult, but is undeniably important; which was our main goal.

For those interested, Simon has provided the slides and source code on his site.

Building Firefox with Accessibility on OS X

2007-10-15T13:39:00.000-04:00

I wanted to check out Minefield on Mac OS X so I went about doing what I do in my Ubuntu virtual machine. I ran into a few snags that were a result of my own silliness. Once I created a clean profile and ran Firefox the right way on Mac it was all good. Here's a rough log of what I did:


cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/client.mk
cd mozilla
make -f client.mk checkout MOZ_CO_PROJECT=browser
cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/browser/config/mozconfig

I created a .mozconfig file with debug options:

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-debug
mk_add_options MOZ_CO_PROJECT=browser
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --enable-accessibility

Then I installed some mac ports as suggested by the Mozilla docs.

sudo port selfupdate
sudo port install libidl
* this installed glib-2.14.1 for me
sudo port install autoconf213
make -f client.mk build MOZ_CURRENT_PROJECT=browser

Running ff-debug/dist/bin/firefox crashed so I got onto #developers and Colin Barrett (cbarrett) helped me out. I asked him if my FF2 addons could be interfereing and he suggested I create a clean profile. I forgot about this, arrg. After creating a clean profile ff-debug/dist/bin/firefox ran!
Still no apple menu though a bit more chatting and Colin mentioned I need to run the the Mac way: dist/MinefieldDebug.app/Contents/MacOS/firefox

Woohoo! VoiceOver is sorta working too, I just have to figure out why it reports Firefox is busy sometimes when it doesn't appear busy. I think Håkan Waara warned me about this.

Mozilla and GNOME Summits

2007-10-09T13:50:00.000-04:00

I wasn't able to attend this year's Boston summits for Mozilla Accessibility and GNOME. If you know me, you know this was painful to miss and I'm sorry I was not able to blog about it for others who couldn't make it this year. Fortunately Steve Lee has blogged about it on a sleepy train ride back home.

Debugging Dojo

2007-10-03T10:15:00.001-04:00

I'm a firebug fan so I use fireclipse. It is basically firebug with support for debugging into eval() expressions. It is quite impressive considering SpiderMonkey is not designed to support easy debugging of eval(). If you are curious about the bug I recommend reading John Barten's great description of the problem. I'm not sure when that might get resolved.

In the meantime, I'm grateful for fireclipse.

FSOSS 2007

2007-09-19T21:46:00.000-04:00

The Sixth Annual Free Software and Open Source Symposium will be held on October 25th and 26th in Toronto Canada again and registration is open. That's only about five weeks away! I really have to send Dave Humphrey my talk title soon... as soon as I decide exactly what I'm going to talk about. Well we know it will be related to accessibility.

Dojo: DOM events and consistent UX?

2007-06-16T21:50:00.000-04:00

I recently posted on this topic to the public dojo/dijit forums but am now casting it to the blogosphere in hope of synergistic bliss (AKA "readers correcting my misunderstandings").

User interaction with a dijit is enabled by our listening for events such as:
1. click
2. mousedown
3. mouseup
4. keypress (fixed/normalized in dojo/_base/event.js)
5. etc.

The interesting thing about click is that it is abstract and device agnostic. For example an html checkbox onclick will be called under the following conditions:

On Firefox, space key up, and left mouse button up.
On Webkit, space key down, left mouse button up.
On IE7, space key up, left mouse buttion up.

In an onclick handler we don't know and presumably are not supposed to care what caused the event.

Right now, in dijit, we have a mixture of device agnostic handling (via onclick), and device speciifc handling (via onmouse__ and onkey__). This means we can't reasonably provide UI/Ux consistency of control.

Note to self: one thing I need to check out is the status of (on)click support for all elements via keyboard and mouse.

In other words, sometimes a user might activate something by pressing space, and another time, on another dijit, by releasing space. This can lead to dangerous things like stray events activating unsuspecting buttons (see related dojo ticket:3281, and firefox bug:384601).

What can we do about this?

Simon and I have discussed this a bit yesterday and have some ideas, such as rewriting/normalizing click if necessar, and perhaps enabling it for nodes the browser implementation might not.

[I've edited this post slightly since the original]

Ken Saunders - Mozilla Volunteer

2007-06-11T17:00:00.000-04:00

Ken is the project manager for the Access Firefox website. This site is an incredible resource for people from the accessibility and disability communities. It provides information on the accessibility features of Firefox, and suggests optional extensions that provide even more options over the way you can interact with the web. In his words:

"The information here will point you to the tools that will help you to get the most of using the Internet. Because of Firefox and its accessibility features, the time that I spend surfing the Internet is more fun and productive again."

Like many of us who are drawn to Mozilla, he believes in a free and open internet.

Oh by the way, Ken is also a graphic artist and happens to be legally blind. I like his icons; here's an example:

Call to Arms: Free and Accessible Desktop

2007-06-01T15:08:00.001-04:00

Our free and accessible desktop needs help.

It appears IBM will no longer have employees working on native Linux accessibility. I really don't know if this says anything about how Linux fits into IBM's corporate strategy, or if it is more about of the huge importance and focus on Internet accessibility (above the desktop). It might just be a case of too "many irons in the fire". I am pleased to hear IBM will continue to do important work in open source and accessibility.

Still... sadness.

I hope Sun can continue the great work they do in this area but it is a heavy torch to carry. There is a lot of work and I'd like to see more from the distros and other companies that understand that the future is open and that it is for everyone.

See Peter Parente's email to some linux accessibility lists. Peter intends to continue his important contributions off-the-clock. I hope he can. Note he lists a number of projects that may be affected: Accerciser, pyatspi, LSR (at least the current GNOME incantation), Linux Accessibility on the Firefox and the Mozilla platform, AT-SPI Collections.

See also, Rich Schwertfeger's blog post.

Dojo Developer Day (3DNY)

2007-05-05T09:22:00.000-04:00

First, let me just say "use dojo 0.9 or greater!" It is API incompatible with 0.4.X but it is the future of dojo. It is leaner, quicker, and... well... better.

OK, I know this blog is a bit shoddy and doesn't flow... but our schedule is really tight and I shouldn't be spending much time blogging.

Simon and I flew into New York Friday morning, sped over to the Manhattan IBM building in a cab, and after setting off alarms, getting our badges, and waiting around, Alex Russell showed up and let us in. We were just in time for introductions where I learned about people's giant pet cats, failed music bands, and other secrets. It was basically a big getting-to-know-each-other, followed by break out sessions. After lunch we really started to make some progress getting a picture of dijit status and planning for 0.9 beta.

The evening started at ESPN Zone, a sports bar in Madison Square, and then a handful of us proceeded to the Belmont, a lounge in Union Square. I am a beer guy, but still I highly recommend the passion fruit mohito.

Saturday was much the same but included more people using (not just contributing to) dojo toolkit.

See also Alex Russell's blog: 3DNY Wrapup

...and Flickr pics from Alex and others.

FLUID

2007-04-19T16:02:00.000-04:00

Today I attended, in an advisory capacity, a day long meeting to launch the Fluid project. The core architecture is being designed here at the ATRC, which is located at the University of Toronto; but there are many partners including other Universities as well as industrial partners and other projects. What is Fluid? The website has this text:

"The FLUID project will create a user interface architecture that enables the creation and consistent use of modular, reusable, and swappable user interface components. The project will develop a living library of robust, usable, accessible UI components, which can be reused across applications, contributed to, and evolved by the community."

I think the components will be DHTML based. Fluid will investigate and hopefully be able to choose an exisiting Javascript GUI toolkit to build on.

There were about 17 of us at the face-to-face meeting and it went very well. Most time was spent on the topic of governance which is so important to get right early (see a related blog:Handling Disagreements in Open Collaborative Projects by Frank Hecker)

It was a great first meeting.

IMG onload reassignment

2007-04-18T19:43:00.000-04:00

Hacking on a dojo dijit widget today I came across some strange behaviour that only seemed to happen in IE. Turns out the reassignment of an image node's onload was causing the new onload hander to fire. Here's the code that reassigns onload:

img.onload = function(){ self.onImageLoad(); }

IE is not open source so I can't diagnose exactly why the onload fires when reassigned. I worked around it by making sure that the premature firing would not be harmful.

Aaron Anderson and XUL Accessibility

2007-04-10T16:49:00.000-04:00

Aaron co-founded www.xulplanet.com.

He joined WebAIM about two years ago, and last Fall began a xul accessibility project funded by the Mozilla Foundation. His project has recently concluded, and produced the XUL Accessibility Guidelines and a XUL Accessibility Tool. The guidelines help XUL developers write accessible code, and the tool provides a report on the accessibility of XUL files.

Aaron also keeps a blog.

planet.gnome.org

2007-04-05T11:46:00.000-04:00

I'm here! Thanks jdub.

HTML inputs, MVC, changing the view

2007-04-04T16:58:00.000-04:00

I did some exploration recently into how one might take advantage of built in (browser) form input widget "model" and "control", while providing a different "view".

Some approaches:
1. transparent overlay test, are mouse and keyboard events captured by the invisible overlay? ...not in IE.
2. off screen test, html radio buttons are to the left and above the browser client area (works but might have accessibility issues).

Note code quality is exploratory.

Charles L. Chen

2007-04-02T21:51:00.000-04:00

Charles L. Chen is in the US working on the Fire Vox and CLiCk, Speak extensions for Firefox.

Fire Vox is a screen reading extension for Firefox. It has features not commonly found in commercial screen readers, such as built-in support for MathML, CSS 3 speech properties, and WAI-ARIA Live Regions.

Unlike Fire Vox which is designed for visually impaired users, CLiCk, Speak is designed for sighted users who want text-to-speech functionality. It has a simple, mouse driven interface that is designed to be easy for users familiar with point-and-click graphical user interfaces.

Charles recently created test cases of accessible AJAX live regions by using the WAI-ARIA live region markup. This work was funded by the Mozilla Foundation.

In his spare time, Charles likes to help out Knowbility.

Gijs Kruitbosch and ChatZilla

2007-03-31T18:35:00.000-04:00

Gijs is a 19-year-old student from the University of Amsterdam, where he's halfway through a B.Sc. in Artificial Intelligence. He has been involved in the Mozilla community since his first patch in November 2004. Within Mozilla, Gijs mostly works on ChatZilla (the Mozilla IRC client). Last summer, he participated as a student in Google's Summer of Code and recently he started working on a project funded by the Mozilla Foundation to make ChatZilla accessible.

He drank a lot of Sprite at CSUN this year.

Steve Lee and Jambu

2007-03-30T14:40:00.000-04:00

Steve Lee is in the UK working on Jambu, a software project funded by the Mozilla Foundation. The goal is to provide first class support for users of alternative input devices such as switches. The tool will use XULRunner, a runtime for supporting XUL applications on the same platforms you find Firefox and Thunderbird. Steve, actively promotes open standards and open source with an emphasis on accessibility, assistive technology and education.

Steve also keeps a blog and hacks on music.

The 'onchange' event

2007-03-29T23:19:00.000-04:00

My recent dojo work has led me to exploring JavaScript event reassignment and specifically to the intricacies of the onchange event of html input elements.

The HTML 4.01 Specification says this about the onchange event:

"The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus. This attribute applies to the following elements: INPUT, SELECT, and TEXTAREA."

Okay. Well currently Firefox doesn't follow this (at least for radio buttons), but instead does something outrageous; it fires an onchange event if something changes, for example, if the radio button checked state changes. (Although I hear it "correctly" fires onchange for a text input only when it loses focus; perhaps to avoid the event noise that would occur during text entry).

Sarcasm aside, I imagine there are good reasons for the HTML Specification but I can't help but think, at least in the post submit-page-refresh model of web development, that we could stand to have a more immediate onchange event, perhaps called onvaluechange?

Some hacky vanilla test code is in my exploratory. Yes, I've taken a liking to using the word exploratory as a noun.

CSUNzilla part 2: Impressions

2007-03-26T13:41:00.000-04:00

Mozilla rocked CSUN last week.

In this post I hope to share a little of what I experienced at the conference. I will be blogging a little over the next few weeks about what people in the extended Mozilla accessibility community are doing. For now, I'll give a brief sampling of the event as it might relate to Mozilla.

The Mozilla Foundation reserved a room for meetings, group hacking, and demos. This was a brilliant success, and the fact that this room was shared with others, such as the Linux accessibility folks, gave the CSUN community a taste of what Mozilla is all about.

Tim Riley from Mozilla Corp. helped staff the booth, and in the hacking room he gave a talk about the role QA plays at MoCo. I was able to share a few meals with Tim where I learned more about the Mozilla developer culture and the way testing techniques can be integrated into that environment in a way that is both helpful to the development process, and helps build an even better product.

Creators of screen readers and other assistive technology (AT) products have been working with Mozilla to enable a better user experience. If you are interested, WebAIM has a visual simulation of a screen reader.

The Mozilla Foundation sent me and others from the ATRC to CSUN and I thank them for it deeply. Thank you Frank Hecker, the Foundation board, and Aaron Leventhal for getting people from all over the world together to talk about and work on freedom and choice in access to information whether it be Mozilla product compatibility, web semantics for DHTML accessibility (ARIA, microformats), or accessible choice on free operating systems such as Linux.

CSUNzilla

2007-03-23T09:43:00.000-04:00

Firefox accessibility star Aaron Leventhal helps set up the booth on Wednesday:

A typical CSUN Mozilla booth moment on Thursday:

In the middle of the crowd are Charles Chen, creator of Fire Vox, and Frank Hecker from the Mozilla Foundation.

Javascript Hacking at CSUN

2007-03-22T18:58:00.000-04:00

We hacked on dojotoolkit ARIA stuff today in the Mozilla hacking room. Shown in the pic above are Becky Gibson, Simon Bates, Gijs Kruitbosch, and Earl Johnson (photo by David Bolter).

The Mozilla booth is busy and lots of people have expressed their appreciation. So much is happening here and theres so little time to blog about it!

We're still hacking/meeting now and I hope to blog in more detail tomorrow...

CSUN Mozilla Hacking

2007-03-17T13:37:00.000-04:00

Mozilla is kindly sending me to CSUN!

Next week is CSUN, the "Technology & Persons with Disabilities Conference" and I look forward to mingling with the amazing community that assembles there every year. When not flitting about or helping out with the Mozilla booth I'll likely be in a room Aaron has reserved for group hacking and problem solving where I will meet with talented people some of whom I know only through IRC, email, blogs, and bugzilla.

Due to scheduling conflicts I won't fly in to LA until Wednesday. I'm looking forward to the change in climate as I was out shoveling snow this morning.

In related news, I think that Deb or Robert are going to pull my feed into Planet Mozilla soon so I hope to blog a bit of the CSUN experience for the enjoyment of our extended community.

olpc

2007-03-12T19:33:00.000-04:00

Jim Gettys from laptop.org emailed me the other day to offer me an OLPC X0-1 developer system so that I might work on getting on-screen keyboard support on Sugar.

I think it is time to start hunting for new talent to help with this work. I started an olpc thread over on the mozilla a11y development list to see if the Jambu project might be a good option here but I'm pretty sure Steve Lee has his hands full without having to target Sugar.

I think Sugar could benefit best with some customized OSK work whether use GOK, Jambu, onBoard, or something new. If you are interested in helping out contact me or Jim. Please note that "helping out" means "doing the work".

Solving Disability (continued)

2007-03-04T20:34:00.000-05:00

Note to self:

"...for people without disabilities, technology makes things convenient, whereas for people with disabilities, it makes things possible."
Judy Heumann, 1998