It is fantastic to see that WAI-ARIA is getting more and more adoption in mainstream products. VoiceOver is available on any iPhone 3G S and iPhone 4, as well as the newest generation iPod Touch models (32 and 64 GB), and the iPad. The iPad does not include the landmarks feature yet, since its iOS hasn’t been updated to version 4 yet.

Further reading

Easy WAI-ARIA tip #4: Landmarks

De-XPCOM-ing the Accessible module

XPCOM is used to communicate to the Mozilla core, getting information out of and into it from languages such as JavaScript, Java, Python and C++. Unfortunately, due to historic reasons, modules internal to the Gecko platform also used to use XPCOM to get information. One of these modules was (and partially still is) the Accessible module. XPCOM, while very powerful, also has some performance limitations when querying for a lot of information via QUERY_INTERFACE. Therefore, over the past couple of months, Alex and David have been working on de-XPCOM-ing our module to make it more performant and ready for the future.

To the end user, this will feel more performant especially on complex pages.

Event management

Firing events, and calculating when and how to fire them, has been a big performance killer for the Accessible module in the past. While this was for the most part not particularly noticeable for screen reader users, since we are sort of limited by the rate our synthesizers talk, recently more and more technologies have started using the Accessibility services. Fingerprint devices to enter passwords into Firefox, tablet PC interfaces etc., all use parts of the Accessible module. Since there is currently no way to turn parts of it on or off, as soon as any piece of software accesses just a single accessibility service, the whole engine gets started, and from that point on, all calculations take place as if a screen reader for the blind was present.

Again, since this cannot currently be selectively turned off, and it is not certain that this will ever be possible, it is our goal to make this fact the least noticeable to users. To that end, we’ve started a project called event coalescing. Event coalescing will, as the name suggest, coalesce the stream of events we get from the DOM to only fire those event assistive technologies absolutely need. However, the rules have not been finalized yet, and the code as it is in the current platform based on some initial ideas and feedback, is not very performant, in parts even less performant than in Firefox 3.6, which fires more events but calculates less before sending them.

For those interested in the very technical details, the wiki page for event coalescing is here.

HTML5 form element enhancements

While we’re working hard on improving performance, work in other areas of Gecko is also progressing, requiring us to work together to make sure these enhancements are also accessible. One of these is the work that needs to be done to make new additions that HTML5 brings to form elements accessible. I wrote up a summary with bug links and some information here. If you have feedback on the ideas and proposed roles, you’re welcome to contact us by leaving a comment down here or on the #accessibility IRC channel.

UI work

As the road to the next major release of Firefox is being walked, there are also some UI redesigns happening. One, which has already landed, was the conversion of the tab strip to a real toolbar. My job was to make sure screen readers can still cope with them after this change. Some minor regressions were found, but all in all this still works great.

Another, much bigger change, is the redesign of the Add-Ons Manager to include support for language packs, Jetpacks and other ways to extend Firefox. This work is still underway, and I recently took a first round of testing. Some keyboard navigation issues, and one XUL markup issue that needs to be addressed, but so far, although this is a major UI change, things look very accessible, and I’ll make sure it stays that way.

Other areas

Work that is not directly related to the Gecko platform, but which is also important in the field of accessibility, is, among others:

• Thunderbird 3.1 Beta2 has been released recently. Thunderbird 3.1 comes with the same platform version as Firefox 3.6. Due to the table enhancements in the Gecko 1.9.2 platform, the message list and other areas will be much more accessible to screen readers. Information such as the unread status, the presence of attachments etc. can now be queried using the IAccessibleTable2 interface or equivalent on other platforms. The control is now a real table control rather than a flat ListView on Windows, giving much more accurate semantics.
• The Instantbird team has also done a great job at providing good XUL markup in their multi-instant-messaging client. We’re currently working together to work out some very specific problems with buddy status and others, but Instantbird is a great multi-messenger worth trying!

As you can see, lots of exciting stuff happening, some of it very user-visible, other more technical and very low-level in nature, but all exciting!

Stay tuned!

Update: Article translation

