XGovFormBuilder / digital-form-builder

Exploring how to quickly and easily design/prototype/deploy high quality digital forms for UK Gov. Based on the excellent work by DEFRA. Currently maintained by jen+forms@cautionyourblast.com at Caution Your Blast and a community collaboration between FCDO, HO, GDS, DfE, DIT, Version 1, UKHSA
https://digital-form-builder-designer.herokuapp.com/app
MIT License
58 stars 34 forks source link

Make the visualisation semantic for a better keyboard navigation #491

Open jenbutongit opened 3 years ago

jenbutongit commented 3 years ago

Is your feature request related to a problem? Please describe. At the moment we are drawing the graph in an svg, which makes it easy to put down coordinates and render the graph.

Describe the solution you'd like Have the pages as a <nav> or <ul>. Use absolute css prop to be able to position the graph elements.

The (poly)line or link can be an item in the nav/ul which is a more appropriate/semantic place for it.

Describe alternatives you've considered svg now allows more x/html elements, but with a "complex" ui, it gets harder to make it semantic and more accessible within an svg.

Additional context Had this thought on the bus.. apologies for the formatting ¯_(ツ)_/¯

jenbutongit commented 3 years ago

The purpose of this issue was to improve keyboard navigation so updating the title too

jenbutongit commented 3 years ago

Currently we've got an issue with navigating through all the pages with just the keyboard. I think we would need to consider the order a user shoulder navigate through a form with a lot of branching logic.

Essentially the pages and links are vertices and edges of a graph respectively (or tree). You can navigate a graph by going depth, or breadth first.

        A
       / \
      B   C
     /   / \
    D   E   F
     \ /
      G

With this graph/form, starting from A, what would happen if you keep hitting tab, would/should you

  1. navigate by depth - A, B, D, G, C, E, (G), F - I'm undecided if we go this route if we should report a vertex twice
  2. navigate by breadth - A, B, C, D, E, F, G

Then the next thing to consider is being able to "hop" branches, and use arrow keys to do so. I think since it's a graph, if you were to press the up key on page D, you would change to E, and up again would get you to F. Using left and right keys would progress the depth or breadth search. i.e. the next page as per depth search.

How would we report to a user where they are, in relation to the pages around them? I could imagine someone could get very disorientated if they are partially sighted, you would have to know the entire graph/form before you even begin. When the page title is read out, should we use something like aria-live to report where pressing up/down/left/right would take you?

In any case.. I might have to revise my thinking on using nesting lists. I have no idea how you would handle when pages converge.

jenbutongit commented 3 years ago

paging @DavidBiddle on the comment above 🙂