• Type: Sub-task
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:


      The current implementation

      As of

      • Navigation of the component tree is accomplished using the arrow keys (see KeyboardSupport.js and use of its defined grades in ComponentGraph.js and StructureView.js)
      • Component location in the component tree is communicated in aria-label properties
      • Component grades and models (structureViews) are in an ARIA tree (role=tree)
      • To move from a focused component to the component contents (grades and model), press tab
      • It is possible to navigate expanded grades and models using up and down arrow (see the "selectable" component on
      • All navigable elements are in the document tab order with tabindex=0

      Issues with the current implementation

      • aria-labels are used to communicate position in the component tree, but there is no communication of 'control type'
        • A screen reader or screen reader user will not know that they should switch from browse mode to focus/forms/application mode
        • The component tree offers no affordances to a screen reader user, such as keys to use to interact with it
        • Potential solutions:
          • Use role=tree on the component tree
          • Use role=application in the short term
      • All components are in the tab order
      • Moving between the component tree and the component contents via tab key is non-obvious (see below for some discussion)
      • The component contents tree does not follow the ARIA best practices keyboard control
        • To expand and collapse a node, we tab to the expander and 'click' it, rather than using left and right arrow keys
      • Components are read as "section" by NVDA (after the aria-label is read) as they are DIVs
      • When we expand or collapse a section of the component contents, the whole component structureView content is replaced. This causes focus to be lost because the element that had focus is no longer present in the document. In the current implementation, the whole component tree is rerendered when a component part is expanded or collapsed (see below for notes).


      • Tab between components, arrow within
        • Component content is role=tree
        • Use "roving tabindex"
        • Problem: Components are linearized and the component relationships are not communicated
          • Could potentially add separate collapsible table of contents
          • Could maybe add other forms of navigation 'skip links' to jump to parts of the tree
          • Could make the component names into headings
      • One big tree
        • Problem: We change orientation
          • I tested nested role=tree with different orientations in Firefox and NVDA; NVDA did not report the orientation change (though more testing can definitely be done here)
      • Two levels of tree
        • One tree for component relationships (the component tree)
        • And a tree for each component contents (grades, model)
        • Move between levels; for example:
          • Navigate to component with arrow keys, press Enter
          • Navigation is then constrained to within the activated component
          • Press Esc to exit the component

      Expanding or collapsing a component content node causes the whole component tree to be rerendered

      1. has grade
      2. calls structureView.readBounds()
      3. changes the layout model value
      4. has a modelListener on layout that fires invalidateLayout
      5. ties invalidateLayout to "{}.events.invalidateLayout"
      6. All components in the componentGraph are rerendered (including the component that initially triggered the rerender)





            simon Simon Bates
            simon Simon Bates
            0 Vote for this issue
            1 Start watching this issue