[the_other]

Flow charts are a terrible use case for CSS (and HTML). The nodes and edges of a flow chart are all meaningful data. When you render the connectors using a mixture of empty divs, pseudo-content and largely arbitrary hacks, all that meaning gets lost from the _content_ (the HTML). Access tooling will largely fail to communicate your intent.

Flow charts are much better represented by something like PlantUML or Mermaid, and then rendered direct to SVG or a canvas. The mark-up is much more human-readable and could be used as source to drive an even-more accessible alternative.

[staminade]

Why not represent them as PlantUML or Mermaid and render to HTML/CSS? That way you get far superior layout capabilities, particularly for text, than SVG or canvas provide you.

[dgb23]

You can embed HTML in SVG, vice versa and use CSS on both.

In fact one little trick if you are doing a complex animated layout with SVG is to nest HTML elements with it that you animate it via CSS transitions or keyframes, which are much more optimized than SVG animations in browsers.

[lukan]

I think it is possible to use this as just the renderer and have your actual data of the nodes in a clean state elsewhere (as JSON for example).

[livrem]

Could have it as an output format for something like Pikchr, but not sure what the advantage would be over just generating a SVG?

https://pikchr.org/

[mock-possum]

That’s an interesting point - how accessible is JSON to differently abled users?

[lukan]

Was that a serious question?

If so, JSON is just a raw data object. I suppose one could read it with a screen reader, but whether that makes sense depends how the data is structured. But it would not be a great experience.

[fkyoureadthedoc]

It's just a cool CSS demo. I don't know why contrarian comments with little actual substance and mostly baseless speculation are so well accepted here.

> The mark-up is much more human-readable and could be used as source to drive an even-more accessible alternative.

Any examples of this _actually happening_, does the tooling exist?

Well rather than just saying that I'll actually check. Looking at Mermaid, the only thing I can find with regard to accessibility is what Mermaid does by default. No other first or third party tooling.

I just tested that with VoiceOver on their accessibility documentation page, and it does not work well on the page. I can get labels but not the title/description. Pulled some of the charts to their own page, and you get title / description of the chart (if the person who did the mermaid markup decided to add the special accessibility fields), then you can arrow through some of the text internals of the chart, but you get no semantic information.

Quite easily replicable in OPs solution if you're so inclined, and you could even take it further, although it would be a lot of manual effort.

[the_other]

Sorry… I didn’t mean to imply that PlantUML or Mermaid had any accessibikity support out of the box. I’ve not tested it and wouldn’t expect it to do that.

My point was more that the raw Marmaid “code” is more likely to communicate the content of a flow chart to some users with certain access needs than a diagram made of divs. In the same way that raw HTML, or HTML rendered with no stylesheet is (should be) more accessible than a document with accordions and carousels.

I accept there probably isn’t tooling to turn Mermaid into a more accessible diagram yet. But there could be. If instead you transmit the diagram as HTML with CSS hacks, you’re losing all the semantic data through the informality of the solution.

I left my contrarian comment because fancy demos have a habit of turning into justification for further “clever” but flawed work. A naive user might see the flow chart example as “good” andnpropose they use the hack in their own project. The solution prevents certain groups of people from accessing the data.

Saying it another way: hacks shouldn’t be used to endorse a new technology.

[Veuxdo]

> When you render the connectors using a mixture of empty divs, pseudo-content and largely arbitrary hacks, all that meaning gets lost from the _content_ (the HTML)

Well, yeah. But you can commit the same sins in SVG and canvas. There's certainly no rule that HTML can't be used to make effective, meaningful diagrams.

[arcbyte]

He just laid out the rule. It's a bad idea for very good reasons.

[Veuxdo]

Re-reading it, he did limit his rule to not using HTML for _connectors_. I can't refute that; that sounds like a bad idea for anything that isn't a toy POC (which this submission certainly is).

I do think a mix of HTML (for boxes) and canvas/svg (for connectors) is viable, however.

[the_other]

If you can mark up where the connectors go in a way that makes them accessible, you have some chance of making this work.

I think it would require extensions to HTML. There are already mechanisms for linking some elements to others, but most of them have pre-defined semantics (labels for controls, headers for sections and widgets). The closest is probably the `form` attribute that links form controls to a non-nesting `<form >` "parent" element... but forms are a worse hack for a flow chart than CSS connectors.

[woopsn]

I tried a few techniques, in terms of accessibility I think "old" ways are the best here.

    <div class=flowchart>... crazy modern shit ...</div>

    <ol class=sr-only>
      <li id=step1> Water on stove.
        <ol>
          <li>Boiling? Proceed to <a href=#step2>Step 2</a></li>
          <li>Otherwise return to <a href=#step1>Step 1</a></li>
        </ol>
      </li>

      <li id=step2> Cook dumplings in water. Wait a minute.
        Floating? Proceed to <a href=#step4>Step 4</a>.</li>
        Otherwise proceed to <a href=#step3>Step 3</a>.</li>
      </li>

      <li id=step3> Stir dumplings. Return to <a href=#step2>Step 2</a>.</li>

      ...
   </ol>

(or start with the anchors/list, and progressively enhance)