Thanks to community member Patricia Clausnitzer, this blog post is now available in Belorussian. How cool is that! Thank you very much! And BTW: This is a first!

The Mozilla Foundation had a booth at CSUN for the fourth year in a row. David, Alexander Surkov and I were present to man the booth, talk to people, and also participate in a couple of general sessions at the conference to gather information and news, and also to network.

Adobe announces broad range support for IAccessible2

One of the biggest news bangs to come out of the conference is Adobe’s announcement to support the IAccessible2 and WAI-ARIA standards in thenext versions of their Flash and Flex products. Both these standards were heavily driven by, among others, Mozilla, IBM and several assistive technology vendors such as NV Access of the NVDA project. Support for the native GNOME and Mac OS X accessibility APIs is also in the works.

In addition, Adobe announced that they will also include IAccessible2 support in their Acrobat and Reader products.

This means that another big player in the software industry is coming forward and supports these widely recognized standards. It is good to see Adobe getting behind the over-all accessibility efforts and helping to drive adoption in this manner!

Three Firebug-related sessions

Hans Hillen of the Paciello Group had two very successful talks about the UI accessibility support in Firebug. The first was a demo of many of the features, using NVDA as the screen reader to demo them. the second was a use-case talk, where Hans explained in some more technical detail how he went about making the Firebug UI accessible to screen reader users.

Both talks were very well received. The first one had quite a broad audience, while the second audience was smaller, but very focused and involved.

In addition, Jon Gunderson of the University of Illinois at Urbana-Champaign held a talk on the Accessibility Testing Extension for Firebug. But unfortunately, due to my travel schedule, I did not have a chance to visit this talk.

It was good to see two Mozilla grantees doing talks at this year’s CSUN, giving visibility to the many facets of Mozilla’s accessibility strategy.

Newer mobile accessibility technologies marching forward

Apple, RIM and Google, the three vendors of mobile devices with well-defined accessibility APIs, all had well-visited talks at CSUN. In addition, I am aware of at least two talks involving the accessible iPhone and iPod Touch 3rd generation that put these technologies to good use to provide a new generation of assistive software, built on mainstream devices.

Well-visited booth

The Mozilla Foundation booth was well visited on all three days that I helped staff it. Comments and questions ranged from the very flattering “I love Firefox and I love what you guys are doing for accessibility!” to “What’s a browser vendor doing at this conference?”. When we then explained why we attended, many of them were keen on trying out Firefox when they got home or back to thheir hotel rooms.

Also, this conference made quite a number of people aware of other Mozilla products than Firefox. While many had heard about Firefox, they had not heard at all about Thunderbird before. But with the better accessibility in Thunderbird, we can now change this and spread Thunderbird in the accessibility community even more!

I personally had a very moving moment on Friday when a deaf/hard of hearing gentelman and his interpreter stepped up to our booth. He was very interested in what we do for accessibility. Before I knew it, I was talking to him through his interpreter, but wasn’t actually noticing it until well into the conversation. At some point, I mentioned Thunderbird, at which point he started joking about the Ford Thunderbird. David, who was present at this conversation, can probably tell a bit more about this, since this was very visual and I only got a third of what he was actually meaning.

David and Alex also took a lot of pictures, which they’ll hopefully upload and share very soon so you all can get a better picture about what CSUN 2010 was like! Mozilla received a big big chunk of good attention, our funding of other accessibility-related open-source projects such as NVDA, Orca and others, definitely is being recognized in the industry as being exemplary. Also, we got a very nice compliment from a gentleman from the Office of homeland security, who told us that he thought our Voluntary Product Accessibility Template is among the best he has encountered so far.

One big failure is there, though

One big problem, which I think should not go unmentioned, is the lack of good internet connectivity in the exhibition hall. For a 2010 information technology conference, having no useable WIFI connection down in the exhibition hall at all is simply unacceptable. The internet connections that were offered were hideously priced, almost like in the mid 1990s when internet connectivity was still not as common as today. Up in the session rooms, the situation was a bit better, at least there were hotspots one could use most of the time.

