Posts Tagged ‘Accessibility’

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!

Easy ARIA tip #3: aria-invalid and role “alert”

Wednesday, July 16th, 2008

I know, I know, it’s been a while since I posted my last Easy ARIA tip. But I’m hoping that this one will find you all excited and willing to play with it some more!

The problem: You have a form, a contact form, for example, that you want to put some accessible error checking into. Common problems are e-mail addresses that are not valid, or a name that does not contain at least a first and a surname.

The form

Let’s start out with a simple form.

<html>
<head>
<title>Contact form</title>
</head>
<body>
<form method="post" action="post.php">
<fieldset><legend>Please enter your contact details</legend>
<label for="name">Your name (required):</label>
<input name="name" id="name" aria-required="true"/><br />
<label for="email">E-Mail address (required):</label>
<input name="email" id="email" aria-required="true"/><br />
<label for="website">Website (optional):</label>
<input name="website" id="website"/>
</fieldset>
<label for="message">Please enter your message (required):</label><br />
<textarea name="message" id="message" rows="5" cols="80" aria-required="true"></textarea><br />
<input type="submit" name="submit" value="Send message"/>
<input type="reset" name="reset" value="Reset form"/>
</form>
</body>
</html>

Straight and simple, but we’re not here to win beauty prices anyway. :-)

Checking for validity and notifying the user

Checking the validity and notifying the user consists of several steps:

  1. Checking if the e-mail address or entered name are valid. To keep it simple, we’ll check whether the e-mail address contains the “@” symbol, and if the name entry contains at least 1 space characters ” “.
  2. Setting the field’s aria-invalid attribute and giving it a value of “true”.
  3. Notifying the user via an alert that the value entered was incorrect. Instead of using an intrusive dialog box created by the JavaScript ‘alert’ function, we’ll use a simple WAI-ARIA widget to do it. This notifies the user, but lets them continue interacting with the form without any interruptions.

All of this happens when the input loses focus, meaning in the “onblur” handler.

The JavaScript code I wrote looks like this, inserted above the closing “head” tag:

<script type="application/javascript">

  function removeOldAlert()
  {
    var oldAlert = document.getElementById("alert");
    if (oldAlert)
      document.body.removeChild(oldAlert);
  }

  function addAlert(aMsg)
  {
    removeOldAlert();
    var newAlert = document.createElement("div");
    newAlert.setAttribute("role", "alert");
    newAlert.setAttribute("id", "alert");
    var msg = document.createTextNode(aMsg);
    newAlert.appendChild(msg);
    document.body.appendChild(newAlert);
  }

  function checkValidity(aID, aSearchTerm, aMsg)
  {
    var elem = document.getElementById(aID);
    var invalid = (elem.value.indexOf(aSearchTerm) < 0);
    if (invalid) {
      elem.setAttribute("aria-invalid", "true");
      addAlert(aMsg);
    } else {
      elem.setAttribute("aria-invalid", "false");
      removeOldAlert();
    }
  }

</script>

The checkValidity function

The core is the checkValidity function. It takes three parameters: The ID of the input that is to be validated, the term to search for to ensure validity, and the error message to be inserted into the alert.

To see if it is valid, the function checks whether the indexOf the input's value is anything greater than -1. A value of -1 or less is returned if the index of the search term could not be found within the value.

If invalid, the function does two things:

  1. It sets the element's aria-invalid attribute to "true", which will indicate to screen readers that there is invalid content in here.
  2. It will call the addAlert function to add the alert with the provided error message.

If the search term is found, the aria-invalid attribute is reset to "true". In addition, any alert that still might be around is removed.

The addAlert function

This function first removes any old alerts. The function is simple: It looks for an element with id "alert", and if found, removes that from the document object model.

Next, the function creates a div element to hold the alert text. It gets an ID of "alert". And it gets a role set of "alert". This is actually ARIA-inspired, even though it doesn't say "aria" in the attribute name. The reason is that role is based on the XHTML role attribute module that was simply ported to HTML for simplicity.

The text is added to the div element, and the div element is added to the document.

The moment this happens, Firefox will fire an "alert" event to assistive technologies when this div appears. Most screen readers will pick this one up automatically and speak it. This is similar to the Notification Bar in Firefox that prompts you whether you want to save a password. Our one does not have any buttons to press, it just tells us what's wrong.

Adding the magic to the "onblur" event

All that's left now is add the event handler. We need to change the two inputs for e-mail and name for this:

