Microsoft listens, and addresses WAI-ARIA concerns

A few months ago, I blogged that Internet Explorer 8 beta 2 was not using standard syntax for WAI-ARIA properties. The syntax actually varied depending on the mode chosen for the page, which was confusing. Sometimes the standard worked, and other times you had to use non-standard camelCase for WAI-ARIA.

Microsoft has listened and is correcting WAI-ARIA property support in IE 8 RC1. Here’s a big thank you. It’s important to have a healthy portion of WAI-ARIA work the same across both browsers. Many look forward to test-driving the WAI-ARIA support in IE 8 final.

Fingerprint and card readers with Firefox

Some laptops, such as from HP, come with fingerprint reader options. I have never seen this in action, but as I understand it, you can swipe your finger and it will automatically fill in any password field for you.

On the web, this means the fingerprint reader must look through the page for password fields. HP apparently reuses something from Bioscrypt, called Verisoft, which was purchased from Cognizance. It actually reuses the accessibility API on Windows to look for password fields. Specifically, it must go through the MSAA tree looking for objects of ROLE_TEXT with STATE_PROTECTED.

Believe it or not, I learned this by investigating a mysterious crash. Since crash-stats isn’t handling most of my queries, it’s been difficult. But, by looking at Modules, I noticed that a foreign DLL called APSHook.dll was always present. Some Google searches led me to Spyware sites describing which company is responsible for what DLL. The maker was Cognizance Security. Errors in their site led me to suspect they were a dead company, and but I was able to finally find an article about them being purchased by Bioscrypt. Further searches for Firefox APSHook reveals people having all sorts of problems with sluggishness, lock ups, stack overflows, extra memory usage etc.

I don’t know why the crash occurs yet, perhaps they don’t do an AddRef() where they need to, or perhaps we’re broken somewhere. Apparently the feature used to work in Firefox 2, although not officially supported by Verisoft.

I called Bioscrypt support and they told me that Firefox isn’t supported (which doesn’t stop them from injecting a DLL that makes us crash). They promised to forward my email to the developers, so I’ve sent them the information. I’m not holding my breath, but well see what happens. I’m sure HP is interested in letting their users enjoy Firefox 3. HP users who purchase the fingerprint reading option can’t use it with reliably with Firefox 3. In general, web searches for Verisoft Firefox reveal that many users are frustrated about incompatibility with Firefox 3.

In the meantime, isn’t there generally a better way to support fingerprint readers and other single sign on products, than to use MSAA? It’s not cross-platform, and it doesn’t integrate with Firefox’s password management. Also, the Firefox accessibility support does take some memory and slow things down, because it needs to create a lot of objects and event listeners in order to function. That is why it is turned on only when needed. Using that for password management is overkill. There must be a better way. If you’re interested, please see the fairly old ignored bug on integration with fingerprint readers. It has a few dupes and votes, but not enough to get it noticed.

For my part, I’m just interested in fixing the crash. Looking around the web though, there are a number of users torn between Firefox 3 and their fingerprint readers. It would be good if someone took an interest.

Looking back … and forward

So this whole thing started for me back in 2000. It began as a one way trip from Chicago to Netscape’s Mountain View offices, traveling through small towns and past the Grand Canyon, up through California and finally into the fog of the bay area. This was to be the last major trip for my mini-Cadillac (a 1986 Chrysler New Yorker).

Netscape barely knew what accessibility was. But they gave me an apartment to live in, and an office. I was working for a Braille note-taker manufacturer who needed web browsing capability. My coding skills were all home grown, in straight C and not in C++. I had never touched something as immense as the Mozilla codebase, and still had not grasped the true power of dynamic content. But what I did have was passion and the belief that open source was a beautiful place — and the best place to implement accessibility the right way.

Eventually Netscape hired me to integrate accessibility into the core product. There was a lot to do — not just to make Mozilla communicate XUL and HTML content and events to screen readers via MSAA, but also to add full keyboard support. I also added some special features for all users, like caret browsing and type ahead find (later enhanced by Blake Ross to become the find bar).

Then in July of 2003, Black Tuesday arrived. The Netscape browser team was laid off. I’d like to thank Asa Dotzler and others for their optimism very early on, even before this. Asa knew that Mozilla needed to be free to develop its own vision, Firefox. The truly passionate found a way to continue working on Mozilla. A year after I was laid off, IBM hired me finish the accessibility work. Yay!