For next year, one thing I’d like to see is a well thought-through strategy for free wireless internet connectivity throughout all conference locations. A technology conference lives and breathes with the buzz people can create around it by tweeting, uploading pictures etc. People with disabilities are no exception, and instead of roadblocking it, the responsible powers at CSUN should embrace this trend and encourage people to get the word out as easily and hazzle-free as possible!

In summary

I can only say that it was worthwhile going to CSUN yet again, and I am hoping we’ll have a chance to participate next year as well!

This is primarily a warning to all screen reader users who read my blog that the only choice you have is to install Mozilla Firefox as an alternative to MS Internet Explorer. While you can, in theory, install the other browsers as well, and some of their marketing statements sound pretty shiny, none of them will work with your assistive technology!

As Steve points out in his post, none of the statements of what the browsers offer talk about accessibility or no accessibility. There isn’t even hidden text that would be visible only to screen reader users indicating something like “if you are a screen reader user, use only either Firefox or IE”.

I was contacted by our marketing team about the issue of accessibility, so I can say with conviction that we tried to bring this into the discussion. But for the EU, Microsoft and all other parties, this issue didn’t seem important enough to highlight. Thanks for this great service!

Please spread the word to your friends and warn them accordingly! You can help them avoid unnecessary frustration.

An example can be found at this German blog site. Look for the “Archive” heading, which is a clickable element that shows or hides the archive choices offered by this blog.

Right now,NVDA speaks this item as “clickable”, so the blind user already gets notified that there is a possibility here to press Enter on the item and something will happen. Now how cool would it be if, in addition, NVDA would tell me that something will be expanded, or is currently expanded, and I can press Enter to collapse it?

Fortunately, we have WAI-ARIA to rescue us from this desire!

The global attribute aria-expanded is used for exactly this purpose. It takes one of two values: true or false. true means a section that this element denotes is currently expanded (visible), false means the expandable section or items is/are currently collapsed (invisible). In the above example, aria-expanded must be defined, and by default set to false. In the Javascript that handles the expansion and collapsing of the categories, another code block must be added to touch this attribute and change its value to true when the categories are made visible, and back to false when they are made invisible. Since there is already JavaScript in place to handle the visibility of the categories, this can be plugged in very easily.

There is one more piece to this: Modern screen readers such as NVDA, Orca or modern versions of the commercial screen readers, can also make use of another attribute that tells which element is actually being affected. In this case, the list of categories. This is done through an attribute called aria-controls. The value of this attribute is the ID of the affected element and is set either once or whenever the controlled element changes. In this example, the value would point to the html:ul element with the ID of “archivliste”. The attribute gets set on the same element that also gets aria-expanded and does all the magic. Screen readers then know which element is being referenced, by something called Accessible Relations.

In summary:

• aria-expanded receives a value of “true” when the elements in question are visible. It is set to “false” when those elements are actually not visible.
• aria-controls is set to the ID of the top level element that gets made visible or invisible.

Both attributes get set on the element that actually does the magic (the same element that has the onclick handler or click/keyboard event listener).

[Update] One word about placement of the expandable items: Ideally, they should be following the item that expands and collapses them, as can be seen in the example above. The list of archive months follows the heading that has the click handler to expand and collapse it. The result is that screen reader users can expand the items and simply down arrow without having to look for the new content. This makes it feel very natural and efficient.

Also, some screen readers have intelligent detection of dynamic changes and speak them automatically. This is sort of what WAI-ARIA live regions do, but without the explicit live region markup. The result is that upon expansion, the new items might automatically be spoken, which might be undesirable. For example, this list of months would be very undesirable to be rattled off by the synthesizer whenever the list gets expanded. To prevent this, another attribute can be applied, aria-live with its value set to “off”. This prevents supporting screen readers from ever treating this particular region as a live region. This attribute, however, in the example above, would go on the html:ul element, not the element that expands and collapses the list.

Thanks to Aaron Leventhal for these two excellent points![/update]

Previous Easy ARIA Tips

1. aria-required
2. aria-labelledby and aria-describedby
3. aria-invalid and role “alert”
4. Landmarks

Exposing HTML 5 audio and video elements

