Posts Tagged ‘Accessibility’

NVDA 0.6p3 released, quite some news for Mozilla users!

Monday, February 16th, 2009

As you may or may not have read, the NVDA team released NVDA 0.6p3 last night. Below, I’d like to highlight those of the changes that are of special interest to those using Mozilla products such as Firefox or Thunderbird with it.

Support for text attributes and spell checking

NVDA takes advantage of the new text attribute and spell checking support of Gecko 1.9.1, which will enable exposure of the inline spelling features of Firefox 3.1 and Thunderbird 3.

  • NVDA+F will report things such as font, point size, styles such as bold etc.
  • When reading through text character by character or word by word, if a spelling mistake is encountered, NVDA will announce it, and also where it ends.

This feature will not work with Firefox 3.0.x, as the version of the Gecko platform used with this version of Firefox does not have accessibility information for text attributes and spell checking.

Automatic switching of focus mode

When browsing web pages in Firefox, certain controls such as textboxes, comboboxes etc. can now automatically cause NVDA to switch to focus mode without the user having to press Enter. Escape or NVDA+SpaceBar can be used to turn focus mode off and browse mode back on. Interacting with forms is much more seamless this way, so I recommend everyone to try out this new mode! You can configure it through the Virtual Buffers preferences dialog.

Better reading of the notification bar

Firefox, and to a lesser extent Thunderbird, make use of the notification bar to convey information without interrupting the user’s flow of work. NVDA 0.6p3 has improved the way it reads these important yet unobtrusive notifications by suppressing double-speaking, and other tidying up of the whole process.

Use NVDA to explore the accessible hierarchy of your web pages

From the What’s New document:

* new: In virtual buffers, the review cursor now reviews the text of the buffer, rather than just the internal text of the navigator object (which is often not useful to the user). This means that you can navigate the virtual buffer hierarchically using object navigation and the review cursor will move to that point in the buffer.

This means that the navigator commands (NVDA+NumPad8, NVDA+NumPad2, etc.) will work inside the virtual buffer of a web page, take the review cursor with them as you go, and allow you to bisect your page accessible node for accessible node, in case you wonder why your users complain about accessibility issues.

This makes NVDA not only suited for blind users relying on access to the Windows operating system and its applications, but also for web developers who need (or want) to get a feel for what their web page or application appears like to a blind visitor.

Miscelanious fixes

The below is a small collection of other notable changes that don’t warrant an own section.

  • fix: Fix the issue where tabbing to a checked checkbox in a Mozilla Gecko virtual buffer and pressing space would not announce that the checkbox was being unchecked.
  • fix: Correctly report partially checked checkboxes in Mozilla applications.
  • fix: When reading with the mouse, text in Mozilla Gecko edit fields should now be read.

In Summary

If you run the beta or nightly builds of both Firefox 3.1 and Thunderbird 3.0 AKA Shredder, you should be able to take advantage of all the new features in NVDA 0.6p3. If you use Firefox 3.0.x, you’ll be missing out on the new spell checking and formatting feature, and if you still use Thunderbird 2, most of the good support for Gecko 1.9 and above will not be available to you since that version of Gecko doesn’t work well with NVDA any more.

Go get it, and give it a whirl!

What should the action name for an indeterminate checkbox be?

Wednesday, February 11th, 2009

As noted in this blog post, we’re currently working on implementing the accessibility for HTML 5 checkboxes that are indeterminate. An indeterminate checkbox is a checkbox that is neither checked nor unchecked, or half-checked if you will.

The first stage is complete: Firefox 3.2a1pre as of Wednesday’s nightly will expose such indeterminate checkboxes as what we internally call STATE_MIXED. There are still two work items left as far as we can see:

  1. Expose an action name for a checkbox that is in this indeterminate state.
  2. Make sure we fire STATECHANGE events for STATE_MIXED.

For action item 1, I’d like to call out to you guys to offer suggestions on what this action name should be. My initial idea is “toggle”. The reason is that we will never know whether the next state after clicking will be fully checked or fully unchecked. That always depends on the web site’s author to decide. That’s why I first thought of this neutral name.

Anybody got any better ideas, or even a suggestion derived from other such indeterminate, or tristate, checkboxes from operating systems? Post your ideas here or comment on the bug.

Implementing a new feature in Gecko that may have an impact on accessibility? Ping the accessibility team and tell them!

Monday, February 9th, 2009

This morning, Jeff Walden pinged me on IRC to ask me whether the new indeterminate DOM property for checkboxes that is being introduced in HTML 5 and which recently landed on Mozilla 1.9.2, has any accessibility implications. I did a quick check, and it indeed does have an implication: We don’t expose the partially checked checkbox state properly for html:input @type=”checkbox” yet.

Jeff then filed a bug on the issue, and I took on the task of exposing the correct state. It turns out to be a small fix that is needed to expose this extra state, so hopefully in a few days the sample page will work correctly in the nightlies.

This shows the importance of collaboration between the various backend and frontend teams and the accessibility team. Jeff was unsure, so he asked, and we “attacked” the problem right away, before it became a real problem, in the sense: We potentially release a product that has this not unimportant issue.

