FLUID-3711: When moving an element, the new location should be indicated

Description

The new location for a moved item should be indicated, specifically in the case of complex layouts like the layout reorderer.

Attachments

• FLUID-3711.patch
• FLUID-3711-b.patch

Comments

• Justin Obara commented 2010-09-07T10:16:06.924-0400

  a11y issue

• Colin Clark commented 2010-09-17T17:48:09.458-0400

  This indication will be achieved by implementing FLUID-3730, a component that can automatically associate reorderable elements with labels using aria-labelledby. However, the strategy will have be somewhat different--we'll have to, in the midst of a move operation do one of the following things:

  1. Dynamically update the about-to-be-moved element's aria-labelled by to point to a temporary, dynamic label describing the move location
  2. Presenting the move location in an associated aria live region

• Justin Obara commented 2010-10-04T15:02:45.706-0400

  Bug Parade 1.3 tag deleted by order of THER KINGG

• Antranig Basman commented 2010-12-10T15:44:34.438-0500

  See comments on FLUID-3708 - the new location is indicated if the mouse is moved or perhaps if the screen buffer is refreshed, but unfortunately it was not possible with current strategies to cause a dynamic announcement at the point of performing the move. These two issues pushed out to 1.4

• Antranig Basman commented 2010-12-13T03:31:43.288-0500

  This patch implements a solution combining the use of "aria-label" for static messages and an offscreen live region for dynamic messages that appears to work under NVDA. A caveat is that to use the reorderer successfully under NVDA, it needs to be put into "FOCUS MODE" using the "NVDA + Space" key, otherwise the use of arrow keys and tab will apparently send NVDA and the browser bananas as they attempt to fight over key bindings. The fix needs testing under JAWS.

• Antranig Basman commented 2010-12-13T13:47:09.951-0500

  Attached FLUID-3711-b which cleans up the patch slightly, accounting for recent changes in trunk and replacing implementation of aria-dragging states which had been suspected of breaking the implementation

• Colin Clark commented 2010-12-13T15:50:24.979-0500

  I committed Antranig's latest patch for this issue at r10401. Still needs code review, which I will do shortly.

• Colin Clark commented 2010-12-15T19:15:37.554-0500

  I've reviewed Antranig's changes to Uploader to include location labeling upon moves, and they look good. Some general, non-blocker review comments from our conversation about it in the channel:

  colinclark: Minor, non-blocker code review comments...
  [6:59pm] colinclark: the labeller's listener for Reorderer's onRefresh event looks an awful lot like something which should actually be a public method
  [7:00pm] Bosmon: Yes
  [7:00pm] Bosmon: I haven't actually considered what to do about returnedOptions
  [7:00pm] Bosmon: I think it should go, yes
  [7:00pm] Bosmon: But I'm not entirely sure how
  [7:00pm] Bosmon: Which I guess is related to your comment just now
  [7:01pm] Bosmon: Where there are "standard listeners" for a component which actually embody crucial public functionality...
  [7:01pm] Bosmon: For a start I guess this listener should be namespaced
  [7:01pm] Bosmon: Haven't really thought carefully about how listeners should interact with IoC, over and above the options infrastructure we already have for them
  [7:01pm] colinclark: it seems to me that it's a core piece of the labeller's behaviour
  [7:01pm] Bosmon: "event boiling" was only a sketch so far
  [7:02pm] colinclark: regardless of whether it happens to be wired up as a listener for something else
  [7:02pm] colinclark: It seems to me that there is room for some awesomeness in regards to events and IoC
  [7:02pm] Bosmon: I guess we actually need to expose the "listeners" structure itself to various kinds of IoC-driven EL inspection
  [7:02pm] colinclark: That seems sensible to me