Archive for March, 2009

Updated ARIA-spiced form example to work in IE 8

Tuesday, March 31st, 2009

I updated my simple form example from the third Easy ARIA Tip to also work in IE 8. I had to explicitly state a doc type to put IE out of quirks mode into proper IE 8 mode, and I also had to change the type attribute’s value of the script tag to “text/javascript” from “application/javascript” for it to recognize the functions declared in the script block.

The example works visually, but has a number of accessibility issues which make testing IE 8 with it a not so pleasant experience:

  • Neither aria-required nor aria-invalid take any effect with either JAWS or NVDA. It’s as if the attributes weren’t set, yet the IE DOM exposes them correctly, as JAWS’s Element Info keystroke, Insert+Shift+F1, clearly indicates.
  • Neither JAWS nor NVDA see the alerts come up, and thus don’t speak them. The alerts appear visually, so the JavaScript is working, but the DOM mutation is not being picked up. Only after a refresh in the respective screen readers is the content of these visible in the virtual buffer.

For testing, I used the latest update to JAWS 10, build number 10.0.1142, and NVDA trunk snapshot 2828. And of course, the release version of IE 8.

For those of you doing web application development and testing, this is an indication that your best bet to get proper results is definitely the combination of a strong implementation of ARIA in Firefox and a supporting screen reader.

Last week in the “Accessible” module, March 30, 2009

Monday, March 30th, 2009

The last week was rather short, but no less busy.

First, on the off-code side, I attended the European Accessibility Forum Frankfurt (EAFRA) conference on Friday, March 27. Christian Heilmann from Yahoo! posted a great summary of the event and also caught my guide dog Falko sleeping while I talked. The videos will appear here.

On the code side, the action happened in the mozilla-1.9.1 repository AKA Firefox 3.5b4pre this time. Today, I checked in all the approved mozilla-1.9.1 nominated patches. From Tuesday’s 3.5b4pre nightly build onwards, Firefox will:

  • Expose font sizes in PT units instead of PX, as specified in the IAccessible2 spec.
  • Support the value of “undefined” on aria-checked/aria-expanded etc. attributes, as specified in the ARIA 1.0 spec
  • Drop support for aria-channel, container-channel, and aria-datatype
  • Support aria-expanded on more roles
  • No longer support role=”description”
  • Require aria-grab to be changed to aria-grabbed for drag and drop to work in the future
  • Expose non-editable documents as readonly, regardless of role
  • Expose the ‘checkable=”true”‘ object attribute

This brings Firefox 3.5beta4 very close to the ARIA 1.0 spec. We’ll take another look to make sure we don’t miss any details from the specification for implementation. Thanks to Mike Beltzner for not jumping our throats at these 10 or so approval requests we threw at him at once!

In other news, some progress is being made towards finding the leak that running the accessibility Mochitests on Mac OS exposes. It turns out that these same objects can also be leaked by other tests, which are not accessibility related, but ours are still the best bet at reproducing them. So our master of leak detection, Carsten Book AKA Tomcat has kindly agreed to help debug this beast.

Last week in the “Accessible” module, March 24, 2008

Tuesday, March 24th, 2009

As the accessibility team was at the 2009 CSUN Center on Persons with Disabilities conference last week, not much happened on the forefront that is visible to bug and code watchers. The only changes that landed were:

However, as David mentions in the above mentioned post, we took the chance to put our heads together and develop ideas for future features and also talked about some hands-on issues that need more immediate attention. Also, it was the first time David and I, and David and Alex met in person. I had already met Alex last year in Whistler at Mozilla’s 2008 Firefox+ summit.

Additionally, Ben Hearsum has been active in trying to get our accessibility Mochitests run on Mac unittest tinderboxes, but ran into some leaks that require further digging because we don’t use either class explicitly in the platform-independent or specialized Mac code. We’re probably uncovering a leak that’s hidden somewhere else. If anyone has any good suggestions off the top of their heads, please feel free to step in!

That’s it for this week.

Last week in the “Accessible” module, March 16, 2009

Monday, March 16th, 2009

Last week, we focused mostly on some solidification on our code and test framework. We are having some strange problems with tests failing randomly or not being run at all. To that end, I fixed the loading of remote images in Mochitests, which is always a dangerous source of failure if an image can’t be loaded from the remote site. David also discovered and worked on protection against some failures in our doAction tests.

David also fixed a PRBool violation uncovered by code analysis. He also cleaned up our object attribute exposure code and added tests to make sure aria-sort gets exposed as an object attribute properly.

David also fixed exposure of mixed and checked states for ARIA and HTML 5. Mixed should not be checked at the same time, and vice versa. I helped out with tests on this one.