So if you implement something new in Gecko like new HTML 5 features, and you are unsure whether there could be any accessibility issues involved, I strongly encourage you to ping surkov, davidb or myself (MarcoZ) on IRC or shoot us an e-mail, or ask in the mozilla.dev.accessibility newsgroup. It may turn out to not be an issue, which is good. Or it may turn out that we have a work item to take care of, which is also good since this is not going to bite us out of nowhere in the future. Also, when the implementation is still new, we’re more likely to have the right fix in place with all memories still fresh.

Asking never hurts, so just ask once too often rather than once too less!

Accessibility fix in 3.0.6

Wednesday, February 4th, 2009

As you may have read already, Firefox 3.0.6 was released on Tuesday. Among the fixes introduced in this version is one for accessibility. It has to do with CaretMoved events and selection changes not being communicated to screen readers properly in the past.

One immediately visible change is that, when you open ChatZilla, the accessible IRC client extension. Previously, your screen reader would have told you erroneously that your focus was in the textbox where you type your message, when it was actually on the output HTML content.

Also when selecting text, you should now get more accurate results under many circumstances than before.

These changes should have a positive impact on all supporting assistive technology.

Enjoy!

New feature: Nesting level and position information for HTML lists

Tuesday, January 6th, 2009

The new year has just begun, and we’re already speeding ahead with new features in Firefox trunk nightlies, AKA version 3.2a1pre. These features won’t see inclusion in Firefox 3.1, but are already the next generation features.

The feature I’m going to report on today has to do with position information and nesting level information of ordered and unordered HTML lists.

To give you an example:

  1. Apples
  2. Oranges
  3. Bananas
    • Apples
    • Bananas
    • Oranges

As you can see here, the unordered list is nested within the ordered list. The ordered list has a level of 1, the unordered a level of 2. Also, in case of the unordered list where a number is not provided, there is still an item count that we expose.

The information is exposed in a similar manner as listbox items, combobox entries, or TreeView element information. We have the following object attributes:

  • posinset – to specify the position within the set
  • setsize – the size of the set of items
  • level – specifies the nesting level

We also specify level and position information in the AccessibleDescription for convenience of screen readers that don’t use object attributes yet. So, the inner “Bananas” item has a description of “L2, 2 of 3″, just like a TreeView item would.

But my screen reader already has nesting level and item count information, so why bother?

Well…Because we’re nice! :-) We save newly supporting screen readers or those that don’t want to calculate these values themselves the trouble and do it for them. We know the underlying HTML anyway and can provide the information while building the accessible tree. There is no need to go in and calculate these items yourself any more, or you don’t even need to start doing it. Just use our values if you want to give your users this information.

NV Access published their progress on the Mozilla Foundation grant

Tuesday, January 6th, 2009

The new year starts out with a bang! NV Access, the makers of theNVDA, a free, open-source screen reader for Windows, have published their progress report on the current Mozilla Foundation grant. The grant goals were laid out for a three year period, and look what was accomplished in the first year alone! Mick and Jamie, you rock!

Firefox 3.0.5 accessibility: New features

Wednesday, December 17th, 2008

Firefox 3.0.5 has just been released, and as the release notes mention, brings a few accessibility improvements. Here’s what they are!

  • Firefox 3.0.5 exposes all CSS display properties as object attributes now in addition to the older “formatting:block” parameter. However, the “display” object attribute values are more granular, mirroring the exact display attribute that is present on the accessible node. The only exception is display: none, for which we usually don’t create accessibles. Assistive technology vendors can use this new “display” object attribute to more exactly find out how certain objects blend in with others, are formatted etc. Firefox 3.1b2 also supports this, in fact this change has been “baking” on the Firefox 3.1 branch for quite a while already, and has now been back-ported to 3.0.5 for better compatibility.
  • There was still a problem left that certain types of elements could not take the focus when instructed to do so. This resulted in some elements not being activated when trying to do so from within virtual buffers.
  • For those screen readers not using IAccessible2, but using the iSimpleDom interfaces, a bug has been backported to 3.0.5 that would not properly handle the request to return the computed styles of an element. This should allow those assistive technologies using iSimpleDom interfaces to get more accurate style information out of nodes in Firefox 3.0.5, as they already can in 3.1.

Thanks to everyone who is continuously giving us feedback on our accessibility implementations!

Starting an Accessible Name refactor, need your help in testing!

Saturday, October 11th, 2008

For those of you following the Firefox/Gecko platform development, or for those interested in helping out, this is a call for participation. If you’re not afraid to get your hands dirty a bit and would like to help the Firefox accessibility team, now would be a good time to get involved!

The problem: The code that calculates the names for any created accessibles has been growing over time and became largely unmaintainable. New features suich as adding the aria-label property support requires code duplication for HTML and XUL, and in general the code has many stylish un-niceties.

So, our team has started a code cleanup and code refactoring series to get the code into better shape and maintainability.

As with any refactor, the result should be identical in output with what we started out from. However, as those of you familiar with software development know, the risk of regressions is there and should not be discounted.

