Wizard: TOC should be first in the markup for accessibility

[ebruchez]

+1 from customer

See also "Wizard: navigate pages with the keyboard #4210".

Need to backport to 2018.2.

[ebruchez]

Currently, we show the TOC last because in wizard.xbl it needs access to variables that are defined earlier. We position the TOC first with CSS.

• .xbl-fr-wizard is display: table; direction: rtl right now to fix the order
• we need to look into making the TOC first in the markup
  • can we do this in wizard.xbl?
  • if not, any other way, such as moving the markup later in the pipeline?

[ebruchez]

Actually it's the opposite: the variables are in the TOC area, but they depend on getting the state of the xf:switch using case(). So we placed the switch first, and the TOC second.

[ebruchez]

Dependencies of the variables on the view:

• case() for the top-level switch only
• xxf:is-control-relevant() for $nav-section-or-grid-ids
• xxf:binding() for $top-level-section-id

We could figure out the relevance and bindings of the sections by creating a separate, internal hierarchy of groups pointing just to the sections and grids, putting this first, and interrogating that.

For case(), currently the switch state only toggles via xf:toggle, although we have an optional caseref/sectionref since #1950 (but it's not used by us at this point).

We toggle:

• initially
• prev/next buttons
• click on TOC

[ebruchez]

Since we store the case id anyway, and the current case is only changed via actions, we should be able to use xxf:instance('local')/current-case-id to replace case(). Actually we can't, because we want the top-level case id. But we could store that as well.

[ebruchez]

Can we use the bind() function instead of creating a "separate, internal hierarchy of groups" as mentioned above?

[ebruchez]

xxf:is-control-relevant() applies to $nav-section-or-grid-ids, which are statically determined:

• if no subsections navigation
  • only top-level sections, repeated or not
• if subsections navigation
  • top-level sections which
    • don't have nested sections
    • OR have @subsections-nav = 'false'
    • OR are repeated
  • first-level subsection which
    • are not within a top-level section with @subsections-nav = 'false'
    • AND are not within a top-level repeated section
  • grid within a top-level section which
    • are not within a top-level section with @subsections-nav = 'false'
    • AND are not within a top-level repeated section
    • AND have sibling sections

So bind() would resolve all of those, since none of those are within repeated content.

[ebruchez]

Gist with a test form

[ebruchez]

Confirming that bind() works.

[ebruchez]

We also use:

• the index() function for repeated top-level sections
• and the xxf:binding() function in a couple of other places
• test again top-level repeated sections
• 2018.2 backport (hoping this won't be needed!)
  • diff wizard.xbl of 2018.2 and wizard.xbl just before this fix to see how hard it will be
  • handle non-repeated grids which don't have a binding as our use of bind() won't work there; should be possible to just use the enclosing section's relevance

[ebruchez]

Like #3455, it'd be nice if we had a native data model for the wizard.