All in all, I got married, had two children, went through three jobs, lived in three cities and fixed over 1000 bugs since it all started …. and we have a very accessible Firefox. Mozilla has a major role in leading the charge for accessibility of Web 2.0, not to mention accessibility on the Windows and Linux desktop.

These days, Marco Zehe, Alex Surkov and David Bolter have taken over the core accessibility work. These are the right guys to bring the quality and polish we need. It’s not all boring; there are also new features to implement. In 2009 we hope to become accessible with VoiceOver on OS X, continue to improve our support for WAI-ARIA and Web 2.0 accessibility, and address advanced topics such as accessible math, diagrams and custom widgets. It’s a bit unfortunate that these are still considered advanced topics in accessibility, when they are so basic to the mainstream. However, when Mozilla addresses new accessibility topics, it tends to pave the road with standards and documentation. This makes things much easier for implementers that come after us.

Although I’m no longer coding I work as hard as ever. I still advise in the codebase and act as module owner. I want to help make sure that decisions of the past are understood by anyone working in the code. Documentation is helpful but ultimately not enough.

What am I working on now?

• The WAI-ARIA standard and everything around it. Right now, making Web 2.0 accessible means using a narrow set of technologies which support WAI-ARIA well. The browser must currently be Firefox, and some ARIA features are only supported in certain newer assistive techologies, and definitely not on OS X. And, you’ll either need to develop your own widgets or use Dojo’s Dijit toolkit. Fortunately, these inflexibilities are slowly but surely fading away. IE, Opera and WebKit are all working on WAI-ARIA support. Numerous JavaScript toolkits, such as YUI, GWT and JQuery, are moving forward as well. Assistive technologies are improving support for cutting edge areas like AJAX accessibility via WAI-ARIA live regions. But ultimately, Web 2.0 accessibility will arrive for real when a “killer app” arrives which requires a WAI-ARIA compliant browser. That’s what will finally drive things forward.  In the meantime, I’ll try to make things as clear for other implementors as I can.
• Finding talented individuals and cowriting grant proposals for worthwhile accessibility projects that benefit the web. One example is Silvia Pfeiffer‘s project to add captioning and audio descriptions for HTML 5 video and audio. I’m also working with Eitan Isaacson, a great programmer who helps us in too many ways to count. He developed Speclenium, a tool to allow the accessibility implementations in two browsers to be compared for differences. I plan to use it to help other browsers improve their support for WAI-ARIA.
• Enabling projects to add basic accessibility testing into Firebug and develop a Firebug extension for more advanced accessibility testing. This will bring awareness of accessibility issues to a wider authoring community, finally bring the test tool development community together on a common strategy, and allow us to address Web 2.0 accessibility testing.
• Advancing the accessibility of math, diagrams and custom widgets.
• Participating in efforts such as AIA, to create a cross-platform accessibility API. Today, developing accessibility for native cross-platform applications is a nightmare because each platform has a different solution. It’s best for the web if the entire industry works together on common accessibility solutions — Mozilla, IE, Opera and WebKit.

I’m very lucky to work with the community that has developed around Mozilla accessibility. I think we follow the model of the Mozilla project as a whole, enabling each other to do great things. This is a good opportunity to thank IBM and Mozilla, and in particular Frank Hecker, for the opportunity to work as more of a leader and organizer. It’s a less direct approach than just writing the code yourself, but when the timing is right it’s the right role to take on. You’ll produce far greater results.

Introduction ou Introducción a WAI-ARIA

(Introduction to WAI-ARIA && Introducción a WAI-ARIA && Introduction à WAI ARIA)

Thanks to Gez Lemon,  David Martin and Pierre Bertet. For more info on ARIA, go to Codetalks.org.

Mozilla and AEGIS

Last week I had the chance to present to the AEGIS Project, a monumental new EU funding effort for open source accessibility. The AEGIS funding of 12.6 million Euros will be spent over a period of 3.5 years, bringing new developers and fresh ideas to open source accessibility.  AEGIS is just in the beginning stages — they still have a lot of work to do just to set up the organization. The first six months of AEGIS will be spent on research and planning, including usability tests of current-generation solutions.

