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.

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.

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!

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.

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.

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

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!]

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.

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.