While we do have test cases for many of these instances already, there may still be cases we’ve missed. So any help we get from the community will help make sure that the refactor goes smoothly, but also help fill in any possible gaps in our testcases.

So, how can you help? By downloading and installing the latest nightly builds of Firefox 3.1 for Windows or Linux, and testing the heck out of them. Use your favorite screen reader, use your familiar web sites, use it for day-to-day surfing. Obviously the most likely pages you’ll find differences on, if any, will be those pages you visit frequently, sites you know what the output should be.

If you find something that is different from what you know, you can download the last Windows or last Linux build before the refactor, unzip it into a separate folder, and compare your findings using that build.

If you find differences you did not expect to find, you have two main choices that will get the developer team’s attention:

  1. File a bug in Bugzilla:
    • Component: Disability Access APIs
    • Version: Trunk
    • Platform: PC or whichever you use
    • OS: Windows or Linux, depending on where you found the bug.
  2. Post a message on the mozilla.dev.accessibility newsgroup (Google Groups mirror).

In any case, your bug report should contain the URL of the page you are experiencing the difference with, the expected output of the element, and the output you’re now getting. Also, is that element a graphic, link, heading, form field etc.? Also, you should mention what screen reader you’re using. If posting to the newsgroups, it will also help to mention the operating system.

How to update the nightly builds to pick up latest code changes: The builtin Check for Updates feature, if invoked from a nightly build, will always grab an update to the latest nightly build and install it for you. So, you only need to download and go through the installation process once. You can then daily check for updates and get the latest code that way.

The first build to see changes will be the October 11 build, build ID 1.9b2pre/20081011.

Working with different profiles: If you don’t want to put your regular profile into the hands of the Firefox nightly builds, you can start Firefox.exe or the ./firefox executable with the -p option to bring up Profile Manager. You can then create a new profile and start Firefox with that profile. That way, your Firefox 3.0.x profile won’t be touched by the 3.1 nightlies if you choose not to. I’ve found, however, that the nightlies are very stable already, and I often flip back and forth between 3.0.x and 3.1 builds on the same profile without problems. The one thing that most certainly would happen is that some extensions may not work in 3.1 yet.

I’d like to thank all of you in advance who decide to participate in this effort and help everyone who relies on Firefox accessibility by testing out the code refactor. You can make a real difference because we obviously can’t test all of the web pages out there, and yours may just be the one we might miss out on.

Why I would not buy an iPod just yet

Wednesday, October 1st, 2008

Recently, Apple announced better accessibility features in iTunes 8 and the 4th generation iPod Nano. This is a major breakthrough in accessibility because now, the maker of a mainstream hardware media player is taking steps to make sure the device is useable also by people with vision impairments. Previously, the only way to make certain types of MP3 players accessible was through projects like Rockbox, which provides a custom firmware for these players. This approach is never fully complete, because for the supported iPods, it does not allow the very specific features to work like DRM-protected media playback.

On the other hand, there are new approaches taken by assistive technology vendors such as HumanWare who manufacture new, modern devices like the VictorReader Stream, which is both a DAISY (Digital accessible information system) and Audible audio book player, and also an MP3 and Ogg Vorbis player. The revolutionary element of this is that it comes with a speech synthesizer, bilingual if you so choose, to read the titles or meta information of your MP3 or Ogg files to you.

The question I was asking myself when I read Apple’s announcement was if this now obsoletes such hardware specifically designed for the blind. And the answer came quickly, too: We’re not quite there yet. And unless Apple and other hardware manufacturers of mainstream players are ready to include blindness specific, or seemingly blindness specific, features into their players, there will always be a place and necessity for these specialized hardware devices.

I also asked myself whether I would choose a Stream or an iPod if I wanted to buy a new portable media player today. I already own a Stream, bought it in March of this year, so am in no immediate need to purchase a new device. And after some thinking, I came to the conclusion that a Stream today is still the better choice for me and possibly other blind users. Here are the reasons why I think this is the case.

More flexibility in speech output

The Stream offers in its firmware bilingual voice synthesis output. One is always English, the other is the language of one’s choosing. Since I am German, in my case a German voice is also on board. This allows me to listen to the meta data or file names of both English and German books or media files without having to compromise on one end. Apple’s approach, to synthesize the menu items and file names on the host computer via the speech APIs is monolingual. In other words, if I choose to synthesize the samples in German, all my English language MP3 meta data will also be read to me with German pronounciation rules, sounding a bit awkward.

No purchase of a speech synthesizer required

The speech synthesis voices are on board when you purchase a Stream. With the iPod solution, you are required to purchase at least one additional Microsoft Speech API 5 voice from somewhere. Granted, users of the JAWS screen reader are in luck, since Freedom Scientific ships RealSpeak Solo voices in multiple languages with their JAWS 8 and 9 releases, which can then be used to synthesize the menu prompts and file data. But others are required to purchase synthesis engines for varying prices to get the same functionality. And to be honest, I wouldn’t want my iPod to speak to me in the Microsoft Sam voice. If you’re using XP, open Control Panel, and there the Speech input/output panel, and let the default voice speak a sample to you. You’ll know what I mean… :-) And the voice selection on Vista is only slightly improved over that. And they’re all English only.

