Consider the future of aria-flowto

cookiecrook commented 7 years ago

aria-flowto should be considered for deprecation b/c it has a number of specification ambiguities and very low web usage.

Problems with aria-flowto

lacking disambiguation rules to account for looping (e.g. a flows to b and b flows to a, so user never lands on c)
lacking disambiguation rules to account for reversing ordering (e.g. even if a browser maintains a inverse flowsfrom relationship, how do you go back from c when both a and b flow to c?)
lacking disambiguation when flowto inadvertent skips content on the page (e.g. first flows to last) even if it does not cause looping.

Low Usage @minorninth and @alice have some spider data that indicates it is used on a minuscule amount of sites, making it prime candidate for deprecation.

minorninth commented 7 years ago

I support deprecating aria-flowto.

Here's some evidence of extremely low usage of aria-flowto from httparchive: https://discuss.httparchive.org/t/usage-of-aria-attributes/778

alice commented 7 years ago

Additionally, aria-owns allows for re-ordering siblings, covering the vast majority of use cases for aria-flowto.

LJWatson commented 7 years ago

+1 to the proposal to deprecate.

I don't have recent data, but as of Feb 2016 when I wrote this post only Jaws in Firefox and Narrator in Edge/IE had any real-world support.

cookiecrook commented 7 years ago

@LJWatson

as of Feb 2016 when I wrote this post only Jaws in Firefox and Narrator in Edge/IE had any real-world support.

I am certain iOS supported it sooner than 2016, but I'd happily drop it for a better API.

joanmarie commented 7 years ago

I don't recall if SVG had some need (which might not yet be documented, let alone realized) for it or not. (I just have this weird sense of déjà vu related to accessible SVG organizational charts.) That said, I'm pro-deprecation of all things useless and unused. So, if that is indeed the situation with aria-flowto....

I'm going to tag this for 1.2 on the grounds that it cannot happen during the 1.1 cycle. If a replacement within ARIA is deemed desirable, that might not fall within the scope of 1.2, but if we have consensus to deprecate, adding a deprecation warning to the spec seems wise.

LJWatson commented 7 years ago

@joanmarie navigation of SVG (particularly data visualisations) is one of the major and unsolved challenges for SVG a11y. That said, given the problems and lack of support noted in this thread, I don't believe aria-flowto is a contender for really solving it in the wild. If the definition could be tightened up, and if more screen readers could be encouraged to support it, things might be different, but...

cookiecrook commented 7 years ago

@LJWatson wrote:

navigation of SVG (particularly data visualisations) is one of the major and unsolved challenges for SVG a11y.

@shepazu had some thoughts around SVG Connectors that I thought showed promise for general and accessible navigation. I don't think flowto is necessary for that.

LJWatson commented 7 years ago

@cookiecrook wrote:

"@shepazu had some thoughts around SVG Connectors that I thought showed promise for general and accessible navigation. I don't think flowto is necessary for that."

Agreed. I don't think the Connectors proposal had much traction, but perhaps with the revival of the SVG WG there might be an opportunity once SVG2.0 is out the door.

mcking65 commented 7 years ago

I also support deprecation. Compounding the problem of low adoption, every time I have encountered flows from or flows to on the web, it has actually made the experience worse because it was used either unnecessarily or incorrectly.

asurkov commented 7 years ago

On Wed, Aug 9, 2017 at 7:41 PM, Dominic Mazzoni notifications@github.com wrote:

I support deprecating aria-flowto.

Here's some evidence of extremely low usage of aria-flowto from httparchive: https://discuss.httparchive.org/t/usage-of-aria-attributes/778

They rely on 'httparchive:har.2016_05_01_chrome_requests_bodies' table to query data. I personally know nothing about this table, thus curious whether it provides a good representation of the web.

Also it is interesting that both ATK and IA2 provide flow_to/from relations, which are solely used to map aria-flows attribute in Firefox. I recall that people said that OpenOffice and Eclipse have native support for these relations, but I don't have any real data on this. So my question would be whether aria-flow is just misdesigned or the web indeed doesn't have any worth examples for the flowing model?

Thanks! Alexander.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/aria/issues/630#issuecomment-321410807, or mute the thread https://github.com/notifications/unsubscribe-auth/ABdnqYw7it1stnS9RgUJPsbuDqm-Tfdnks5sWkO9gaJpZM4Oyv8N .