The initial exposure for the HTML5 audio and video elements to screen readers landed, causing a minor regression that was quickly fixed. In testing this with NVDA, I found that the button labels weren’t properly exposed and that the slider values were not really useful. The progress meters were showing the number of bytes downloaded, or the milliseconds elapsed instead of useful percentage values. Along those lines, Alex also added a bug to expose proper names for each progress meter, so a screen reader user knows which slider is for what purpose.

Except for the last patch, all others have landed on mozilla-central and will be available for testing starting with the 11th of May nightly build.

To make it clear: This is for those HTML5 audio and video elements that have the controls attribute set, indicating that the internally available controls should be used. Other forms of controlling the media playback, such as from external HTML controls/widgets, already worked in the past since these were not part of the actual audio or video element itself.

Tree view item rectangle exposure

We received a report that in Thunderbird 3 beta on Windows, the rectangles for tree view items were not exposed correctly. The rectangle was too small, not encompassing the whole item. Alex investigated this and fixed the bug, putting an optimization in as a second step for all platforms. This also landed on mozilla-1.9.1 after having baked on mozilla-central for a while, and is available since the May 9th nightly builds of Shiretoko, Thunderbird and SeaMonkey.

The ARIA live region background tab leakage

David has been taking different stabs at bug 444644, with some good results thanks to feedback from Roc and BZ during the Mozilla all-hands week. However, we’re still fighting a situation where the creation of virtual buffers by NVDA is causing the live region updates from background tabs to be spoken again. Investigation is ongoing

Other ARIA-related triage

David’s also been a busy bee clearing out some ARIA-related bugs, gathering feedback here and there, closing others as they’ve been solved by other bugs, etc.

Firebug accessibility

This is not strictly inside the “Accessible” module of the platform, but very closely related to the Mozilla eco system. Accessibility of the Firebug UI has been shaping up very nicely over recent weeks. I spent a fair amount of time last week pounding the different alpha releases to help make sure things stayed in shape.

On Friday, Hans from the Paciello Group, Jamie from the NVDA team and I also managed to get the biggest outstanding problem solved in a very productive meeting on IRC, and that’s the reading of the Firebug JS panel by NVDA. Watch this space for a review once Firebug 1.4 goes to beta!

That’s it for this week, thanks for the read!

In Firefox 3.0.x, we expose the screen text, in this case the word “regression” as the accessible name. This is the piece that screen readers speak when focus lands on the link, and which usually also gets rendered into the virtual buffer.

If there is also a title attribute, in this case “@title attribute no longer exposed on accDescription”, this will be translated into the accessible description of the link object. This is additional information that can be spoken by the screen reader on demand. For example, in NVDA, focus the link or arrow to it in the virtual buffer, and hit NVDA+Tab. NVDA will speak first the name, followed by the fact that this is a link which is linked to something, followed by the description.

The one exception where we do not expose a description is when the screen text and title attribute contents would match. This is considered bad practice anyway, because it is redundant information, and thus we suppress it.

Firefox 3.5b4, and in fact all builds that date back to mid October last year, have a bug in that the title attribute is no longer exposed as the accessible description. Jamie from the NVDA team found this recently and notified us.

I’m happy to report that this functionality got restored in the Firefox 3.5b5pre nightly builds starting with the May 7, 2009 build. Sorry for any inconvenience this may have caused!

Actions for sorting and expansion/collapsing

After some minor setbacks, David’s patch on exposing actions for ARIA sort and expand/collapse attributes finally landed today. This means that:

• An element that has aria-sort set, will expose an action of “sort” to assistive technologies.
• An element that has aria-expanded set to “true” will expose an action of “collapse”, one that has aria-expanded set to “false” will expose an action of “expand”.

These can be used to exactly determine what action will be performed once it is being performed.

Exposure of the HTML5 audio and video element controls

Alexander’s patch to expose the embedded controls of the HTML 5 video and audio elements has landed on mozilla-central. With NVDA, one can now see the grouping where the controls are, and invoke the action on each of the buttons. One can even switch to focus mode on the sliders and use the arrow keys to manipulate them. Note: Due toa different approach in reading our information, JAWS does not yet expose these controls despite this patch. Other screen readers are pending tests.