I refactored our nsAccessNode caching test. There are only 2 files left to refactor now, and one of those is currently disabled.

Alex cleaned up static casts to ATK roles. He and Ginn Chen from the Sun Microsystems China office also chased down one of our top crashers and Gionn found the root cause for this we believe.

David and I agreed to request that accessibility and the accessibility unit tests be enabled on the mozilla-central unit test tinderbox for Mac. This is the first step in getting Mac accessibility efforts moving again. We are currently anxiously awaiting test results from a run on the staging servers. Cross your fingers!

In other matters, David, Alex and I will be at CSUN in Los Angeles this week, so if you’re in the area, come and drop by our booth! We’re being joined by Frank Hecker of the Mozilla Foundation, Mick and Jamie from the NVDA team, Eitan Isaacson, a regular Mozilla grantee, and Aaron leventhal, without whom we’d probably not be sitting here today.

The venue opens Wednesday at 4 PM and runs through 7 PM, Thursday and Friday it runs from 9:30 AM to 5 PM, and on Saturday it runs from 9 AM to 1 PM. I’ll be holding a presentation on Friday at 12PM talking about what we’re currently doing, and planning to do in the future, with Mozilla accessibility, so if you can still get a seat, come on over and let’s have a chat!

See you all next week, where I’ll be reporting a bit about what the venue has been like. I’ll also be updating my tweets, so if you like, follow the hashtag #csun09 on Twitter for my and other people’s updates.

Happy birthday, world wide web!

Friday, March 13th, 2009

Today, CERN will celebrate the 20th birthday of the world wide web.

I’d like to take this opportunity to thank Tim Berners-Lee for writing the initial proposal and sticking to the idea even though his boss, Mike Sendall forgot about it after calling it “vague, but exciting…”.

For me, the web has opened a ton of possibilities that I would have otherwise required sighted assistance with, or which would not be possible for me to do at all, such as casually browsing the New York Times or the Hamburger Abendblatt. I would not be able to look for specific items on, or simply browse the offerings of Amazon. I would not be able to sell no longer needed items on eBay.

Without the web, the world of newspapers would always be more or less hidden from me, unless a sighted person read something to me. The truth is, even though there is very good optical character recognition software out there, newspaper layouts are simply too much to cope, let alone that most newspaper formats don’t fit on off-the-shelf scanners, or even those scanners produced by assistive technology firms.

For shopping, I would always have to rely on someone else to share what they thought the most interesting or compelling offerings in a shopping mall were. It would not be solely my decision what CD I’d buy, what electronic gadget was best for me etc. Oh yes, in many cases I would probably get what I wanted, but it would never be my 100% freedom of choice without depending on others to help me.

And to sell my no longer needed items, I would have to request the assistance of a magazine agent or enlist a sighted friend’s help with preparing an ad, getting it sent in to a magazine publisher, etc.

And these are just some of the things the web has allowed me as a blind person to do independently that were not possible before.

Also, other persons with disabilities benefit hugely from the web, like hearing-impaired who can communicate with anyone without the barrier of most others not speaking sign language. I don’t think it’s exaggerating to say that the web has revolutionized the way persons with disabilities can participate in society.

And that brings me to a point David Baron raised. I can only echo what Wendy Chisholm said in response. I consider access to information just like anyone else to be a right I have as a human being, and the web is the only independent means of doing so. If anyone would try to take that away from me, I promise that I’d prosecute them to the full lawful extent possible.

However, let me emphasize this: I utterly disagree with John Foliot who said that Bespin should never have been released because it uses the Canvas element which is not accessible currently. Here are my reasons for that:

Bespin is not a released product, it’s a Mozilla Labs project that is in a highly experimental stage. Being as open as Mozilla, who share everything we do with the public, some might easily get misled and think that this is a released product already. I can only suggest: Read carefully, then you won’t fall into that trap.

Bespin shows us that the Canvas element can be used for more than just rendering some nice and shiny graphics. It shows that there are still deficiencies in the HTML 5 Canvas element design which need to be rectified as soon as possible. And this is what experiments are for, and always have been: Experiments are there to learn from and improve upon.

The history of the web and the development with the Canvas element we’re seeing now aren’t all that dissimilar in fact. Berners-Lee’s experimental and first theoretical proposal only later turned into something that could actually be useful, when he received his NeXt workstation where he could finally start programming the first web server. He could not have known what would once become the web as we know it today. The inception of the Canvas element probably also happened without realization that someone might actually build a code editor upon it.

In that sense, I am very very thankful for the Bespin team to share their work as early as they did. You guys have shown the web community that there is still work to be done to make Canvas content accessible to screen readers. So rather than whining about Bespin not being accessible, and pushing the developers into the defensive by reflexively yelling before thinking things through, we should get our act together and find out a way to make it accessible soonish! Bespin is a chance, not an evil deliberate move to exclude people with disabilities.