shepazu commented 7 years ago

FWIW, I'm using aria-flowto and aria-flowfrom in some of my accessible SVG content and software, because SVG Connectors isn't yet a thing and it might never be. I'd prefer to keep these around, and to fix the problems @cookiecrook identifies. But I'm open to being convinced.

cookiecrook commented 7 years ago

I'm using aria-flowto and aria-flowfrom in some of my accessible SVG content and software,

@shepazu Will you provide links please? Thanks.

robfentress commented 5 years ago

Sorry if I'm violating etiquette here by commenting on this issue, but what is or would be the recommendation for representing directed graphs, if not using aria-flowto?

brennanyoung commented 5 years ago

Very interesting discussion. If aria-flowto does get deprecated, there should at least be some kind of road map for a replacement.

I don't think it would be fair to say that the low usage stats are an indicator that aria-flowto is a solution in search of a problem. The problem is real enough. The solution is simply lacking essential features.

I'm working on accessible flow charts right now, and this attribute comes very close to what I need. I am effectively implementing my own aria-flowto using data attributes, so I can steer the result and AT behavior more predictably. I could just use aria-flowto, I suppose but I am wary of variance in AT support, so custom attributes are safer for now. It's not as if there's a recommended pattern I should use instead.

Consider that aria-flowto can take a list of ids as its value, so a non-useless implementation needs to provide some way of selecting from that list. (Interaction patterns needed? Keyboard focus-management idioms? Browse mode considerations?). Each 'branch' needs a label, which can be announced by ATs. And, once selected, tabbing, or using some other 'next element' shortcut should move focus along that selected branch or pathway to the specific element indicated - it should not (IMO) visit each one in turn.

Now, the main problem with aria-flowto is that notion of 'a selected branch' (something a little like aria-activedescendant) is completely missing. And that makes it almost useless for anything non-linear. (For linear stuff we already have lists). Ergo: low usage stats, and poor implementations.

My understanding of aria-owns suggests that it is solving a slightly different problem. The draft spec states that aria-owns should be used 'when the child does not appear directly in the subtree of the owner' - i.e. its primary use case is a hack to ameliorate the lack of ancestor-descendant relationships in garbled DOM trees. But might there not be cases of directed graphs where the child does appear in the subtree of the owner? Maybe the start node is the parent of all the others! Wouldn't this contraindicate the use of aria-owns?

Final point, this article mentions

...aria-owns must not be used on elements or roles that do not support children, such as HTML input elements or img elements.