There are a few problems still which will be addressed soonish: For one, the buttons don’t have text labels yet, and the slider percentage values reflect times rather than actual percentages, so we need to see how we’re going to expose this properly.

In other news

The team, along with a number of community members, has worked on a new high-level accessibility strategy document. Frank Hecker has a blog post explaining this in greater detail.

Spreading the good work of ARIA to mainstream open-source CMS

Peter Krantz, accessibility expert from Sweden, has started an effort to contribute WAI-ARIA landmark roles to mainstream open-source content management systems. If you know one of the CMS that don’t have patches yet, feel free to jump in!

That’s it for this week, see you next week for a new edition!

In the version that is currently on addons.mozilla.org, there are several problems with missing label7control associations in the Options dialog as well as problems navigating the tree, and more importantly, opening a feed article via the keyboard.

Not too long ago, I contributed a patch to the project to fix these problems, and Chris has accepted it and put it into a recent beta version of Feed Sidebar. He also made it possible to access the sorting options from the context menu.

The latest beta brings a better updating mechanism that is less resource hungry.

For those of you who have asked me about a way to view feeds in a tree like structure, this is definitely worth a try! Go download the latest beta version here! I’ve found it to be very stable and accessible. Of course, feedback is welcome! You can either contact Chris directly of course, or leave a comment here, I’ll then forward it to him.

Enjoy!

This article can be found on the front page of my blog under the “Pages” section, in the “Articles” sublist.

The article is meant as an introduction, not as a replacement for the NVDA user guide, and it is certainly not meant to replace other accessibility testing tools you might use for your website testing, just as an additional tool to help you get a feel for how blind users interact with your web sites or web applications.

I plan to update the article periodically as new versions of NVDA become available, features are added and other info relevant to the article might change.

Enjoy the read, and feel free to leave feedback!

In the e-mail exchange that ensued, two positions became apparent:

• On the one hand, it was stated that blind people prefer the exchange through mailing lists highly over any other means of exchange possible on the net today, and that this is the easiest to access medium. This has a lot of merrit, since to subscribe to most e-mail lists, you don’t even need a web browser. If you know the mailing list address, you can send a subscribe request and acknowledge that by only knowing how you compose and reply to e-mails in your favorite e-mail program. Forums, on the other hand, are often secured against spam bots by CAPTCHAs, and the display is considered by many to be highly inefficient for reading. Newsgroups are somewhere in the middle, with the strict insisting on the netiquette by “usenet cops” being what drives new users away from this medium mostly.
• On the other hand, David and Kadir advocated for Sumo and the German firefox-browser.de community forum respectively, stating that support personell and volunteers and most community members frequent Sumo and other forums highly, but hardly any mailing lists. On IRC, Kadir and I talked about this as well, and others who chimed in even used words as strong as “hate” when it came to the topic of mailing lists.

I did some research, and found quite some diversity in who uses which medium. For example, among Mozillians, mailing lists, which are mirrored to newsgroups and Google Groups, are the most frequented way of doing development planning discussions, project-specific exchange etc. With mailing lists on one hand, and an almost forum-like display at Google Groups on the other, this is a very cross-over way of offering access to the groups. But one does not see many end users here. There are support-like newsgroups, but compared to the number of users we now have, the traffic is comparably low. The MozillaZine forums enjoy very high traffic by comparison.

In other areas, I found the same picture. The more end-user, the lesser techy, the more popular web forums are. The more techy, the more things take place in mailing lists rather than forums. Granted, most mailing lists have a web-accessible archive nowadays. But even that’s controversial: In the above mentioned IRC discussion, one person I’d consider to be rather technically versed mentioned that he hates mailing lists and the typical Mailman archive format on the web because it shows only one post at a time, requiring him to click constantly to read through a thread.

Interestingly enough, in the recent screen reader survey results published by Webaim, web forums were not mentioned in either list of web sites, neither particularly accessible nor particularly inaccessible.

