accessible svg graph

[felixroos]

idea by Nicop:

I don't know of the exact way to implement this, but, if we're sticking to an SVG, you could make the tab order for individual connections make more sence, maybe in the order I've described. If you do decide to implement branching logic, the branch should be under a dropdown that shows/hides the relevant components when it's collapsed or expanded. As a bonus you can probably reduce visual clutter, especially for cable salad.

Another idea. If we want to implement the treelike navigation but keep it graphed as SVG, you can manipulate the keyboard focus whenever the user arrows through, as long as the keyboard focus is on a component of the SVG. For this to work, however, you'll have to properly alt your components. The only reason I don't want to make that arrow key navigation global is because you also use those to move in the code edit field, as you would with any other.

[nicopn]

Hi,

I'm the person who originally thought of this idea, and would like to bring more context to it. My goal is to make the SVG graph (the one that contains all modules and connections) be accessible to screen readers. In terms of navigating and labeling the graph's elements, I propose the following:

labeling

every element in the graph should have its own alt text. Suggestions for that are below

• A module, such as sine, mul, lpf, should have ", module" appended to its alt, E.G., "lpf, module". This is to differentiate between modules and connections between them.
• A wire or connection should have its two endpoints labeled in its alt, and should have ", wire" appended, E.G., "saw to lpf, wire".
• Assuming we're dealing with a tree-like structure, any connection that branches to others should have ", has branch" appended to its alt, E.G., "perc to add, wire, has branch".

Navigation

• The user should be able to navigate the graph using their arrow keys as if it were a tree view, in the following manner:
  • Up/down should move to the previous/next element in the same hierarchical level.
  • Right should move to the first child item (the first wire that branches out from the current). This should only work if the wire branches out, hence why I propose to add ", has branch" to the alt text when applicable.
  • Left should move to the parent item (opposite of what right does)
  • If trying to move in any direction out of bounds, that attempt should be stopped and focus should not move.
• Navigation in this way could be achieved by moving the keyboard focus along the graph in the manner I described. This has the added bonus that screen readers should speak the keyboard focus if it changes, meaning that this should work as long as each component has proper alt text
• This way of navigating with arrow keys should only work if the user was focused somewhere in the graph beforehand. This is to avoid those keys conflicting with, say, text editing commands, in which the arrow keys move the cursor.