<input name="name" id="name" aria-required="true" onblur="checkValidity('name', ' ', 'Invalid name entered!');"/><br />
<input name="email" id="email" aria-required="true" onblur="checkValidity('email', '@', 'Invalid e-mail address');"/><br />

Testing the example

I've put up the above as an static example page for you to try it out. If you use Firefox 3 and a current supported screen reader, try the following:

  1. Enter only your first name as the name. When tabbing, you'll hear an alert that tells you you've entered an invalid name. You can then shift-tab back and correct the error.
  2. Enter an e-mail address that has no "@" symbol. When tabbing out of this field, you should hear a warning that says you didn't enter a valid e-mail address.

In both cases, when returning focus to the field in question, your screen reader should tell you that this field is invalid. JAWS 9 supports this, but JAWS 8 does not, so this may not work in all versions of the screen readers supported.

A few questions that you might have

Why did you put both "(required)" in the label text and the aria-required attribute on some of the inputs?
Because if this were a real live form, and the site was being visited by a browser that does not yet support ARIA, we'd still want to give an indication that this is a required field.
Why don't you set focus back to the invalid field automatically?
Because this is not allowed by at least the Windows API specs and possibly others. Also, letting the focus jump around without real user interaction too often is not a nice thing to do in general.

In conclusion

Personally, it is my hope that websites would include such techniques more often in the future when filling out forms. There's nothing more frustrating than filling out a form with 20 or so fields, submitting it, only to find that field 3 was invalid, and having to go through all fields again to make sure the values were retained, or supplying some information redundantly.

This is one of those examples where, in my opinion, more direct accessibility and user-friendliness can be achieved by explicitly using some JavaScript in combination with ARIA.

I hope you found this little tutorial of some use! I'd welcome your feedback as always!

And of course, you're welcome to enhance this little example as a "homework" to also check whether something valid was entered for the "message" textarea.

Previous Easy ARIA tips
  1. aria-required
  2. aria-labelledby and aria-describedby

WordPress 2.6 brings a lot of accessibility improvements!

Wednesday, July 16th, 2008

I just upgraded this blog to WordPress 2.6.

This version brings with it a number of accessibility enhancements.

One thing you might have noticed already is that there is now a default language set. Default English blogs should now always cause screen readers that support language switching to use the English variant of their default speech synthesizer.

Also new: Whereever possible, there are now labels properly associated with the corresponding form controls. This means that now also screen readers that do not do their own HTML processing should pick up the labels fine.

One more addition that the WordPress team has embraced is the inclusion of some WAI-ARIA markup. Whenever you comment on my blog now, and soon hopefully many others, and you use a compatible browser such as Firefox 3, and a compatible screen reader such as NVDA or Orca, you’ll hear that the text fields also textually marked as “required” in their labels, now are announced as “required” fields. The WordPress default theme now uses aria-required to denote such fields as required, giving even more accessibility to WordPress!

I’d like to thank the WordPress community to embrace ARIA! It is really amazing that ARIA is now finding its way into such a widespread mainstream piece of software!

Review of the WebVisum Firefox extension

Thursday, July 3rd, 2008

Today, a post announcing the WebVisum Firefox extension was posted to the mozilla.dev.accessibility newsgroup. The things talked about in this post and on the WebVisum homepage almost sound too good to be true. Among the features are:

  • Ability to tag graphics, form fields, links, and other page elements. While some or all of these features have been available in some screen readers already, this feature is unique in that it works across platforms. It also sends the data back to the WebVisum web service so other members of the community can benefit from the labels someone provided.
  • Optical Character Recognition (OCR) to try and identify those images that absolutely won’t tell us through their SRC what they’re all about.
  • Visual page enhancements such as a high-contrast profile.
  • Suppression of automatic page refreshes or Flash content
  • And most astonishingly: CAPTCHA solving!

A few days ago, I was approached by the WebVisum development team if I would consider beta testing their extension. So, I had a bit of a head start with this tool, and I was very surprised when I started testing some of the features.

The tests

From my main screen reader, I already knew the capability to label graphics or HTML form elements that have missing alt text or labels. Instead of using those techniques, I applied a few labels to the main navigation images on the CakeWalk homepage using WebVisum. After labelling the graphics from my Windows computer, I fired up my Linux box, installed the extension there and surfed to cakewalk.com. Orca immediately picked up the labels I had given the graphics and used them as the link text.

I then went ahead and labelled the Search combobox on the German Heise Newsticker site. Again, after visiting the page from the other computer, the label for the combobox was read aloud.