In that spirit, a wholehearted HAPPY BIRTHDAY WORLD WIDE WEB!

Last week in the “Accessible” module, March 9, 2009

Monday, March 9th, 2009

Last week’s work saw quite some code cleanup.

Unification of role and finalRole

Previously, our nsI*Accessible interfaces exposed both role and finalRole properties. While role returned a preliminary role, finalRole always returned the finally determined role after all markup and ARIA processing had taken place.

It turned out that the role was hardly ever used, but everyone always asks for the finalRole. So, the decision came about to file bug 481357 and get rid of finalRole and make role do what finalRole did previously.

As a prequel to that, bug 482013 was fixed, refactoring all test files to use the common getRole and testRole functions in the testing framework. As a result, only one instance of .finalRole had to be dchanged to .role in the bug linked to above, to make all tests still work right.

This change will be exclusive to Gecko 1.9.2, since it will need some adjustments in DOM Inspector and other extensions that use our accessibility interfaces.

Crash fix in tree table code with some side effects

Alex also fixed a crasher in the tree tables implementation of getChildAtPoint/getDeepestChildAtPoint. After a fix for a leak that was uncovered by the test, the tests are still failing on Linux because of wrong coordinates we’re getting back. Investigation into this is still ongoing.

Originally, bug 471493 was also supposed to introduce crashtests specific to a11y. However, it appears that, once a crash test has turned on accessibility, that remains on for the remaining crash tests, and some of the others didn’t react well to that. A solution is under investigation.

Speaking of leaks

While investigating bug 420068, Alex found this memory leak. After he fixed that, the other bug seems to have been resolved, too.

Further test refactoring

I took on our table testing code and refactored it to use the new infrastructure. 4 more files that no longer use their separate implementations of retrievals of accessibles etc. That leaves 3 more files to go, and one of them is disabled right now because of bug 437980.

I also finally got the tests for aria-activedescendant refactor off my back. This one had been going on forever (or so it felt).

HTML 5 features

One thing I forgot to mention last week was that a few weeks back, the “indeterminate” property new to HTML5 was introduced to HTML:input @type=”checkbox” elements, effectively giving them the ability to be partially checked, for example as a master checkbox to dependent checkboxes. As expected, we didn’t expose the mixed state properly on these yet, so I took on that task. As a sequel, I’m currently working on exposing a proper action name for these as well. I’m having some trouble getting the tests to run properly, though. The tests go into an endless loop when I run them locally, so until I found out why, I’m hesitant to throw these at the tinderboxen. If anyone has seen this happen at all, suggestions are welcome. A sample log excerpt can be found here. The tests start running this test_comboboxes.xul file, then the whole a11y test suite starts running all over.

More text attribute fixes

Alex got the font-weight bug resolved, so font-weights are now properly exposed according to the visual representation and not through some seemingly arbitrary numbers.

aria-sort, aria-grabbed, and aria-expanded action exposure

David has been sinking his teeth into this one and has come up with a great idea to solve this. Since no desktop app ever exposed many of these things especially when it comes to a controlled drag and drop action from a screen reader’s point of view, this one requires careful thinking and design as well as good communication with AT vendors to get right.

Progress on plugging in accessible trees from plugins

Recently, community member Brad Taylor approached us with the question of plugging in accessible trees from plugins into our accessible tree on Linux, integrating third party plugin accessibility nicely with ours. A bug was filed, and Brad has been working on this, regularly communicating on the accessibility channel with David. A first WIP patch was posted on Friday.

That’s it for this week.

JQuery UI 1.7 released

Saturday, March 7th, 2009

The jQuery UI team has released jQuery UI 1.7. Congrats on this release!

One thing the team did not mention in the above blog post is the fact that jQuery UI 1.7 is the first version to contain WAI-ARIA enhancements, making the widgets more, or at all, accessible. WOOT!

It’s really cool to see another big player in the JS widgets field to adopt WAI-ARIA, making modern websites more accessible the moment they just switch to this version of jQuery UI.

Firefox 3.0.7 fixes screen reader users in GMail!

Thursday, March 5th, 2009

As you may or may not have read yet, Firefox 3.0.7 was just released. This security and stability update brings a very important fix for all screen reader users wanting to use GMail. Previously, it was not possible to open messages by just going to the appropriate link and pressing Enter. GMail would simply not react. One had to use mouse emulation and click the link to get the message opened. Firefox 3.0.7 fixes that problem, allowing our users a much better GMail experience.

Enjoy!

