[go: up one dir, main page]

I want a way to mark up branching, meaningful sequences (like flowcharts)

Submitted by Brennan Young

Community Pick

I make digitalized algorithm flowcharts representing medical and life-saving procedures. These originate in nursing and first-aid text books. If they could be represented as "text alternatives" they would be in that form already. Plain text is a really bad way to represent a branching "meaningful sequence". It should be possible to make flowcharts (or any branching meaningful sequence) accessible.

I need a way to browse a flowchart "tree" topologically. I am not interested in forcing non-sighted users to imagine a spatial grid (treegrid pattern) just so they can continue through a flowchart. "Left," "Right," "Up," and "Down" are not important. "Next" and "Previous" are important, and some way to represent choices.

There's a (soon deprecated?) aria property called aria-flowto which begins to address this problem space, but it is sorely lacking an official pattern (and sufficient technique) for choosing branches as you browse it. The fact that it is close to being deprecated is understandable, but quite depressing, because there does not seem to be any effort to replace it with anything better.

My own solution so far relies on tabbing through the flowchart boxes. (Shift-tab to go backwards.) When you get to a "choice" box, you use arrow keys to select an options, then tab to follow that path.
The problem here is that tabbing is for operable content, and flowcharts are not operable artifacts.

But if I use a "browsable" role, such as list or listitem, then any interactions (such as choosing branches) are likely to get eaten by the screenreader unless I wrap the whole thing in an application role, which then requires the flowchart boxes to become "document" role elements (so that the rich text inside can be browsed). It's an ugly mess, and there are no recommended solutions available at this point.

Flowcharts—and indeed other "directed graphs"—are not uncommon artifacts. They should be expressly covered by HTML or ARIA, perhaps with a role for "choice" boxes, where aria-flowto might be placed, and where an expected keyboard idiom might be implemented. Assistive tech also needs to accommodate whatever solution is thought best.

It's a long road, but I am already quite a way along it. I need help from the accessibility community, especially including UA and AT vendors, to complete the journey!

Tagged
HTML Accessibility
This was presented at