Previously, Firefox used a progress bar to indicate the progress of loading a document and the status bar to indicate the stage of loading (connecting, loading, etc.). Both of these are now gone, replaced with a progress indicator icon for each tab, which indicates both loading activity and the stage of loading. As far as I can tell, this new indicator is not exposed via accessibility APIs, making document load progress inaccessible to screen reader users. (I believe there is an add-on to bring back the status bar, but I don't consider this to be acceptable accessibility. A feature should be accessible as is.) The way this new indicator is exposed needs careful consideration for an optimal user experience. Following are some of the issues: * It is relatively simple for a screen reader to indicate activity with a progress bar, as the percentage changes as activity continues. However, as I understand it, the new indicator indicates that there is activity, but the amount complete is indeterminate. It'd be good to find an optimal way to indicate this to screen reader users. Perhaps an event needs to be fired on the indicator accessible every so often indicating that activity is still occurring. However, what role should we use for such an indeterminate indicator? Perhaps we could use a role of progress bar but have a value which indicates indeterminate progress. * Visually, the stage of loading is indicated by changes in the icon, not using text. This needs to be exposed in a textual manner; e.g. "connecting", "loading", etc. I think this could be exposed as the name of the indicator accessible. * Instead of there only being one indicator for the active tab, there is now one indicator for each tab. This means that multiple indicators may be visible at any given time. I don't think it is optimal for screen reader users to have indicators for other tabs reported (even though they should still be exposed), so the indicator should somehow expose that it is for the active tab. Perhaps we could use the selected state. - How do sighted users quickly determine which indicator to look at for the active tab? * Current screen readers aren't going to know to report this indicator. Should the indicator for the active tab perhaps be a live region? - This is fairly ugly, though, and doesn't allow for other possibilities like non-speech sounds to indicate activity. Perhaps screen readers are just going to have to handle this new type of indicator.

This should be considered blocking the release since it breaks screen reader user experience in quite bad way. Also I've got these complaints from other screen reader vendor. Marco, could you cc right people or move this bug into proper component where it will get proper attention from UI guys?

Since this is now part of the tabbed browser I believe, moving it here for now. Dao, et al, please correct if this is not the proper place.

I think bug 603777 will give you the information you'll want to use.

(In reply to comment #3) > I think bug 603777 will give you the information you'll want to use. It looks like partially since it doesn't address percentage changes. Though this bug will be resolved if progress bar is added instead (or together with) text (like "connecting...").

Jamie, does this bug not include file progress downloading problem that was available in statusbar previously? If not then are you going to file new bug for this?

(In reply to comment #4) > (In reply to comment #3) > > I think bug 603777 will give you the information you'll want to use. > > It looks like partially since it doesn't address percentage changes. What percentage changes? The progress bars were in part removed because no such thing is really possible. There's no way to know how long until the server will be done; any "progress" indicated by the bars was a placebo. See bug 602964.

(In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #3) > > > I think bug 603777 will give you the information you'll want to use. > > > > It looks like partially since it doesn't address percentage changes. > > What percentage changes? The progress bars were in part removed because no such > thing is really possible. There's no way to know how long until the server will > be done; any "progress" indicated by the bars was a placebo. See bug 602964. I think it was treated as a percentage of loaded page, not as a time estimation. Does it make sense?

Percentage changes are impossible - either in terms of time remaining or in terms of page load kilobytes. We don't know how large every dependent resource is during page load, so any estimate is unreliable, as Dave suggests. That being said, then, I'd like to understand what other work this bug represents, so that I know whether or not it should block. I would not block on making the deceptive, now-removed percentage indicators accessible, for instance. :)

Right, an honest progress bar isn't doable. An indeterminate progress bar is problematic as well. There is precedent for this in dojo/dijit but the use case is different. Basically you expose role="progressbar" but with no value-* attributes. I guess in our case when it finishes we would remove the role attribute. This probably won't work the way we want today though, in terms of desktop events etc. Jamie how do you get document load state information currently?

why can't we just use aria-valuetext? (along with role progressbar)

(In reply to comment #9) > Basically you expose role="progressbar" but with no value-* > attributes. I guess in our case when it finishes we would remove the role > attribute. This probably won't work the way we want today though, in terms of > desktop events etc. It really needs to fire some sort of event periodically so we know something is still happening. > Jamie how do you get document load state information currently? Progress: We automatically beep (by default) for changes to any visible progress bars. This is particularly noteworthy because we don't speak progress indication. For many users, beeping is far less intrusive and annoying than constantly speaking percentages. Stage: When the document goes busy, we have some app specific code which reads the status bar. Ideally, the indeterminate progress bar would fire an event periodically so we can produce some sort of indeterminate beep, and events would also be fired whenever the stage changes; e.g. nameChange or something. I guess you could make the stage the value of the progress bar, but this would mean it'd be impossible to know whether something was still happening until the stage changed.

This is a regression (significant per comment #1), and periodic "something's happening" events per comment #11 sound like a reasonable approach. Blocking+.

What's next here? Sounds like we need a conclusion from a11y folks on how to best expose the aria pieces, and a Firefox person for implementation?

I could take it, but I'll need some help to figure out what implementation steps to take.

Unowned blocker, over to Frank. (Sorry Margaret, too slow ;)

(In reply to comment #14) > I could take it, but I'll need some help to figure out what implementation > steps to take. (In reply to comment #15) > Unowned blocker, over to Frank. (Sorry Margaret, too slow ;) I'm not familiar with what steps to take either. Any pointers on where to start?

> (In reply to comment #15) > I'm not familiar with what steps to take either. Any pointers on where to > start? I think the first step is to add attributes role="progressbar" and aria-valuetext="favicon" to the throbber's containing element. Each time the throbber changes, update aria-valuetext to one of: "favicon" "looking" "loading" (If this doesn't work, use aria-valuenow and 0, 1, 2 respectively) Then throw builds over to MarcoZ for some back and forth.

(In reply to comment #17) > I think the first step is to add attributes role="progressbar" and > aria-valuetext="favicon" to the throbber's containing element. "favicon"? This probably needs to be user interpretable. I think I'd rather see "done" or empty. We don't want to have to interpret these specially just for Firefox.

Jamie I wasn't imagining these being localized but was treating as machine readable. If NVDA would normally speak raw valuetext, we'd need to localize these but we are well past string freeze for FF4. Frank feel free to find me on IRC (davidb) for higher bandwidth discussion.

Checked the spec and I don't think it is expected for AT to localize/map the valuetext so we may be better off with valuenow.

(In reply to comment #20) > Checked the spec and I don't think it is expected for AT to localize/map the > valuetext so we may be better off with valuenow. Agreed, at least for FF4. I don't know what ATs will actually do with this, though. It's not really useful to just speak seemingly random numbers. Isn't bug 603777 going to expose text, though?

I think we should tackle this on bug 628654.

Taking this off of Frank's plate... David/James, did the old status bar send accessibility events for both the progress line indicator and the connecting/loading/waiting status messages? If so, we may want to implement this bug as discussed above for the loading indicator, then let the status messages be dealt with over in bug 628654, or possibly a follow-up to that bug. I'm not sure if this is best done in bug 628654, since that is already a pretty messy hard blocker, and I wouldn't want to slow it down.

(In reply to comment #23) > Taking this off of Frank's plate... > > David/James, did the old status bar send accessibility events for both the > progress line indicator and the connecting/loading/waiting status messages? I don't know. > If so, we may want to implement this bug as discussed above for the loading > indicator, This makes sense to me. > then let the status messages be dealt with over in bug 628654, or > possibly a follow-up to that bug. > > I'm not sure if this is best done in bug 628654, since that is already a pretty > messy hard blocker, and I wouldn't want to slow it down. I'm not sure either, but I think the a11y fix there is probably as simple as adding one attribute (probably aria-live="assertive") to the container node for the status messages.

The indicator was a progress bar (ascending tones that NVDA makes) indicating the overall progress, but not the actual stautus messages. As David said, adding the live region markup to the status messages should be a good substitute, better than indeterministic progress beeps.

So maybe it would be better to just make the status text accessible, and leave the progress throbber alone? We could make both accessible, but I'm not sure if that would be too noisy.

After discussion with davidb, MarcoZ, and gavin on IRC, we decided to try adding a role="status" to the status panel label implemented in bug 628654. I pushed this to try server for MarcoZ to test. Build will be available here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/mleibovic@mozilla.com-ca6fa06e3650

(In reply to comment #26) > So maybe it would be better to just make the status text accessible, and leave > the progress throbber alone? The problem with not making the throbber accessible is that a screen reader user then doesn't know if things are still alive if the status messages don't change for a while. As I understand it, one reason the throbber exists is to provide a sense of "progress". That said, I'm not really sure what the best approach is here. We've never dealt with an indeterministic progress bar before. If we do consider a progress indicator at all, perhaps it should be considered post FF4 when there's a little more time to consider this. In the meantime, the status messages will be good enough.

(In reply to comment #27) > After discussion with davidb, MarcoZ, and gavin on IRC, we decided to try > adding a role="status" to the status panel label implemented in bug 628654. And this works as expected in the try-server build. Thanks!

This is the patch I applied on top of the patch for bug 628654. MarcoZ says it works as expected, so I think it should do the trick :)

Bug 628654 landed without this fix, so we'll just fix it here.

Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110129 Firefox/4.0b11pre

Marco, how did you test this? I just tried with NVDA and a current Minefield nightly and don't hear any progress info.

I did, for example when bringing up this bug in the current nightly build: "Connected to bugzilla.mozilla.org..." It works fine for me.

(In reply to comment #34) > Marco, how did you test this? I just tried with NVDA and a current Minefield > nightly and don't hear any progress info. Err... please disregard. I goofed up and was running the wrong build. Sorry.

Fer, can you try Orca? We might need to open a GNOME bug if it isn't reporting status.