Walking into the meeting room I was astonished to see about 40 people seated in a half-circle, many of them clearly developers (several bearded computer science types were present, thus lending credibility). The people in the room represented just a portion of AEGIS. A wide variety of backgrounds and nationalities was present, and at least some of them are experienced in accessibility. Seeing this group gave me a rush. The generous grants from the Mozilla Foundation have been world-changing. Who knows what’s possible if you multiply the resources by 10 or 20? The size of AEGIS means it can be help bring much higher quality and more innovations in the open accessibility space.

Even with their size, AEGIS still needs to focus in order to deliver. Projects that are too heavyweight fail. From my point of view, the size of the Mozilla Foundation grants have been good — they’ve allowed us to be very ambitious and accomplish great things, while not allowing us to be careless with what gets funded.

My concern for AEGIS has been, how will they manage it all usefully? Clearly they will need to ignore certain areas. For example, AEGIS will probably not be developing open source assistive technologies on Windows, because they want to focus on platforms where rich accessibility APIs are supported more consistently. That definitely means Gnome (I’m not yet clear on what their take on OS X is).  This fits in with one of AEGIS’ goals of focusing on economic disparities, and providing low cost accessibility solutions to people who can’t afford proprietary solutions. This differs slightly from Mozilla’s focus in accessibility tooling. We care a lot about the open source desktop and have done great things for accessibility on it, but we also care about being very accessible on Windows, which currently is where more of our users are.

After Peter Korn introduced me I presented both on ARIA and the Mozilla community’s accessibility efforts so far. (Peter Korn is the main visionary behind AEGIS). Mozilla has made a broad contribution to accessibility that extends beyond the web. I was able to provide some ideas on what succeeds and what doesn’t. It was a tired group, but I was well-received. Peter treated me with high regard, like an old timer who has valuable lessons.

My biggest question coming in was, where will AEGIS cross-pollinate with the current open accessibility community and Mozilla’s efforts? As I presented my ideas, I got clues from the head shakes and grunts. There are also clues on Peter’s blog.

A big area of common interest is the accessibility of Web 2.0 using WAI-ARIA, something that Mozilla helped spearhead with implementations in Firefox and assistive technologies. I don’t yet know whether AEGIS needs WAI-ARIA for specific applications, or whether they just agree with the long term goals. Other potential common areas of interest include testing tools, mobile devices, assistive technologies under Gnome and a better open source text-to-speech engine. I’m personally interested in seeing better alternative input (AAC) software developed for people with physical disabilities, and often multiple disabilities. In my opinion, what exists today is still very primitive compared with what exists for people with visual impairments. I hope they look at Jambu or at least some of the ideas in it, like in-application selection.

My hope and belief is that once AEGIS is ready, it will open up a bit more to the wider community. They will need to include the community in brainstorming and planning and ensure that developer’s mailing lists, bug databases and wikis are completely open. This is good for a number of reasons — to get the best ideas, and to avoid hurting external developers working on similar projects. Perhaps more importantly, it is necessary to get developer buy-in and ultimately wider, longer lasting participation from the open source community.  Most of the AEGIS developers I met would prefer to be “truly open”. This is probably just a matter of time.

To conclude, I’m looking forward to watching AEGIS blossom. The lasting  affect of AEGIS won’t just be the tools they develop. It will also be how they affect communities.

Great new ARIA video: “Developing Accessible Widgets Using ARIA”

Does your page use JavaScript for dynamic effects, widgets or content updates? Want to make sure it’s accessible? If so, check out Yahoo’s new video Developing Accessible Widgets using ARIA.

Todd Kloots uses real examples to cover setting up the ARIA development and testing environment, landmark roles, widgets, enabling complex widgets with progressive enhancement, keyboard navigation, live regions, custom widgets and more.

A big thank you to Todd Kloots and Yahoo! for putting this together.

Making the entire web more accessible

We spend a lot of time on the very basics. It takes a lot of effort just to make Firefox accessible with the various tools out there, to create the polished experience that people with disabilities want. We struggle to create new standards to allow the future dynamic web to be accessible.

But what about the web itself? Content needs to be accessible, right? Too many web pages don’t bother, probably because of lack of awareness or knowledge of the issues, or a concern about the amount of work involved.

