Firefox 6: html:progress element accessibility

Recently, Mounir landed support for the HTML5 progress element on the Mozilla development branch (AKA “Nightly” channel). A few days later, after a concerted effort and another episode of “Marco and C++ are only partially good friends” 😉 , accessibility support landed, too, and thus the progress element will be accessible starting in Firefox 6. For those of you on the “Aurora” channel, you should see stuff come through the pipeline with updates after the next Aurora merge, currently slatted for mid next week.

This means that web devs can use the progress element in web applications, and we will now no longer expose the alternative text enclosed in the opening and closing tags, but the actual visual representation of a progress meter. The accessible object for the progress meter will expose the AccessibleValue interface for all relevant platforms (e. g. ATK and IAccessible2), so that assistive technologies can query for not only the value string but also the float values for:

  • the current value
  • the minimum (always 0)
  • the maximum (if not specified, the default is 1 as in the specification)

By default, NVDA will expose the current percentage as you can test in this example with a current version of NVDA.

Note that there were no changes required on NVDA’s side to support this. So if your screen reader currently supports WAI-ARIA progress meter elements, and the screen reader does not do any funky stuff with their own HTML parsing here, this should just work.

Another note: While we were here, we also fixed a few things regarding XUL:progressmeter elements that were buggy in the past, but were not really uncovered until now. The user visible impact will be minimal for this, but for our code this was definitely benefitial, as we’re now dealing with the proper maximum value for xul:progressmeter elements, which differs from the default max for html:progress.


7 thoughts on “Firefox 6: html:progress element accessibility

  1. Hi Marco, were you able to implement the progress element according to the HTML5 spec, or do you think there’s room for improvement in the specification? If so, would you consider posting a bug against the spec explaining which changes were necessary to make the element accessible? Thanks, Martin

  2. Hi Martin, hm, I do not quite understand your question I’m afraid. Since this is a new HTML element, we needed to make it accessible anyway. So our accessibility code needed to learn that it should react to an element with name progress, and we told it that it needs to expose the AccessibleValue interface so assistive technologies can query for the minimum and maximum values, the current value etc.

    No browser vendor can go without implementing something like this for a new element. So I’m not sure what the spec has to do with this. The progress element gives us all we need for the accessibility APIs AFAIK.

  3. I am very concerned about the new forced march dev cycle. Sure, as often as not it is just a case of renaming securrity updates as majors, but the issue is lack of suuport for older versions, and will add to confusion for the user who may need to stay with an un-supported version if, (and I almost for sure suspect when), accessibility lags.
    On the bright side html5 and good standards compliance should make screen-reader devs’ jobs easier. I just hope that changes that may effect screen-reader usability are not phased in before acomidations can be made. So far I’ve been pleasantly surprised by my lack of problems with fx4-5 in Linux, but have not had good results in windows. Go Linux!
    Anyone know how long changing the max value in the install.rdf file will keep web-visum working?

  4. Burt: that seems to be the last plugin keeping me on FF 3.6x, Web Visum.

    From what I’ve been reading on Mozilla blogs, so long as the base API does not change (whatever the plugin uses), then the max value is the only thing breaking the plugin. If the API changes, then the developers of the plugin would need to fix.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.