Support for DAISY audio books

The Apple iPod does not support the playback and navigation options that a modern dedicated DAISY player offers. DAISY books can be listened to in MP3 format, but no navigation among headings, phrases or the like is possible without the additional meta data present in DAISY books. Since one paradigm I live by is to always have the greatest flexibility when getting my content, I would not want to limit myself by excluding the possibility to read DAISY content.

Since more and more mainstream download shops also offer DAISY audio books now, bringing this format out of the niche of blindness-specific libraries, it is my hope that mainstream music players will soon adopt this format, too, and offer a wider choice in this regard.

Support for the Flac and Ogg Vorbis formats

OK, this is a strictly personal opinion: I prefer to rip my CD collection in Ogg Vorbis format, since I feel it is substantially superior to MP3. The iPod does not support Ogg Vorbis even in the latest of their devices.

Support for various text file formats

The Stream can read various types of text files to me: Plain text, HTML and XML, RTF, and even some types of braille formatted files, using its on-board speech synthesis engine.

Notetaking feature

The Stream allows me to take notes using either an external or the built-in microphone. Depending on the memory card that’s inserted, I can even record whole presentations with this. Granted, this, like the previous one, is a very specific feature, but an essential one for blind users. Quickly being able to record something without having to fiddle with the notetaking facility of one’s mobile phone is even more efficient than grabbing pen and paper to take a note.

More flexibility in memory usage

The Stream operates using standard SD or SDHC memory cards you can buy in any store, giving it virtually unlimited memory capacity. The Apple iPods have their Flash memory built in, restricting one to 8 or 16 gigabytes (in the case of the 4th generation Nano). In addition, because these speech prompts get copied to the iPod to make it accessible, using up memory as well, which counts against your available music storage space.

Freedom of choice when purchasing digital content

With the iPod, one is bound to Apple’s iTunes software and music store. Even though there is also DRM-free content available, the vaast majority of content is protected, and encoded in the not too impressive 128 kbit/s Aac format. For the record: Other music stores use protected 128 kbit/s Windows Media Audio (WMA) format, which I find equally unimpressive. If I purchase music for download, I usually go for DRM-free, high quality MP3 format. If I don’t find it, I go to Amazon and buy the CD to rip it in my favorite Ogg format. Call me old-fashioned, but I’m a guy who prefers to purchase whole albums rather than individual tracks. Feels incomplete somehow.

The Stream offers me that flexibility, the iPod limits me in that it won’t accept my Ogg files and requires me to always use Apple’s music store, or use iTunes to copy files across. Using the Stream, I can simply insert the SD card into my reader and copy the files over using my preferred file management tool, reinsert the card into the Stream, and off I go.

Do you have no arguments for the iPod in store?

The only thing I can currently think of is the price. The Stream costs about twice as much as the more expensive iPod Nano 4G with 16 gigabytes of memory.

One other argument some might think of is the trendiness of the device. For a blind person however, other than the feeling that one might look trendy, that should never be a criteria to choose a device. Granted, the Stream looks a bit–and I cite a friend’s 8 year old son–like a mobile phone of the mid 90′s, with its speaker and mike and the rather big keys and the edged case. The iPod for some might indeed have a much nicer form factor.

Looking at other features the iPod offers, I can only say that viewing fotos is sort of beside the mark, and being able to watch videos is only interesting if one wants to buy or rent TV shows or movies from the store. If you record from TV or have DVDs, there are always ways to extract the audio only, which is enough for a blind person.

Having said all the above, I’m not saying that Apple’s move was a bad one or that this is an invain endeavor. I can only repeat that I find it fantastic that Apple has taken these steps, and can only encourage them to continue this venture, and encourage others to follow this example. The more choice everyone has, the better.

And if someone from Apple reads this and thinks of making me a Christmas present, I’d be very grateful for the gesture, and write a positive review on my blog. :-)

Firefox 3.0.2 has been released, lots of accessibility improvements

Wednesday, September 24th, 2008

As was announced on the Mozilla blog, Firefox 2.0.0.17 and 3.0.2 security updates are now available. In addition to the security fixes, there have been a couple of significant accessibility improvements made to Firefox 3.0.2 that I’d like to give you all a heads-up on.

  • Firefox 3.0.2 is now compatible with JAWS 7.10. In an effort to make Firefox accessible to the widest range of users possible, we’ve identified and fixed a problem that prevented Firefox 3.0 and 3.0.1 from working with JAWS 7.10. If you previously tried to use Firefox 3.0.1 with JAWS 7.10, you would get a crash in Firefox almost instantly after launching it.
  • Similarly, we’ve identified and fixed a problem that prevented proper interaction between Firefox 3.0.1 and the public beta of JAWS 10. With some elements, if they were made visible dynamically, JAWS would not be able to pick them up correctly.
  • Fixes were put in for the doAction and doDefaultAction methods to allow clickables and some other elements like the “Compose” link in GMail to be properly activated by some versions of some screen readers. We previously had a bug that prevented these elements from being activated through the virtual buffers, requiring users to use mouse emulation to activate these elements.
  • Elements within a map element that were not images would previously not be rendered to any screen reader by Firefox. This has been fixed.
  • A random crash that occurred with some layout tables was fixed.
  • And a couple of API fixes were also made to ensure better compatibility with assistive technologies on both Windows and Linux.

