Firefox 7 is released, new features in accessibility

Firefox Update 7 has just hit the net, and while it’s still hot, I wanted to share a few items specific to accessibility that are included.

First and foremost, we participated in the improvements to memory usage and speed. More accessibility classes participate in our garbage collection mechanism, reducing the memory consumption greatly. Long sessions with a screen reader running should no longer result in huge amounts of memory being consumed. This is especially evident if you run with multiple tabs and open lots of pages.

A bug was fixed that caused large additions to xul:tree elements to hang for long times when accessibility was turned on. This could be observed in add-ons such as Adblock Plus on occasion.

If role="presentation" has been specified on an element and this element is made focusable, for example by setting tabindex="0" on it, the role of presentation is now ignored, and an accessible is created for the element nevertheless. This is to avoid situations where one would suddenly land on a focused item for which there is no accessible. This was the cause for some screen reader confusion.

On HTML table elements, the way the summary attribute and caption elements were handled has been switched around. Now, if the caption element is present, it becomes the primary source (ARIA not withstanding) for the name of the table. summary is now being converted into the accessible description, which is used to communicate additional information to users. Only if the caption element is omitted, summary will still become the accessible name’s source. Until Firefox 6, summary would always become the accessible name’s primary source. This brings Firefox in line with other browsers. Also, if assistive technologies query for the relation between the caption and table elements, the relation is now LABELLED_BY instead of DESCRIBED_BY.

In addition, some crash bugs were fixed that were found in earlier updates of Firefox, so this version is not only less memory-hungry and faster, but more stable, too. Happy browsing!

18 comments:

  1. As improved as it may be, it still crashes quite a lot whilst focused in the add-ons manager. For instance I make sure all the extensions installed are set to ‘on’ which means updates will automatically be installed. This is a very tedius task however because I must navigate to each, press Enter, Tab till that radio button can be selected by pressing Down Arrow, Tab or Shift+Tab till I get back to the list that says Extensions, Appearance etc. then toggle between something then return to Extensions since it will present the list of add-ons. I must repeat this 20 something times.

    Upon doing so, I can press Down Arrow to go to Appearance for example and the thing just crash. I always submit reports but since version 4 or 5 it has not been fixed. I do not think it is an add-on’s malfunction either because it would have most likely been fixed by now.

    On another note, the About dialogue is not as accessible as it could be. Since the first public beta of JAWS 13 dialogues have became much more accessible but it would still be nice to read things using standard JAWS commands. I have not used it long enough to notice a speed change. I also use Memory Fox so that may be why. I have other minor issues but I will not prolong this comment more than I have already.

  2. @ Marco. To whom can I contact regarding Thunderbird? This new version is crashing more than ever. I already submitted a JAWS 13 beta report when I used 6.0.2 and now 7.0 because it crashes every time an e-mail is finished sending but now it crashes every time I am in the add-ons manager and simply use the Arrow keys to cycle through the list of 3 or 4 add-ons. Something is wrong with either this public beta of JAWS or something went majorly wrong with Thunderbird 7.0.

  3. Jonathan, I just sent you private e-mail with some questions/requests that hopefully will help us diagnose the problem and find a solution. So far, I am at a loss as to what might be the problem. it is definitely not a general issue.

  4. The crashing is less frequent thankfully. Still happens from time to time, but no where as often as before. Firefox does however crash almost all the time when I’m in a CoverItLive chat (using JFW).
    I also get that odd “Stop Script” error message whenever I launch Firefox with Webvisum enabled. I wonder if that’s an FF or add-on specific issue. I’ve just resorted to logging into Webvisum whenever I need to instead of having it enabled by default since it can pop up while browsing as well.
    All in all though, a much greater improvement over the versions 4 and 5.

  5. I do not encounter the script issue stated above whilst logged in WebVisum [which automatically does so whenever Firefox is launched]. I assume it is that yes/no prompt that allows the script to run or stop running. I hardly ever encounter that any more.

  6. @Jonatan, yes, it is in fact that Yes/No stop script message. It’ll come up every blue moon without being logged into Webvisum, but when I’m logged in and especially if I have Webvisum enabled when launching Firefox, that error message comes up I would say about 7 or 8 times out of 10.
    @Marco, Well, so far, I’ve only recently been using the JFW 13 betas (both versions), but now I can’t recall if it’s happened in earlier versions. I’ll have to take the chance the next time there’s an active chat to try it out with earlier versions of Jaws. It’s rough though since I had absolutely lousy experiences with JFW 12 as it was terribly sluggish over all and especially with Firefox and have more or less tried avoiding using it as much as possible. That and whenever unloading and restarting Jaws would always make Firefox crash. That issue thankfully seems to have been resolved with the new JFW 13 beta.

    It still looks like the threshold for Firefox to work well is at 1,000,000 in memory. After that, Jaws and Firefox begin to act all buggy and spotty. I usually have to restart it at around the 1,400,000 mark.

  7. I think it is an issue pertaining to something on your specific system. JAWS 12 never made things slow down and act sluggish and I do not encounter that script error often at all. Just out of curiosity, what are your system specs [e.g. processor, RAM, hard disk space]? That might have something to do with the slowness.

  8. The Webvisum thing may in fact be due to something on my system, but the JFW 12 problems I believe are not. JFW 11 is a lot snappier and responsive and so is the JFW 13 beta. Many people on Jaws and tech lists reported the same if not similar issues with JFW 12 being over all slow and buggy. I for the most part tried sticking to Jaws 11 as much as possible and now with Jaws 13.

  9. The gogle toolbar bookmarks do not work in this new Firefox update. This was an incredibly useful feature especially having more than one computer. I am getting some goofy errors at start up too.

    “Exc in ev handl: TypeError: this.oRoot.enable is not a function”.

    and another new one today that is too long to remember.

    NEED BOOKMARKS BACK!!!

  10. Is anyone unable to read the menus in FF 7.0.1? I can’t read them with either NVDA or Window-eyes. In NVDA, pressing alt by itself or with another key yields no feedback, and the virtual buffer remains active. With WE, it recognizes that a menu appears but can’t read it.

  11. Tim, this must be something specific to your environment, since menus work perfectly here with 7.0.1 and nightly and both NVDA and WE.

What are your thoughts?