FLUID-5423: Progress is not announced.

Description

Steps to reproduce:

1) Open the progress demo
http://build.fluidproject.org/infusion/demos/progress/

2) Click on "submit"
Notice that the progress bar is moving but there are no audio updates/indications of it.

Environments

Chrome 35, FF 29 (Windows 7)(NVDA 2014.2)
Safari 7 (Mac OS 10.9)(VoiceOver)
Safari 10 (macOS 10.12)(VoiceOver)
Safari 17.5 (macOS 14.5)(VoiceOver)
MS Edge (Win 10, Narrator)

Comments

• Justin Obara commented 2014-06-12T14:06:43.608-0400

  May be related to the fact that the "submit" button retains focus. If progress bar itself has focus, it will announce the progress.

• Anastasia Cheetham commented 2014-06-16T11:44:35.296-0400

  We may want to update the demo to autofocus the Progress bar after the submit, so that the demo is more informative.

• Justin Obara commented 2014-06-17T09:44:59.549-0400

  Joseph Scheuhammer and I talked about this in the channel today, and compared with an example from the open ajax alliance.
  https://botbot.me/freenode/fluid-work/2014-06-16/?tz=America/Toronto
  http://www.oaa-accessibility.org/example/27/

• Joseph Scheuhammer commented 2014-06-18T10:24:06.171-0400

  The ARIA mapping document has a section on a11y events, including aria-valuenow and aria-valuetext [1]. These are the events that the browser is to emit when aria-valuenow/aria-valuetext change. Summarized below – note that aria-valuetext changes do no spawn events for either of UIA express nor pure UIA:

  aria-valuenow:

  • MSAA + UIA Express: EVENT_OBJECT_VALUECHANGE
  • MSAA + IA2: EVENT_OBJECT_VALUECHANGE
  • UIA: ValueProperty change.
  • ATK/AT-SPI: object:property-change:accessible-value.
  • AXAPI: AXValueChanged.

  aria-valuetext:

  • MSAA + UIA Express: not mapped (no event)
  • MSAA + IA2: EVENT_OBJECT_VALUECHANGE
  • UIA: not mapped (no event).
  • ATK/AT-SPI: object:property-change:accessible-value.
  • AXAPI: AXValueChanged.

  I tested the open ajax example Justin cited above [2] and the fluid demo [3] in two ways. One way involved running the examples with Orca on GNOME/Linux. The other was to see what events FF was emitting on Win7, using AccProbe.

  For the GNOME/Linux tests, Orca spoke a sequence of "percent complete" speeches. That is, both examples worked.

  For the FF/Win7/AccProble tests, a sequence of EVENT_OBJECT_VALUECHANGE events were emitted. This matches the mappings spec (MSAA+IA2) for changes to aria-valuenow. FF is emitting the documented a11y events on Win7. And, although not checked with an inspector, it's likely FF is emitting the ATK/AT-SPI events for the Orca tests.

  [1] http://www.w3.org/TR/core-aam-1.1/#mapping_events_state-change
  [2] http://www.oaa-accessibility.org/example/27/
  [3] http://build.fluidproject.org/infusion/demos/progress/

• Justin Obara commented 2021-07-14T15:33:49.782-0400

  Possible related issue: https://github.com/nvaccess/nvda/issues/913