When navigating the charts with a browser / screen reader pairing that opts to ignore the problematic structure (see #266 Charts inaccessible to most SR users) or simply using a keyboard without a screen reader, the items are read from what is visually the last item and then in reverse visual and conceptual order.
A user might expect to put focus on the top-most item first or hear that same item first, not last. Instead the last item of the content is the first node in the DOM. The entire set is reversed in the DOM.
2.4.3 Focus Order (because the user starts at the opposite end of where they expect to go, and can cause viewport jump).
The translate() function is moving the nodes into a visual order reversed from their position in the DOM. That means it is possible to re-order the DOM without changing the visual appearance. This may be a matter of reading an array in reverse order to populate the SVG.
It is critical that the corresponding numbers also get re-ordered to match. A screen reader user exploring the content will draw the wrong conclusions from its structure now and also if the names are re-ordered without the numbers.
See my suggestion to convert this to a programmatic table in the linked issue. That might make this entire chart easier to manage (for authors and users).
Describe the bug
When navigating the charts with a browser / screen reader pairing that opts to ignore the problematic structure (see #266 Charts inaccessible to most SR users) or simply using a keyboard without a screen reader, the items are read from what is visually the last item and then in reverse visual and conceptual order.
A user might expect to put focus on the top-most item first or hear that same item first, not last. Instead the last item of the content is the first node in the DOM. The entire set is reversed in the DOM.
Steps to reproduce the bug
Expected Behavior
Actual Behavior
Tab↹
presses visually move up the list.Related code
The chart listing of names is made up of this elided HTML:
Note the last person on the list appears first in the DOM (I only brought in the bottom four).
Additional Context
The code as shown is problematic under the following WCAG 2.1 Success Criteria:
The
translate()
function is moving the nodes into a visual order reversed from their position in the DOM. That means it is possible to re-order the DOM without changing the visual appearance. This may be a matter of reading an array in reverse order to populate the SVG.It is critical that the corresponding numbers also get re-ordered to match. A screen reader user exploring the content will draw the wrong conclusions from its structure now and also if the names are re-ordered without the numbers.
See my suggestion to convert this to a programmatic table in the linked issue. That might make this entire chart easier to manage (for authors and users).