I recommend you update to Firefox 3.0.2 as soon as possible to be able to take advantage of these and the other fixes that went into this release. Enjoy!

WebVisum had to switch to an invitational registration system, I can give out invites!

Wednesday, August 27th, 2008

As you may have read on the WebVisum website, the team had to switch to an invitation-based registration system. The spambot abuse attempts became such a toll on the team after such a short time already that they were forced to take this step.

However, all is not lost with this step! There are already a lot of WebVisum users out there who can invite others. So if you are not a member of WebVisum yet, but know someone who is, ask them for an invitation!

If you don’t know anyone who might have a WebVisum account already, but are reading this blog and want to try it out, please send me private e-mail at marco dot zehe at gmail. I can send out invitations so you can benefit from the CAPTCHA solving, graphics recognition and other great features this Firefox extension offers.

Further reading

Jim Zemlin on this year’s breakout of the Linux desktop

Wednesday, August 27th, 2008

Jim Zemlin of the Linux foundation wrote a very good post on this year being the year of the Linux desktop breakthrough. One thing he did only mention marginally, but which I think is just as important for certain users/markets, is the fact that there is now a wide range of accessibility solutions available for at least the GNOME desktop, which either come directly with the distribution such as the Orca screen reader for the visually impaired, or are easily installable. Screen reading, which includes support for a huge variety of braille displays, magnification, on-screen keyboard solutions, alternative input device support are all available as open-source now and open up the Linux desktop alternative to virtually every potential user.

And there’s more when it comes to the mobile platform. The Mozilla Foundation funded a feasibility study last year to migrate the communication layer for the assistive technology service provider interface (AT-SPI) from using Corba to using DBus, which is a key part in getting screen reading support on the mobile Linux platform. Nokia is now funding the actual migration work. I’ll blog more about the mobile prospective from an accessibility standpoint in the near future.

JAWS 10 public beta’s Firefox 3 support: A review

Tuesday, August 26th, 2008

In the August issue of the “FS Cast” podcast, Freedom Scientific announced the soon-to-be expected availability of JAWS 10 public beta. They also demoed many of the new features, like the automatic forms mode switching. They also mentioned that they improved Firefox support a lot and that the web should feel transparent now regardless of which of the supported browsers the customer would be using: IE or Firefox. ARIA support, also with an emphasis on live regions, was mentioned, too.

The public beta was released on August 25, and I took it for a test ride. Here’s what I found:

In general, the display of static pages has improved quite significantly over previous versions of JAWS. Especially text being run together with certain HTML constructs is no longer an issue. Missing line breaks are a thing of the past now, too. This makes the over-all reading experience much more pleasant.

One big plus I also noticed is that, when you open a link and then later return from the newly loaded page using Alt+LeftArrow, JAWS correctly sets the virtual cursor to the link you activated. It used to put the virtual cursor at the top of the page.

The automatic forms mode switching works on textboxes and textareas, but Alt+DownArrow on a combobox does not pop into forms mode and open the listbox yet, as was demonstrated in the podcast using IE.

Speaking of listboxes: JAWS 10, unlike 9, shows all items in an HTML listbox (a select with size greater 1). It used to only show the selected entry. In IE, it still does that, but in Firefox, it dumps all the items into the virtual buffer. If you have a list of over 100 items, this can become very annoying.

In terms of ARIA support, there are clear signs that work has been done on this front. For one thing, JAWS now honors the ARIA role of “application”, which means it does not go into virtual PC cursor mode on such pages or in properly marked-up web application environments. An example can be seen here.

Also, live region updates are nicely read on this page.