Fortunately, there are tools to help developers that are willing to try them. What web accessibility testing tools exist for Firefox?

• The Firefox Accessibility Extension from the University of Illinois. This one
• The WAVE toolbar from WebAIM (please help review so they can get out of the addons sandbox!)
• WAT toolbar (being ported to Firefox, not available yet). If you want to check it out now, try WAT for IE.
• The Color contrast analyzer also from the WAT folks, has the beginnings of a table and live region analyzer. Eventually this will become part of the WAT toolbar.
• TAW3 from Fundación CTIC, an automated checker that creates a report from the page.

Outside of Firefox, there are others, such as the IBM Rational Policy Tester Accessibility Edition (what a mouthful!) — formerly known as just “Bobby”. Feel free to add a comment about any tools you like (or don’t).

Major Opportunities to Improve

Accessibility testing could become part of mainstream tools like Firebug or the Web Developer Toolbar. This would raise awareness quite a bit, as these extensions are used by millions of developers. We’d need to do a good job of finding a natural way to integrate into the features that already exist. For example, the Firebug HTML view could highlight incorrect markup or accessibility violations. There could be a quick search for various kinds of markup, and we could have a log of errors can help developers jump back to the root source code which caused the problems. We can learn from accessibility tools that visualizing problems right in the page content is very useful. And in general, if we’re to successfully integrate, we need to have a high signal to noise ratio — developers will ignore a11y errors if they are not accurate and important.

Another place to improve is Web 2.0 and AJAX accessibility testing. Current generation accessibility tools expect static pages. As we know, the web is not static. The new tools need to help developers add the right WAI-ARIA markup to put meaning to the dynamic chaos.

Finally, we can use open source methodologies and work together better as a community. Why should there be so many independent efforts? Let’s pool resources this time around. IBM, the Paciello Group and the University of Illinois are already in discussions about how we can work together on a new generation of tools. The plan is share and reuse code as much as possible, and make features available both in mainstream and specialized accessibility tools.

Where do we go from here?

Please share your insights. We need as many perspectives as possible!

• Which of the current generation of accessibility tools works best for you and why?
• What are the best features of each tool?
• What are possible integration points in mainstream tools like Firebug?
• Where do current tools fail
• What features would help you test AJAX or Web 2.0 accessibility and WAI-ARIA (JavaScript widgets, live regions, drag and drop, landmarks, etc.)? (Feel free to ask me if you want to know more about this new area).

Feel free to dream.

Legacy defeats consistency in IE 8′s Web 2.0 accessibility effort

Cooperating on Web 2.0 Accessibility

UPDATE: Microsoft has now listened, and is changing this in IE8 RC1. It is very much appreciated. The original article follows:

---

It’s exciting that IE 8 Betas have WAI-ARIA support in order to enable Web 2.0 and Ajax accessibility, and that Microsoft joined the W3C PFWG to work on standardization. With all of the major browser vendors collaborating on the WAI-ARIA web accessibility standard, addressing the modern, dynamic web seems in reach. We’re even collaborating on platform accessibility API specifics for ARIA, which is a major step forward to allowing a consistent experience for users with disabilities. The scope of cooperation between browser vendors on the technical aspects of accessibility is truly unprecedented. There is already an amazing amount of support for WAI-ARIA in browsers, JavaScript toolkits, assistive technologies and more.

It’s enjoyable working with Microsoft accessibility engineers. They care about what they do, and are easy to get along with. Except for one issue, we have always either agreed or could at least relate.

IE 8′s WAI-ARIA Incompatibility

Unfortunately, a disagreement has come up on an important compatibility issue.

In IE 8 Beta 1 Microsoft introduced their own unique method for setting ARIA properties without notifying the working group.  The feature was added to IE 8 standards mode as well as legacy modes. This was an unintentional side effect of IE’s legacy code. By adding a new feature and not implementing the existing standard, they broke something fundamental — how developers write JavaScript to change an ARIA property.

Here’s a concrete example: if a user presses the right arrow in a JavaScript slider, the slider’s keydown event handler should be able to increase the slider’s aria-valuenow property such that it is reported to any assistive technology such as a screen reader. It should work the same way no matter what browser you use. In this case, the author simply uses slider.setAttribute(“aria-valuenow”, theNewValue) and it normally just works. A screen reader user will hear the new value or be able to read it on their braille display. This is fundamental to ARIA — the ability to create interactive widgets in JavaScript, which correctly report their updated properties as they change. Unfortunately IE 8 breaks this by interjecting a non-standard method for changing ARIA properties.