... which strikes me as a problem if we are going to use this attribute to mark up directed graphs. (Although I haven't been able to find where this rule is stated officially). Would it not be reasonable (desirable, even) to construct a directed graph using img elements as nodes?

So... if aria-owns is going to do the (important) job that aria-flowto was intended to handle, we'll need to change the spec of aria-owns. And we'll still need to have some way of specifying 'the selected branch'. I don't see how deprecating aria-flowto gets us closer to that goal.

On the contrary, the low usage stats should embolden us to 'move fast and break things' (as FB devs might say), so that we get the spec and implementations we need.

brennanyoung commented 5 years ago

Regarding a pattern for 'reverse ordering' - I suggest that one useful approach is to implement a history, so that going backwards always takes the same path you took on the way forwards. This would be meaningful with directed graphs which have an inherent direction (such as algorithm flowcharts).

cookiecrook commented 3 years ago

removing my assignment because I won't be able to address this in the 1.3 timeframe.

brennanyoung commented 3 years ago

Can we agree at least that if aria-flowto is going to be useful, then any AT that offers a "Next Element" shortcut should ideally jump (focus or virtual cursor) to the element specified by the attribute, in the case that only one id is mentioned. That would provide some clear guidance to the AT vendors about handling it.

If there is more than one element specified, we need to hash out some kind of practice or idiom for handling it, but the single id case seems compellingly useful, at least.

It occurs to me that this mechanism might even be used for bypass block (e.g. "skip links") implementations.

brennanyoung commented 3 years ago

Regarding the cases where aria-flowto has a list of ids, I suggest an implementation might behave something like a list of internal links, except that the links are not (necessarily) tabstops.

AT might offer a rotor view, floating panel or keyboard shortcut way (arrow keys?) to cycle through them one by one.

How might we label the destinations before visiting them? We're not expecting the AT to announce the ids, right? I don't think "destination 1 of X" is very useful or informative.

This aspect seems to be sorely missing from the spec. A hyperlink has both an accessible name and a target. aria-flowto only supports target ids. Could the accessible name be taken directly from the target element? This would require that the ids in aria-flowto support naming.

After choosing, the matter seems more straightforward: Subsequent use of the AT's "Next Element" feature takes the focus/virtual cursor to the one you chose.

aleventhal commented 2 years ago

Between aria-owns and aria-details, we don't need this attribute. The best argument I saw for removing was that aria-owns can't work on something like a textfield, but aria-details does work there. Also, aria-flowto doesn't actually work and isn't used anywhere. Let's kill it. We're doing harm by keeping it in the spec, which makes it look like it should work.

Ping @scottaohara

brennanyoung commented 2 years ago

We certainly don't need the current heavily flawed aria-flowto implementation, but we do need a way of browsing (non-operable) directed trees of content (such as flowcharts). aria-owns and aria-details do not address that problem at all. I wont support deprecation of aria-flowto until we have some idea how we plan to handle the directed tree use case. If it may be solved without aria-flowto (such as SVG connectors), that's fine with me.

Why not a flat text alternative (e.g. using aria-description) for flowcharts? In our case, we already have a flat text in the text book (which is PDF, not my decision). That's the primary way the information is conveyed. The flowcharts (which appear both in the text book and in our RIAs) are an at-a-glance mnemonic representation of those longer texts, a kind of visual summary of the various paths that might be taken, depending on circumstances, to remind you of the long text you've just been studying.

Note: Our auditor did not accept that the original flat text in the PDF was adequate as a text alternative because the abbreviated/compact nature of the flowchart is not met by the lengthier and more detailed flat text. (I suspect another reason is because the PDF accessibility experience is poor at best).

This is a case where the "R" in aria is not really being honoured.

aleventhal commented 2 years ago

Actually, why couldn't aria-details by used for this? Consider a tree, Food points to vegetables and fruits. Vegetables points to several veggies, and fruits points to several fruits. The aria-details property on each node would point the the child nodes, in the order they should be visited. This won't work with all ATs immediately, as some are still completing their aria-details implementations.

brennanyoung commented 2 years ago

I suppose aria-details might be viable, and it makes a lot of sense in the fruit and veg example, because (e.g.) a carrot "is" a more detailed way of talking about vegetables.

But lets say we have a flowchart choice box "Is the patient breathing?" The exits are labeled "Yes" and "No", each leading to a new box, with the "No" branch leading to another choice "Is there a pulse?", (with it's own exits) and the "Yes" branch leading to an 'end' state: "Monitor the patient until they regain consciousness"

Does it make semantic sense that "Yes" is a detail of "Is the patient breathing?" Is it a "descriptive relation"? Does that fit what aria-details is supposed to do? Maybe it does, but if so, the spec leaves room for doubt. Some clarity here would be appreciated.

Also, regarding "the order they should be visited", only one branch should be visited for the sequence to be meaningful. Which branch? The one that fits the patient right now. Following irrelevant branches does not add any value, and (in our case) could even be dangerous. The (draft) spec says

If a user agent relies on an accessibility API that does not support exposing multiple descriptive relations, the user agent SHOULD expose the relationship to the first element referenced by aria-details.

That's not going to work for us. The first element referenced is going to be wrong, some of the time.

Some other questions about flowcharts that might use aria-details to make connections

How do best we get from the 'end' of the flowchart to the top again? Is the start box a "detail" of the end box?
What mechanism will be available to the user to make that choice? Should it be provided by ATs or by content devs?
Is choosing a branch in a flowchart "operating" its UI or simply browsing?
Does aria-details point at the id of "yes" and "no"? Or to the boxes that they lead to?
How does one navigate from "yes" or "no" to the next box? Or does that happen automatically when choosing?
Maybe a flowchart choice box should have role="navigation"? Would that make any sense?

Sorry to keep beating this drum, but we use a lot of flowcharts in our e-learning materials (each course is built around at least one flowchart), and they are not uncommon in the wild. I simply can't find a good fit within the current ARIA spec.

brennanyoung commented 2 years ago

A small sketch flowchart using aria-details. Would this make sense?

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>ad flowchart</title>
</head>
<body>
<div>
    <div id="start">
        <h1>A patient has collapsed</h1>
    </div>
    <div id="callforhelp">
        <h2>Call 911</h2>
    </div>
    <div id="choice_pb"
        role="navigation"
        aria-roledescription="choice"
        aria-labelledby="choice_pbh"
        aria-details="pb_y pb_n">
        <h2 id="choice_pbh" >Is the patient breathing?</h2>
        <div id="pb_choices">
            <a id="pb_y" href="#monitor_p">Yes</a>
            <a id="pb_n" href="#choice_pp">No</a>
        </div>
    </div>
    <div id="choice_pp"
        role="navigation"
        aria-roledescription="choice"
        aria-labelledby="choice_pph"
        aria-details="pp_y pp_n">
        <h2 id="choice_pph">Does the patient have a pulse?</h2>
        <div id="pp_choices">
            <a id="pp_y" href="#monitor_p">Yes</a>
            <a id="pp_n" href="#startCPR">No</a>
        </div>
    </div>
    <div id="startCPR">
        <h2>Start CPR immediately</h2>
    </div>
    <div id="monitor_p">
        <h2 id="monitor_ph">Monitor Patient</h2>
        <p>Keep checking pulse and breathing until the patient regains consciousness</p>
    </div>
</div>
</body>
</html>

Leaning on "H1" to provide a quick affordance to get to the top of the tree here. I note that aria-details should be available on all elements of base markup. I assume this includes elements with a generic role, such as the divs used here.

(n.b. the 'medical' aspects of this example are deliberately simplified).

aleventhal commented 2 years ago

@brennanyoung ARIA 1.1 is actually pretty old by now. Take a look at the ARIA draft spec. https://w3c.github.io/aria You can now have multiple aria-details. In ARIA 1.1, only one aria-details target was supported.

It's taking literally years to screen readers to update to support aria-details. That's just how long it takes. But we're getting pretty close.

Each node in a tree of aria-details can point to all of its children, in order. The user would be informed of the presence of aria-details and provided with commands to cycle through the children, or return to the parent.

brennanyoung commented 2 years ago

I was looking at the draft spec, not ARIA 1.1.

Yes, This could work out, but it is very hard to tell without a minimum viable implementation. I'm not having much luck running my example with NVDA or Narrator to be honest. Can you name an AT which makes an attempt to handle multiple IDs in aria-details today? I want to get a feel for how it might work.

I'd be a whole lot happier if one of the examples offered in the spec for aria-details was a small flowchart, because I'm not getting much clarity from the draft wording that a flowchart choice box is a viable use case for this attribute. It doesn't really seem to be a "descriptive relation". since that implies that the "details" are subordinate to the thing that points at them. In a flow chart, I would argue that the "next" box is at the same logical level as the previous one, it is subordinate only in the sense of sequence. Can we fix this?

FWIW https://validator.w3.org/ will need attention at some point. Currently, it does accept aria-details, but if you use aria-details with a space-separated list of ids, the validator complains about spaces in ids, which is misleading.

aleventhal commented 2 years ago

Hi Brennan, implementation of aria-details by JAWS and NVDA has unfortunately taken longer than we hoped. They are both still working on it. This has reminded me to ping them for status updates. I'll see what I find out.

brennanyoung commented 2 years ago

The more I think about this (and I think about it far too much) the more I want to scream and shout "DON'T DEPRECATE, TIGHTEN THE EXISTING SPEC".

Yes aria-flowto is flawed, but the core idea is sensible, practical and very much called-for in the lagging art of accessible data presentation.

To improve it we need UA, AT and author guidance for

What (if any) accessible name should indicate any flowto target?
Is there a difference between a connector and a flowto target?
How AT's might offer a choice from among more than one flow target
Some considerations/guidance about round trip (flow to, and come back)

Nothing I have seen in this discussion so far convinces me that aria-details will handle any of these issues better than aria-flowto for the (currently unhandled) 'charting connector' use case. The aria-details spec does not address any of the flaws inherent in aria-flowto either. I'm afraid we'll be stuck with another close-but-no-cigar attribute (and poorly-accessible data) for heaven knows how long.

And the aria-details spec indicates that its prime use case is to indicate 'more detailed information' about the node, which is IMO a poor (i.e. non-obvious, and potentially contradictory) fit for the connectors on a flowchart or a sequence diagram, where the fact that the nodes are distinct from each other (rather than merely each others' "details") is very much the point of the idiom.

I strongly approve of the aria-details spec as is. I just think it's a very poor replacement for what is already promised by aria-flowto. Please let's tighten up aria-flowto, not deprecate.

weedySeaDragon commented 2 years ago

I'd like to jump in with my input on using aria-details for representing the flows in a diagram. In short: it is not sufficient. It would be mis-using the navigational abilities to try to represent semantic flow information and would incorrectly communicate an entity-details relationship where there is none.

I've recently started work to help improve a11y to diagramming software mermaid which is supported here on GitHub. (I do not have to describe GitHub here, obviously. But I do want to remind everyone that it has a vast and established user base.) Disclaimer: I am a volunteer contributor and do not speak for the owner of mermaid.

Specifically, I've started to work on adding the aria properties and information for communicating the flow through diagrams I immediately identified aria-flowto in the 1.3 draft spec as the best possible way to achieve this, only to learn that is might be deprecated and that aria-details is being considered as a viable alternative.

The specification for aria-details is very clear:

"...is for referencing elements that provide more detailed information than would normally be provided via aria-describedby

(emphasis mine)

and it provides support for navigation back and forth between an entity and the details.

aria-details has no stated purpose about representing the flow between two entities that have no semantic entity-details relationship. Certainly aria-details could be mis-used to provide navigation between two entities that are peers (or have any other relationship), but that would clearly violate the stated specification. Providing this navigation does nothing to communicate the flow of process, data, information, etc., between entities.

The flow in a diagram is not just navigation from one entity to another. It is the flow of all possible paths through the diagram and amongst all entities of all semantic 'levels' in a diagram. aria-flowto describes this as

"... an alternate reading order of content which, at the user's discretion, allows assistive technology to override the general default of reading in document source order."

Communicating these alternate reading orders (paths) in a diagram includes communicating whether entities are peers because they are sequential, one entity following another, or because they are a group of equally valid choices (ex: An undergraduate, having completed a prerequisite, choosing from 3 different classes they are now qualified to take).

Communicating flow also means communicating loops (ex: returning to some possibly previously visited entity). Because one entity might occur sequentially after another does not mean that there is any kind of entity-details relationship at all.

Diagrams that have flow are not always flowcharts with simple yes/no decisions. They may include activity diagrams, business process diagrams, and totally custom diagrams that a user dreams up. They may include paths that can be taken in parallel at the same time. They may include multiple paths that can split off or come together.

The aria-flow specification is incomplete, as others have pointed out. But its purpose is clear. Likewise the aria-details specification is clear about its purpose, which is at odds with communicating myriad possible relationships between entities in a diagram.

We (finally) are at a place where diagramming software can automatically include so much more information that will allow ATs to give all users an experience much closer to the visual diagram. That AT vendors have not supported the aria-flowsto property is a separate matter. It is a non-trivial matter, to be sure.

Providing a more complete specification for aria-flowto means that it will be much, much more likely to be implemented. With more implementation of a property obviously comes more pressure (and business sense) for AT vendors to support it.

There is a strong need for the aria-flowsto property and now more than ever there are now the technological languages and tools to support it in diagramming software. Diagramming markup tools like mermiad and plantUML are being used more and more and are opportunities for AT users to be able to get more of the natively described meanings in the diagrams.

I hope I'm not too late in adding my opinion. I've been doing software engineering since the 1980s (gasp!) and have seen soooo many standards being developed and come and go. The "being developed" process is always, always messy and imperfect. Opposing forces are many and unavoidable. Compromises are necessary.

I have been frustrated since I first was introduced to computers (back when they took up rooms and rooms) that they are not used even more to make things easier. So much more could be done -- as I surely don't need to tell this group.

We have a terrific opportunity to start bringing so much more information out of visually-based diagrams to so many more. aria-flowsto is a critical part of it.

(Thanks for reading this far.)

cookiecrook commented 2 years ago

Discussed a bit on the ARIA call today: https://www.w3.org/2022/10/27-aria-minutes.html#t08

brennanyoung commented 2 years ago

^That's encouraging!

BTW I'd love to see SVG connectors happen. Where do I push?

The little draft spec is very old and lacks context.

cookiecrook commented 2 years ago

To clarify... The ARIA WG discussion was about finding an accessible path to a general many-to-many relationship interface, similar, but not limited to Connectors. I think SVG Connectors (if it is not defunct) would be a great use case because flowchart connections are conceptually easier to explain that anything AT-specific.

If you want to push on Connectors specifically, I'd ask the editors of that document, or the SVG group directly.

spectranaut commented 2 years ago

In today's meeting we decided to have a deep dive on this discussion on December 8th, 9-10AM PST, please attend if you can @brennanyoung!

pkra commented 2 years ago

In today's meeting we decided to have a deep dive on this discussion on December 8th, 9-10AM PST, please attend if you can

Ditto for @weedySeaDragon.

@zorkow, it would be good to have you there.

weedySeaDragon commented 2 years ago

Would love to attend, but don't know how. What platform/tool is used? Assuming I need some sort of invite.

jnurthen commented 2 years ago

I created an event at https://www.w3.org/events/meetings/70a5cdcc-3341-4cee-8091-9be078aaa30d I invited @brennanyoung and @zorkow but can't find a w3c account for @weedySeaDragon

jnurthen commented 2 years ago

@weedySeaDragon if you create a w3c account at https://www.w3.org/Help/Account/ I can invite you - otherwise you can send me your email address (to nurthen at adobe dot com) and I can invite you that way.

weedySeaDragon commented 2 years ago

@jnurthen - I've created a W3 account. Thanks for the info re: creating an account. My W3 user name is "ashleyengelund" and is now linked to my github account. Let me know if there's anything else I should do. (ETA: P.S. I used to live in Wallingford, not too far from Adobe HQ. Now a little farther away.)

zorkow commented 2 years ago

Peter, Thanks for alerting me to this. I am scheduled to be in Paris that day, so it will depend whether I am back already by 6pm or somewhere where I can join the meeting.

James, thanks for sending the calendar invite. I did not renew as invited expert this Spring (as I never really attended meetings!) but I assume I can still join the meeting without any special passcode?

Best, Volker

Professor Volker Sorge Chair of Document Analysis and Accessibility, School of Computer Science, University of Birmingham, UK Adjunct Faculty, School of Information Technology, IIT Delhi, India www.cs.bham.ac.uk/~vxs

On Tue, 8 Nov 2022 at 19:24, James Nurthen @.***> wrote:

I created an event at https://www.w3.org/events/meetings/70a5cdcc-3341-4cee-8091-9be078aaa30d I invited @brennanyoung https://github.com/brennanyoung and @zorkow https://github.com/zorkow but can't find a w3c account for @weedySeaDragon https://github.com/weedySeaDragon

— Reply to this email directly, view it on GitHub https://github.com/w3c/aria/issues/630#issuecomment-1307652156, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLTZX4CYAYMTLM4WYMBTXTWHKLFDANCNFSM4DWK74GQ . You are receiving this because you were mentioned.Message ID: @.***>

cookiecrook commented 1 year ago

The ARIA WG agreed to NOT deprecate aria-flowto until a suitable replacement arises. @brennanyoung agreed to file a new issue to discuss how we may address that, with use cases and stakeholders (perhaps as a WICG project?)… Thanks all for attending the deep dive today.

brennanyoung commented 1 year ago

The WICG issue is now up and awaiting discussion. https://discourse.wicg.io/t/proposal-mechanism-to-mark-up-alternative-read-order/6109

cookiecrook commented 1 year ago

@jnurthen @spectranaut Should we re-open this (or another issue to deprecate aria-flowto?) IIRC, "Consider deprecating" was the original title of this one.

spectranaut commented 1 year ago

@cookiecrook if you want to make an issue called "deprecate aria-flowto once there is a suitable replacement" you can if you'd like :)

brennanyoung commented 9 months ago

Hmm WICG got moved, and the proposal seems to have got lost. Here it is now

https://github.com/WICG/proposals/issues/138

w3c / aria

Consider the future of aria-flowto #630

Some other questions about flowcharts that might use aria-details to make connections