And then I actually tried a CAPTCHA. I chose digg.com as my first target since I know they also offer an audio CAPTCHA. Of course this is not a 100% satisfactory solution because deaf-blind people are still left dead in the water with this, but it gave me a good reference to compare the results. I went into the new account creation process on digg, and when it came to the CAPTCHA, I let WebVisum do its magic. Within less than 30 seconds, I got a result back, placed on my clipboard by the extension, ready to paste in. I compared it to what the audio CAPTCHA told me, and the results matched!

I repeated this step two more times because I had first chosen a user name that was already taken, and then goofed up something else in the form, and each time, the result was correct. Totally stunning!

I tried the same on Technorati who also offer an audio CAPTCHA, and got the same results: The CAPTCHA was correctly resolved.

As my third target, I chose MozillaZine, who, despite a couple of attempts on my part, still do not offer an audio CAPTCHA for registration or sending a reply to a forum without being logged in. Without this fall-back mechanism, this is a real-world scenario that visually impaired people are being faced with on an almost daily basis. And I’ll be darned, it worked out! I could register with the MozillaZine forums without any sighted assistance.

The conclusion

There are actually a couple of conclusions, concerns and questions that this extension raises.

The educational aspect

So here we are, having been trying to educate web developers all over the world to use W3C accessibility authoring guidelines, comply with section 508 and what not, and now an accessibility comes along that allows for labelling controls, providing alternative text for graphics, and even share this with the community. So did we do all this educational endeavor invain?

The answer can only be a firm and resolute: “No, we didn’t!” While this extension allows to correct for obvious mistakes like a missing alt attribute on an image, it cannot correct all the requirements there are to meet for section 508 compliance. And it should not! On the contrary: All mistakes one has to correct should be counted against a ranking on a “Wall of shame” kind of statistic that depicts the sites requiring the most corrections. Similarly to the Firefox “Report a broken website feature”, that in Firefox 3.0 also has a “Disability Access” component that allows to report an inaccessible web site, this data should be used to advertise for better accessibility in a future relaunch of that particular site.

Furthermore, there are so many websites that are part of the so-called web 2.0 that are not publically-owned or from a big company, but which are just as compelling to participate. These can usually either not be bothered or cannot financially make it to be 100% sec 508 compliant. Having the possibility to enhance these pages will make the web 2.0 a much more compelling place than it already is in the future.

The CAPTCHA solver

This is probably the most controversial feature. The fact alone that WebVisum is able to solve the CAPTCHAs will probably send shivers up and down the spine of many web developers, website administrators, blog owners etc. that have to fight spam every day. The fact that WebVisum can do it probably means that spambots will sooner or later also be able to do it. Even worse, some could argue that the WebVisum service may be abused by spammers to get CAPTCHA resolution for free.

The WebVisum developers assured me that they’ll make sure that only real people will be able to use their service. Furthermore, the number of CAPTCHAs that can be solved per day per site is limited.

While it is correct to advertise for alternatives to visual CAPTCHAs, the reality is that audio CAPTCHAs, which are the most common alternative, do not allow every person to use them. I already mentioned deaf-blind surfers. But also people who have a hearing impairment and have difficulty deciphering the distorted audio have trouble with this alternative. The CAPTCHA resolution feature allows to solve the problems of these people and also anyone who has trouble reading or hearing the text who is not visually impaired.

Also, this allows access to those private sites and blogs that are under no pressure government- or image-wise to implement an audio CAPTCHA. It definitely lowers the barrier for participation in the web 2.0 world!

Aside from all that, CAPTCHAs only offer a false sense of security. There are much more effective ways of fighting spam than imposing these things upon everybody. My blog, for example, has no CAPTCHA entry for commenting, and still my spam fighting measures have kept this blog clean for as long as it has been in existence. But the sad reality is that CAPTCHAs are an “evil” we currently have to cope with, and WebVisum certainly helps a lot in circumventing these artificial barriers.

My hope is that the WebVisum folks manage to keep their user base spambot-free and that there won’t be any other way to abuse the feature for unsolicited activities.

A few wishes for the future

I see for this extension the potential to become much more than “just” a web helper for the visually impaired. For example, I can imagine this being enhanced to allow hearing-enabled people to provide a textual transcription of an audio clip for deaf surfers, sighted people giving a textual description of not just an image, but a video clip or the like, and other similar cross-impairment possibilities. After all, any hearing-enabled blind could provide such textual transcription of an audio clip for a sighted deaf person.

Aside from this larger-scale vision of mine, a few more basic features such as an undo feature that allows to revoke a server-submitted enhancement will hopefully make its way into near-future versions of the extension.

So: To be able to make up your mind for yourself, go check out the website and extension at www.webvisum.com.