However, there are also still quite some areas where both ARIA support in general and live region support in particular should be improved before final release. Here are some points where I am still seeing problems:

  • While the live region support works great on the above page, it does not work at all in the ChatZilla Firefox extension. ChatZilla uses an HTML table with role of “log”, and both “polite” and “assertive” live regions. JAWS currently runs all the text inside this table together in one big string, without line breaks. Also, markup such as links inside these chat output messages is completely ignored. While JAWS 9 didn’t support live regions yet, it did properly format the output into a very readable form. As a plus: Updates to the view are now automatically picked up, which was not the case in JAWS 9. There, you had to constantly refresh the virtual buffer to see the newest messages.
  • Live Region support in Google Talk, as I describe in my ARIA in GMail
    #2
    post, is flaky. Sometimes new text that comes in gets spoken, sometimes it doesn’t. I haven’t found a consistent pattern yet. Also, the chat window still needs to be popped out into its own window, as also was the case in JAWS 9, to be able to read it at all.
  • Speaking of Google Talk: The ARIA list of contacts behaves inconsistently with Forms Mode. It has a tendency to unexpectedly pop out of forms mode when you arrow from one list item to another. In addition, Enter does not yet work to open a chat or new e-mail message, depending on whether the contact is available for a chat or not. Forms Mode is instead turned off, and the virtual cursor lands somewhere unpredictable, preferably at the very bottom of the virtual buffer.
  • A similar unexpected leaving of forms mode can be observed in this
    Dojo treeView test example. Focusing the tree view, turning on forms mode, and arrowing among the items, opening and closing them works in the downward direction. However, as soon as I go from “Africa” back up to the root element “Continents”, forms mode is popped off.
  • One other problem I discovered was that alert messages have a tendency to get out of sync. I was trying out my example from Easy ARIA tip #3. I called up that page directly after I had started Firefox. Upon launch of Firefox, WebVisum told me that I was now logged in, via an alert. When I then triggered my first alert from the sample page, the “You are now logged into WebVisum” message was repeated. Consequently, all subsequent triggers of alerts would then speak the previous alert message instead of the current one.

In summary, there are clear advancements visible in JAWS 10 with regards to support of Firefox 3. Especially the more readable flow of text and the fact that you always return to the same spot when going back a page are big plus points. However, while there are also advancements visible in the ARIA and live region support, for a public beta after as long a development cycle as was mentioned in the podcast, I would have expected a much more polished first beta.

Having said that, it must not be forgotten that this is still beta software. All above issues were reported to Freedom Scientific prior to publishing this blog post, and the Mozilla accessibility team will work with the developers at FS to resolve these issues.

For the next public beta release of JAWS 10, I am planning an ARIA shootout among all screen readers across all platforms that support ARIA already. So stay tuned!

A job opportunity in Mozilla accessibility!

Monday, August 25th, 2008

The Mozilla Corporation has the following job opportunity available:

The Mozilla Corporation is looking for a full time engineer to develop accessibility in its software.

The job will involve working with a small team to develop support for a wide variety of 3rd party assistive technologies such as screen readers, screen magnifiers, on-screen keyboards and voice dictation software on a variety of operating systems.

The candidate we are looking for will be an excellent C++ programmer, with experience in COM or XPCOM, as well as working on OS X and either Linux or Windows. Previous experience with the Mozilla codebase is a plus. The candidate should be interested in developing solutions which improve how users with disabilities interact with the web.

Mozilla Firefox already has a strong foundation in this area. However, as the web progresses to provide ever more interactive and complex applications, interesting challenges continue to present themselves. For example, users with significant visual or physical impairments need to be able to interact with applications as complex as online word processors and spreadsheets, as well as content which includes technical information such as diagrams and mathematics. These users will be interacting with the content using text-to-speech, Braille displays, on-screen keyboards, voice input software, and other interesting technologies.

The candidate should be passionate about improving the Mozilla platform and be interested in pushing forward in a truly challenging and interesting area, which improves the lives of users with disabilities by removing barriers to participation on the web.

Some of the standards we will work with include HTML 5, SVG, MathML, WAI-ARIA, OS X’s AXAccessibility API, ATK/AT-SPI and IAccessible2. The team will assist the candidate in becoming more knowledgeable with respect to accessibility topics and the APIs involved.

Occasional travel will be part of the job, such as to disability-related conferences like CSUN and Mozilla project events such as on-sites and summits.

If this sounds interesting to you, get in touch and send in your resume!

New: Firefox 3 with Screen Readers FAQ online!

Thursday, August 7th, 2008

After the release of Firefox 3, it became apparent that there were many questions that came up again and again on the various mailing lists. The accessibility team along with several community members formulated a set of frequently asked questions and answers over the course of the past few weeks. We’ve been tweaking it and are now ready to announce it to the public! It is part of Mozilla’s official support pages, and you can check it out here!

Feedback is always welcome, and if you have additional questions that we didn’t cover, but which you think should be answered there, send them in as well!

ARIA in Gmail #2: Enhancing the Chat experience

Wednesday, August 6th, 2008

This post continues a series on the implementation of ARIA (Accessible Rich Internet Applications) in Gmail.

On July 30, Orca team lead Willie Walker forwarded a message to the Orca mailing list titled Orca & gmail. The message is originally by Srinivas Annam, an accessibility web developer at Google. He describes a couple of enhancements that had been made to the Gmail user interface and were pushed live recently. I’m going to review each feature in turn so you get an impression of what accessibility improvements these changes actually brought about.

I tested with JAWS 9.0, Window-Eyes 7.0 Beta 1, NVDA snapshot as of Wednesday August 6, and Orca snapshot as of Wednesday August 6. Unless noted otherwise, all features are fully useable using Firefox 3.0.1 and these versions of the screen readers.

All of the below are in the Chat area of the Gmail interface. So after you’ve logged into Gmail, make sure to activate the “Chat” link to be able to follow the descriptions.

The “Set Status Here” label