The behavior also depends on which of IE8′s three operating modes a page loads in. Two of these modes require authors to use a non-standard method to change an ARIA property. Here’s a quick summary:

• Correct slider.setAttribute("aria-valuenow", '25'); // Firefox, Opera, Safari, IE8 Standards Mode
• Incorrect slider.ariaValuenow = '25'; // IE8 in all modes, including “standards” mode

So does IE support the standard method of changing a property or not? Only in one mode — IE 8 standards mode, but it’s tricky to know when IE 8 standards mode will be used. On the other hand, the non-standard method (we’ll call it ariaCamelCase) is supported in all IE modes. Only the standard is supported in other browsers. Many existing applications do not use IE 8 standards mode and it is realistic to say that many will not transition at the same time as implementing WAI-ARIA.

The Consequences of Incompatibility

The current state of affairs is going to create a mess. Authors will be confused about ARIA, because changing a property won’t work consistently. We’ll get a strange mixture of:

1. Web apps that are only accessible in IE
2. Web apps that are only accessible in Firefox and Opera/WebKit (once their ARIA and accessibility support is further along)
3. Web apps that support both because they have made the transition to IE 8 standards mode
4. Funky, messy code to check the user-agent string and attempt to get around the issue with browser-dependent code (exactly what the web is trying to get away from)

The whole situation is worsened by the fact that standards mode is not always the default. It depends on whether a page runs on an intranet, whether there is a doctype, and a whole host of factors. For most developers not versed in these details, the type of ARIA support you get in IE 8 will be a roll of the dice. Rather than face that confusion, developers are likely to use the nonstandard method, which confusingly works even in IE 8 “standards” mode.

No amount of documentation will prevent developer confusion. Users will be confused why some apps are accessible in one browser, and some in another. This will in turn slow down ARIA adoption. ARIA is built to make web apps accessible today.

Prioritizing Standards

Microsoft has also asked what can be done to enhance community trust in their handling of standards issues. Collaborative working groups are successful when the lines of communication are open, the implications of various strategies are discussed together, and participants follow up on issues. Microsoft never proposed that ariaCamelCase method should be a standard part of ARIA. However, when the community discovered the divergence back in March, just after Beta 1 we pointed out how important addressing this was for interoperability.  Microsoft agreed to move forward based on community consensus. They promised to look into a solution, and if none were feasible, at least warn authors not to use ariaCamelCase. They have not done any of these things. The community should not have to stumble upon these compatibility issues. Microsoft needs to communicate its awareness of the issues it is currently presenting, and help articulate the way forward.

While ariaCamelCase might be considered a neat feature, it is very likely not compatible with the future of ARIA where authors can define roles and properties. Naturally Microsoft has the ultimate say in what goes into it’s browser, but keeping this incompatibility makes a strong statement about how much it values the standards process and saving work and confusion for developers and users.

Microsoft doesn’t hold any ill intentions here. Understandably, Microsoft is not eager to add code that remove a feature which is arguably beneficial. They like the feature. Therefore, Microsoft should actually propose the technique as an official part of WAI-ARIA, and allow the community to accept or reject it. In fact, because it has currently not  been properly discussed, it does not currently address important issues. For example, it does author-defined properties. It does not address the cost to ARIA’s significant momentum. And as something non-standard and never proposed, it means other browsers have not implemented it and have no plans to.

ARIA is a great opportunity to solve many accessibility problems affecting the web.  If Microsoft wants to extend ARIA, that’s great; however, we must ask that Microsoft work with the community in good faith and extend ARIA with the full confidence that it’s right.

What are we asking Microsoft to do?

We’re asking Microsoft to keep WAI-ARIA from being convoluted by legacy code. Microsoft can ensure that all modes consistently support correct setAttribute() usage for changing ARIA properties. For the IE codebase it’s only necessary to add a condition to check for “aria-” properties when setting an attribute. It should not be a difficult change nor one that will cause a detectable performance hit.

