monotonous.org

Specular/Speclenium 0.0.3

Another release out the door!
Update: I started migrating tests and creating new tests against the codetalks collection. You could see that git branch here.

–debug=ALL

As I have mentioned in 15 earlier blog posts, my current project is putting together an accessibility API comparison framework specifically for browsers, and help weed out substantial differences in implementations.
The challenges I have faced, and still sometimes face:

Windows

I was surprised to learn that Windows is still by far the most popular platform in the world. Interesting. Since it isn’t very POSIXy, I have had a lot of dillemas as how to distribute software for it. The usual autotools, or distools does not have all the advantages it has on Linux or Mac OS X. On any other OS, you could safely assume that Python is installed. Not on Windows. In the last few releases I have been experimenting with py2exe. It gives you a bit of a DOS feel to your package: unzip and run the first EXE you see. Easy, but unelegant.

Selenium

One of the first things that turned me on to Selenium was that it was platform, browser and language agnostic. What better way to provide users with absolute freedom in choosing their language and platform? Originally I subclassed Selenium’s Python client class, and added all of the accessibility functions to it. But I decided it would be awesomely cool if this were added to the Selenium server itself, so that the integration with accessibility would be tight and native, and language agnostic. After installing a couple dozen dependancies, and reading Selenium’s developers guide more than once, I finally made the proper changes in Selenium Core and Selenium Remote Control to support accessibility tests. This created a huge overhead for anyone who would want to build the entire solution from source who is not me. They need to check out my git versions of Selenium Core and Selenium Remote Control, figure out how to build them, fail, try again, etc. Selenium has many advantages, but building it is a real pain.
While Selenium is great, I have had a hard time interfacing with it’s community, besides a few individuals. The changes I made to selenium only made sense if they somehow landed upstream. I don’t see that happening any time soon, so folks who want to use my solution are doomed to using a fork forever. Unacceptable!
So I decided that in the next Speclenium release, I am going to go back to the simple approach of subclassing the Selenium Python client. This will hopefully simplify the setup overhead since we could instruct people to just go to Selenium’s website and download an unmodified binary. The downside, is that tests could only be written in Python, and not in Ruby or PHP. I think that is an acceptable loss.
I already have a branch with the appropriate changes. There will be some dramatic file renaming going on too, not for the first time.

Selenium vs. Windmill

Since I started work with Selenium, I have been called attention to Windmill more than once. For one thing, it seems like Windmill will be the tool of choice for Firefox QA. With components such as MozMill, and Gristmill Firefox QA could do some automated chrome testing action. Recent real-world cases have come up in the Firefox world in which such in-app interaction would be beneficial. Currently the Selenium setup is specifically targeted at the document frame, and nothing above it. This has been the choice since ultimately we are looking for browser independance.
Windmill is written entirely in Python, which would compliment my project well.
So why not switch to Windmill just yet? For one, it would be a distraction, I am pretty far along in the project, I would hate to suddenly switch the whole toolset. Second, I have a feeling that Windmill does not have the same wide support for browsers as Selenium does. For example, Selenium already has the proper bits for automating Google Chrome. I am repeatedly impressed by how easy it is to launch and automate obscure browsers using Selenium.
I know that Windmill has been under intense development this summer, so it might get really good soon. Nonetheless, I think that this accessibity testing project might eventually benifit from a side-by-side approach of support for both Selenium and Windmill.
That is my brain dump for now. Aren’t you glad I don’t do that often?

Happy New Year

… to Heebs and all.
I am spending the Holiday with my grandparents in New York. It’s really nice to be able to do that.
I have been taking time over the weekend to revisit my accessible tree comparison code from a month ago. I then managed to waste two days trying to get Selenium to work with trunk build of Firefox. I took David Bolter’s suggestion and relooked at Windmill. I would hate to switch automation schemes mid-project, but I could tell that eventually it will be beneficial. Windmill has it’s shortcomings too. It is amazing how non-trivial it is to launch Firefox. Both Selenium and Windmill have issues with that.
Anyway, I decided to stop putting time into that for a while, and instead improve the whole tree comparison deal. There are a few issues that still need to be dealt with:

  1. Accessibility. Ironically the comparison display is not too accessible, it relies on colors for example. It should also have an optional column with info as to how that node changed (inserted, deleted, updated, moved). The “moved” string should be an anchor that by pressing it will put the focus on the other tree’s “moved” anchor and show where it moved to. Of course I could also add ARIA markup to this.
  2. Horizontal alignment. Equivalent nodes should be on the same row, this will also make it much more usable for screen reader users.
  3. More accurate matching. The heuristics I am using now are good for generic XML, but they could be made more relevant to accessibility APIs. A lot of the “moves” don’t make too much sense, and don’t make it any easier on the eyes. I am thinking that if I can’t improve this, I will just change “moved” markup to delete/insert.
  4. Prettyness. The output now is uglier than a monkey’s armpit. If I could get it together visually, I am sure it will be more usable and accessible too.

So here are two examples, they both use the dijit form demo:

  1. This is a comparison between Firefox 3.0.2 and Firefox nightly (9/29).
  2. This is a comparison between Firefox nightly and IE 8 beta 2.

Stop The Coal Train

The United States in some respects has come to terms with it’s dead-end consumption of fossil fuels. A watershed moment happened a couple of years ago when Bush informed us all that we are “addicted to oil”, as if his administration reached that conclusion before the rest of us. Even global warming is not the same politicized issue it was a couple of years ago, today it could be regarded as fact without a partisan chip on the shoulder.
It is really sickening to watch the resurgence of coal energy, and it’s labeling as the energy source of the future. It isn’t. It is amazing that certain industry and interest groups could get away with such a corny mindfuck.

So I decided to do my blogger’s duty and get the word out, I also added a badge to my site which is very not like me. Sign it!
http://ilovemountains.org/webbadges/bloggers_toolbar1c.php?id=36038