So, what is it that makes so many blind people go to mailing lists instead of web forums, sort of contrary to most of the main stream on the internet today? Are web forums inherently inaccessible? Or, is this one of those things that sticks around while the actual picture has changed, but the blindness community simply has failed to notice?

Provocative questions, I know. One of the things that drives blind people away, and which also drove me away from forums for a long time, is the spaghetti-ish nature in which many, especially older, forum software displays threads. It is very hard to find the beginnings of posts, making it difficult to skip over a reply that is of no interest. As blind people cannot visually skim forum topics like sighted people can, this is essential to efficiently navigate and participate in forums.

Here are some examples of forum post views that may give some clue as to where this resistance to use web forums amongst the blindness community may come from, and where it may also no longer be justified:

• In this thread on the MozillaZine forums, each reply starts at a new item in the definition list that is used to display the topic. With the other lists inserted to encapsulate the “Reply…” and other info/action possibilities, simply jumping from list item to list item, as one would first expect, does not really get you quickly to the start of the next post within the thread.
• This thread on the phpBB community forum shows a nice way to do things: Each reply starts at an HTML heading element, making it very easy to skip forward if one doesn’t want to read the rest of the current reply. Since both phpBB.com and MozillaZine use phpBB, this seems to be a question of theming the forum.
• Also based on phpBB, but on an older version, is this example from the German DelphiPraxis community forums. This is what I referred to as the spaghetti view earlier that drives me and others away from forums. It’s a tabular layout, done with HTML table and descendant elements, and each post within the thread simply gets its own new row. Most screen readers do offer a way to navigate tables by row, but the keystrokes for doing so are much more cumbersome, requiring usually both hands to execute them than is good for casual reading or browsing. Table navigation is made for consciously interacting with data tables. I have seen similar table-based constructs in both VBulletin-based forums as well as the Carookee.com forum service.The German firefox-browser.de community forum uses a similar display right now, however this will probably change once they upgrade to phpBB3.
• Looking at bbPress, the companion to the WordPress blogging software, they use a similar list-based display style as MozillaZine in terms of markup, but no intermingled lists, allowing to quickly skip ahead to the next post if the current one doesn’t interest me.
• Lastly, the Sumo forum display shows a series of divs that are used to show the posts within a certain topic, but no special semantic markup to help navigate from one post to the next within an individual thread. It is similarly spaghetti-ish right now, with the difference being that it uses divs instead of layout tables.

Disclaimer: The topics chosen above and the comments made about the quality of the individual display styles is not meant to reflect on the quality of the forums themselves. They’ve merely been chosen for illustration purposes in the accessibility context of this blog.

As the display of the phpBB community forum post shows, there are possibilities to choose really accessible forum themes and create an attractive forum that also blind people might like to use. However, there’s also still a lot of forum software out in the wild that does not conform to any modern accessibility standards and thus offers a rather unattractive accessibility experience.

Also, one thing that I briefly mentioned are CAPTCHAs. Fortunately, with Firefox 3 and WebVisum, these are solvable for blind users. Or audio CAPTCHAs are spreading more and more, making this a barrier that is possible to deal with given the proper tools.

And now, I’d like to hear YOUR opinion on this topic! Do you prefer forums over newsgroups or mailing lists? Do you prefer to read on the web or in your e-mail client, in your RSS reader? Do you easily keep up with where you left off reading in a certain thread? What are the challenges you’ve faced dealing with forum software in the past or present?

On the other hand, if you’re a forum user and don’t like/use mailing lists, why is that? What do you find more attractive about forums that makes you not like mailing lists, or even hate them?

Welcoming your comments!

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.

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.

• a fix for one of our top crashers, which also landed on the mozilla-1.9.1/Firefox 3.5 branch. We need to see if the crasher count on this one and a few derivatives goes down now. Thanks Ginn for digging into this one!
• a stability fix for a certain test suite that David found.

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.

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.

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!

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.

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.

Enjoy!

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:

• The change from aria-grab to aria-grabbed
• The removal of role=”description”
• Some urgently needed fixes for when the document node gets an ARIA role
• Some infrastructural changes and fixes to which ARIA roles can receive what states, and what these states should be

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!