We’re also asking Microsoft to communicate its awareness of the issues it is currently presenting, and help articulate the way forward. Microsoft can join the community in implementing whatever consensus is reached.

Accessibility is very important to both users and authors. Making it all simply work for users is more important than holding onto incompatibilities. Let’s do it right.

Motion sickness and transition effects

A couple of days ago I received an email from a user named Jen, a Firefox user and Java programmer:

… when firefox goes to a page where it wants me to enter a password, then a horizontal bar-shaped menu appears at the top and the entire page slides down about a centimetre to accommodate this bar … The problem for me is that the bar in firefox appears very suddenly and the movement of the page to accommodate it makes me feel very motion sick. There is currently no way to turn this page sliding off.

After several emails back and forth with Jen, who very patiently explained the issue. I learned that she and others actually do get sick to the stomach from transition affects in UIs. The fact that this is trendy among UI developers is no help. For example, Apple loves to use transition affects by default. At my request, Jen put up an article on how to turn transition effects off in some popular products.

Firefox 2 doesn’t have this issue. The recent Firefox 3 automatic upgrade had literally made Jen sick! For now I suggested to that she return to Firefox 2 and turn off automatic upgrades. Prior to that suggestion, she was in the midst of switching to Opera — that’s how real the issue was for her.

As it turns out, this is a topic you don’t hear discussed much in accessibility circles. It is, however, mentioned part (h) in the software guidelines of section 508 law as well as W3C’s UAAG (the user agent accessibility guidelines). When this topic is discussed it’s usually discussed along with its cousin — blinking. Blinking can cause seizures in people with epilepsy.

Both blinking and animations can also cause cognitive stress in some individuals. Perhaps that’s why I find these things annoying. I’m probably one of them, and I suspect there’s a scale between loving it, finding it annoying, being stressed by it, and getting sick from it. But also, I just want to get to my content!

Does this mean that these effects shouldn’t be used? No. Firefox needs to provide users with a way to turn them off.

And what about web apps? JavaScript toolkits like JQuery make transition affects really easy to do, and it appears that this is going to cause problems for many people like Jen. I’m not sure what the right mechanism should be for exposing preferences to web pages — we’ll have to follow up on that one later. It should probably be a standards discussion.

If anyone has more information on these issues or statistics, feel free to add a comment.

UPDATE: I’m also proud to have introduced Jen to AdBlock Plus — one of Firefox’s best accessibility aids.

Chapter 1 in an accessibility story: HTML 5 video

One day, as I read on planet, I learned that Firefox would be supporting <video> and <audio>.

“Yowza! What about captions? What about audio description? Another uphill accessibility battle. No one is even slated to work on this!”

I’m skeptical is no longer The Mozilla community came through for accessibility once again. First, I spoke with Henri Sivonen & Chris Double. Both understood the importance. Henri is always able to help focus a discussion on the right issues, and Chris reassured me he will make sure that implementation happens, but we needed a plan.

Chris introduced me to Silvia Pfeiffer, Silvia is an experienced engineer with diverse experience in automatic creation of video metadata and captions, video hyperlinking, MPEG standards, Ogg and Annodex, as well as Web applications using Adobe Flash. She is an active member of the Xiph / Ogg community. She is extremely keen to solve accessibility issues for Ogg media files, and easy to agree with.

Silvia has an extremely cool hybrid German-Aussie accent.

Last week, Silvia started on a Mozilla Foundation grant to work with the community to develop a plan for accessibility support in HTML 5 <video> and <audio>, using an Ogg container. It’s a complex area, with many factors such as existing standards, formats and authoring tools, to be considered. Silvia’s recent blog entry does a good job at introducing the work and pointing to her wiki docs describing the requirements and background.

It’s not just a matter of implementing what exists today. There are opportunities to assist video indexing, support social creation of accessible content for existing media, provide new capabilities for expressing emotion, and more. Naturally, these ideas must be considered in the design process while maintaining a pragmatic view and avoiding unnecessary complexity.

Silvia has created the mailing list accessibility@lists.xiph.org for discussion. and you can also find her on irc.mozilla.org #accessibility as “nessy”.

P.S. Thank you to Frank Hecker for making this possible, as he has for so many other open source accessibility iniatives.

UPDATE: Silvia tells me that she has a bit of a Scottish accent mixed in there as well (she spent 1 year in Scotland).