This is the label right below the “Search, Add or Invite” textbox. Pressing Tab from that textbox focuses the label. You can press Enter to get another textbox where you can put in a personal status message that others will see when they have you in their chat lists. Note if you’re using JAWS, press JawsKey+3 (3 on the number row) to pass the key through to Firefox directly. Otherwise, JAWS will capture the Enter key and turn off Forms Mode when you don’t want it to.

The “Status” menu button

This follows directly in the tab order after the “Set status here” label. You can press Enter on it to bring up a context menu to navigate and set a predefined status. This button is also discoverable with the virtual cursor in all three Windows-based screen readers, and Enter works on all of them to open the context menu.

Inside the context menu, navigating the items with Up and Down arrow keys properly issues the focus events, making use of the aria-activedescendant attribute to indicate which of the menu items is active.

A known problem is that, when pressing Escape to close the menu, focus does not yet return to the menu button. Use screen reader navigational commands to return to where you left off.

The chat contact list

This is an ARIA listbox with list items. It follows the “Status” menu button in the tab order. The Windows-based screen readers allow navigating to it using their virtual cursors, and pressing Enter for Forms Mode/Virtual off/PassKey mode. With Orca, you can simply navigate or tab to the list. The list uses aria-activedescendant to indicate which item has focus.

Navigating inside the list is done using Up and Down arrow keys. Besides the contact’s name, the status is given “chatting”, “available”, “idle”, “offline”.

Pressing Enter will do one of two things. Note that if you’re using JAWS, again use the JawsKey+3 keystroke to pass the key through, or it will turn off Forms Mode.

  • If the contact is available or idle, a chat window will open. See the next section for features within this window.
  • If the contact is offline, a new mail message to it will be started, and the focus will be placed in the “Subject:” textbox.

Below the list is another menu button labelled “Options”. However, the menu that opens does not yet use the aria-activedescendant attribute. The result is that no screen reader follows the focused item within this menu yet. It is hoped that this menu be accessible soon since it contains a number of useful functions.

The chat window

If you’ve opened a chat window to one of your contacts, the focus is placed inside a textbox where you can type your message. Press Enter when done to send your message.

The chat output pane uses ARIA live regions to enable screen readers to speak incoming messages automatically. These can either be your own, or the ones your chat buddy types. A suggestion: The message output uses aria-live=”assertive”. The other portion that gives messages such as “xxx is typing” does not use live region markup at all yet. It would be good if this used aria-live=”polite” to allow screen readers to also speak this information. Since this message is not as important as the actual output, using “polite” here can help screen readers prioritize the speaking of these updates.

Currently, both Orca and NVDA support speaking of live region updates. This means that, when inside the chat area and a message comes in, both screen readers will automatically speak them. Additionally, you can turn off PassKey through mode in NVDA and navigate upwards to review the last messages. With Orca, simply navigate upwards to review the last messages.

Note: If you’re using JAWS, you should pop out the chat into a separate window. For some unknown reason, JAWS will not pick up the contents of the output window unless the chat is inside its own window. To do this:

  1. Press JawsKey+3, followed by Ctrl+DownArrow to focus the Chat window toolbar.
  2. Press Tab to move to the “Pop out” button.
  3. Press Enter to activate it. Note you might get a warning from your popup blocker that it prevented Gmail from opening a pop up, and an error dialog by Gmail itself that tells you how to disable popup blocking for Gmail. I suggest you do this to more easily open those pop outs.

The Chat window toolbar

You can reach this by pressing Control+DownArrow while focused inside the chat entry textbox. It places focus on an “Options” menu button. Press Enter to open it. Navigation inside it is just like in the “Status” menu, also works using aria-activedescendant.

Alternatively, you can press Tab to reach the “Pop out” button, allowing you to put the chat into its own window.

Finally, Ctrl+UpArrow will put focus back into the chat entry textbox.

In summary

With these enhancements in both keyboard navigation and ARIA semantics, Google have turned this portion of Gmail into a really useful tool also for blind and visually impaired users. With Firefox or another ARIA-capable browser and a compatible screen reader, you can now use this part just like your sighted buddies do.

With this, Gmail is not just web mail, it becomes a communication center as it already is for the sighted users.

I’d like to thank Google again for putting ARIA into Gmail in this fashion. It shows that the work Mozilla, IBM and the W3C, under the leadership of Aaron Leventhal, put into this spec is indeed usable in real-life scenarios and not just, as suspected by some, a nice geeky thing on the drawing board.

Previous ARIA in Gmail posts

More ARIA in the news

Wednesday, August 6th, 2008

As I’m catching up with news after my return from Whistler, I have two suggested ARIA-related readings for you:

Gez Lemon of the Opera Developer community has posted an article titled Introduction to WAI ARIA. This is probably the most comprehensive, but easy to understand, introduction to WAI ARIA I’ve come across so far! Thanks Gez!

Victor Tsaran from Yahoo! has posted an article on the YUI blog titled Enhancing TabView Accessibility with WAI-ARIA Roles and States. It is a hands-on example that shows a lot of techniques outlined by Gez in action. There are both the final example to try out, and a screen cast to watch. Thanks Victor!

Happy reading!

Progress on automated testing for the accessibility module