Last week in the “Accessible” module, March 2, 2009

Monday, March 2nd, 2009

This is the first in an ongoing weekly series where I’ll highlight items that the accessibility team has been working on over the last week. I’ll be reporting on fixed bugs, or will also call out on items that we might appreciate your help on.

Since this is the first issue, and my last update on a concrete new feature/major change has been a while, here’s a broad overview over what we’ve been up to over the past two months or so.

Automated tests on all three active Firefox development branches

Since December 18, 2008, all three Firefox branches that are under development run accessibility mochitests. These branches are:

  • Gecko 1.9.0, off which Firefox 3.0.x is being released. These tests actually have been running since roughly the Firefox 3.0.4 timeframe in October.
  • Gecko 1.9.1 AKA Firefox 3.1. This is the branch Firefox 3.1 will be released from.
  • Mozilla-central. This is the development branch where the next major release after Firefox 3.1 is being developed, with new features going in and more experimental stuff is happening right now.

The most interesting of these is definitely the mozilla-central branch. Both Gecko 1.9.1 and 1.9.0 receive back ports of important features/bug fixes from this branch. The number of tests that run in the accessibility code has surpassed the 2,000 mark two to three weeks ago. We started in December with about 1100 tests.

ARIA 1.0 compliance patches

David has been working on ARIA 1.0 compliance patches and started to put in some good infrastructural stuff as well. Interesting items are:

Alex implemented the ARIA spec’s name from subtree calculation algorithm. Of course, despite all the tests, a regression had to creep in, but after that’s fixed, I believe we’re in good shape. The visible result, especially for authors of ARIA-enabled we bapps, is that the Firefox 3.2a1pre nightlies should now always behave according to spec when calculating the name from those elements/widgets that call for its subtree to be aggregated as its name.

As a side note for those interested in the effect our automated tests now have: When Alex tried to land a fix for bug 463645, it clashed with the above mentioned name from subtree bug in an unexpected way, causing an immediate orange flag on the unittest tinderboxen. We’re looking for a solution to that problem right now. Hadn’t we had these tests in place, it would have taken a while for this regression to creep up in manual testing. This way, due to an immediate backout of the offending code, no nightly build ever saw this happen.

New for text attributes

David implemented the conversion to pt algorithm that IAccessible2 calls for on Windows. This change is also in Firefox 3.1.

Alex implemented a faster way of retrieving text attributes,a nd he and I teamed up on better better test coverage for this area.

Accessible relations improvements

Alex worked on better accessible relations support, allowing for a relation to have multiple targets. This will allow assistive technologies to get at aria-labelledby relations correctly. As a sequel, 1:1 relations between tabs and tabpanels were also implemented, allowing ATs to better identify which tab a tab panel belongs to.

Proper reorder events

Alex, our man for big patches :-) , also created a fix for a long-standing bug involving reorder events on DOM mutation changes. Several screen readers need these events to keep track of dynamic changes on web pages to keep their virtual buffers up to date. Some recently inconsistent behavior that often required the user to refresh their virtual buffers manually, should now work much better. This change also is included in the Gecko 1.9.1 branch already, waiting to debut in the upcoming beta 3 of Firefox 3.1.

Thunderbird 3 reading panes

The Thunderbird 3 reading panes received a fix to the way they expose the “from: ” etc. header information. When tabbing through these header fields, one now immediately hears which type of header this is with a compatible screen reader.

This fix was done by Yuen Hoe, a student at the University of Singapore, as part of the NUS Mozilla students project. He picked this bug specifically. Thanks Moofang!

Because this patch relates very closely to SeaMonkey, it was ported there as well, however users can’t take full advantage of this yet in SeaMonkey because of a keyboard navigation issue in the message reading panes.

Better accessibility in SuMo’s live chat

SuMo, Mozilla’s support community, offers a live chat facility that alows users to get help quickly. This live chat was previously not very accessible.

However, Gijs Kruitbosch, the mastermind behind ChatZilla’s accessibility features, worked on a fix, which will see the light in one of the next Sumo updates.

I know this is not strictly the Gecko Accessible module, but nevertheless very important to the over-all Mozilla eco system, and that’s why I’m mentioning it here.

On other fronts

I’m currently working through some of the earliest test files to make them use the common accessibility retrieval and events structures that were implemented more recently. This will help maintainability and make sure that if we add new features to these common functions and classes, every test will benefit from them.

On Windows, all active branches will be more correct in what service IDs they accept when calling the QueryService function. This insures better compatibility with Windows 7, among other things.

Thanks for sticking with me until now! The next reports will be shorter, I promise! :-)

Of course, we welcome your feedback on this kind of post, or on specific areas. So feel free to comment here!