Tuesday, August 5th, 2008

Today, I checked in two changes that allow the unit tests we’ve developed for the accessibility module so far, to run on what we call a staging server. A staging server is a server that simulates production conditions, but isn’t the live thing just yet. It allows us to test new features in build, testing, web sites etc., in close-to-real-life conditions before finally pushing them to production.

Obviously, getting these tests running on the production tinderboxes so we immediately see when we broke something is the next step. But until that can be done, we need to find a solution for bug 441974. Basically what is happening is that tests pass when each test file is run stand-alone, but some of these tests fail randomly when running all files in one big batch. But I made some good connections at the Mozilla summit last week, and as soon as we get these passing we’ll start running those tests. They’ll then run along with the many other unit tests we have for Firefox and the Mozilla platform.

I’d like to thank our intern Lukas Blakk and a bunch of other members of the QA and build teams to help me with getting these configs for buildbot right!

ARIA in Gmail #1: Alerts

Monday, August 4th, 2008

Google have recently started to put ARIA (Accessible Rich Internet Applications) into GMail. This means that ARIA is now getting a lot more exposure than it used to, with GMail being probably one of the most widely used web applications today. It’s great to see that the hard work Mozilla, IBM, the W3C and especially Aaron Leventhal put into this standard recommendation is getting this prominent placement so soon!

As an appreciation for the work devs at Google such as Srinivas Annam are doing to provide better access to GMail, this post starts a series of articles on the subject of putting ARIA into GMail, either after I’ve been pointed to specific areas or by finding new features myself.

The first in this series of reviews of GMail ARIA features concerns a very simple, yet effective, one: Alerts. As I already mentioned in my Easy ARIA Tip #3, alerts are a great way to immediately notify users about important status updates, but without taking focus away from where you are currently working.

As I found out rather by accident, GMail now uses an ARIA landmark role of “alert” for the piece of the UI that pops up with an important status message for a few seconds after certain actions have been performed. It disappears again after a few seconds, but because this is an alert, screen readers pick it up and speak it automatically as soon as it appears. Alerts, in the assistive technology terminology, are important status messages that can pop up anywhere on the screen and should be spoken or otherwise indicated to the user immediately. Another example of an alert is the notification box that appears when Firefox asks the user whether they want to remember the password just entered. It is an important notification the user might want to act upon, but still less intrusive than a modal dialog.

Actions that cause this alert to appear are such ones as moving a contact from the “Recommended contacts” to “My Contacts”, deleting a label, sending an invitation to someone for Google Talk/Chat, adding a contact, etc.

This way, actions that previously used to only pop up a message now provide immediate feedback. There is no need to look for the message, and when one finds it, find out that it just disappeared after the timeout.

Support for text attributes and spell checking is coming in Firefox 3.1!

Thursday, July 17th, 2008

For those of you on the bleeding edge, namely on the Firefox 3.1a1pre nightly builds, the Friday’s nightly build will include one big new feature in accessibility for 3.1: Text attributes and spell checking support!

This means that assistive technologies now have access to the attributes of any text run on a page via the IAccessibleHyperText::getAttributes or ATK/AT-SPI equivalent API calls.

For example, running today’s nightly build of Firefox 3.1a1pre on Windows, visiting my blog’s main page, bringing up Accessibility Probe, and navigating to the link below the Heading Level 1 that says “Marco’s Accessibility blog”, a call to IAccessibleHyperText::GetAttributes on the link accessible will get you this result:


getAttributes(1) = NULL

Not very fancy, huh?

Tomorrow’s build, however, will yield a completely different result:


getAttributes(1) = org.eclipse.actf.accservice.core.win32.ia2.IA2TextSegment[text=font-style:normal;language:en-US;text-align:center;font-size:40px;background-color:transparent;font-weight:bold;text-indent:0px;color:rgb(255\, 255\, 255);font-family:'Trebuchet MS'\,'Lucida Grande'\,Verdana\,Arial\,Sans-Serif;text-underline-style:underlinesolid;,start=0,end=26]

So, not only do you get information about the font-family, style, color and backgroundcolor, you also get the language this text is in, the underline style, the font-weight etc.

Also when editing, and you misspell something, as soon as you hit spacebar and the red underline appears, the attributes of that word will change and will include “invalid:misspelling;”, indicating that this word is invalid in that it is misspelled. Of course, an according IA2/ATK event will be fired accordingly! Note that the denotation of this may change if the IAccessible2 and ATK groups decide on a different notation for misspellings. Right now, it follows the aria-invalid convention, and we hope that this will be accepted by the groups.

Over the next few weeks, we’ll fine-tune this feature to be a bit more performant and also iron out any last details that might come up.

But if you’re an assistive technology vendor and you’ve been waiting for us to finally expose these text attributes, now is the time to try them out and provide feedback.

Note that Thunderbird and other projects that will be moving to use the Gecko 1.9.1 platform will also get this feature. This means that inline spell checking notification can also be supported for those apps soon!

[Update]: This patch made it into Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008071803 Minefield/3.1a1pre just fine. So go take a peek!