Nice to see, that you take a look into the " technocratic rules".
As often written: PDF 1.7 is an old and imperfect specification. That makes some things hard and will only be finally fixed by using PDF 2.0 / PDF/UA-2
But nevertheless:

1. There are no strick nesting rules, nor absolute specific BLE/ILE handling. If you read the hole chapter 14.8, you will find stages and examples, where the spec itself allowed different handling of BLEs and ILEs.
2. And yes, <Link> as a child is not directly forbidden by PDFD 1.7, but there is a lot stuff written there, makes you argumentation quite hard to proof (e.g. <Figure> has to contain graphical content).
3. It is common sense, that content inside <Figure> is ignored by ATs.

In addition, linking a Figure is a semantical question – what is the meaning of / reason for the link?
if you want to link an element, you should place that element inside a Link tag. You would only place a Link tag inside an element if you want to link just part of that element.

You are the only person i know who wants this actual tagging. All other people i know, a lot of well know experts, even from Adobe, follow my suggestion.

Once again i like to invite you to join the PDF Associations working groups. That is perfect place to discuss such things,

Lets look at specifications and ISO:
A Figure tag is a Block element
A Link is an Inline (Child) element

A Figure with nested Link will pass any machine checker (PAC, CL , VERA)

Nest a Figure in a Link will make Link Block and Figure Inline.
PAC will flag it as error.

As there is nowhere it says that a Figure with nested Link is forbidden, there is nothing wrong with this, it will read correctly, it will pass the rules and will save time in remediation.

Therefore the change in InDesign is a good change.

But by all means, convince Axes that their pdf/ua check in PAC and AxesPDF is wrong.

Contents item for Links is however defined. But is not read by any AT omitting information to the end user. Alt text, however, is read but it is not how it is specified.

I know ‘someone’ wrote on LinkedIn you do not even have to test in AT, that I can not take very seriously as then you have no idea what in reality works for the end user we are all remediating for.

Strongly agreed Rainer!
All other tools (e.g. Word )generate an InDesign 2025 and before like structure.

Irony won't help the InDesign developers to make the right decision.

To me it sounds like either all AT tools have to change their behavior or one tool (InDesign).

From a global perspective I'd say it's better to do such change only in one software.

It is never a good idea to put irony in a bug report (discussion). I saw enough things going wrong by misunderstandings…

“ I ask that you refrain from interpreting Frans' comments arbitrarily and instead stick to the facts.
I never said that alt text should be used. That is also completely incorrect from a technical standpoint.”

You really should learn to understand irony 🥴😆

" I’m happy to understand that you now say: ‘use an Alt Text, that is read instead of Contents item"

I ask that you refrain from interpreting Frans' comments arbitrarily and instead stick to the facts.
I never said that alt text should be used. That is also completely incorrect from a technical standpoint.

Regarding the bug report itself: I sincerely hope that the InDesign team will provide proper support for the PDF 1.7 standard, especially since my colleagues at Adobe share the point of view I have outlined.

If PDF 2.0 will be integrated in IInDesign, there will be indeed beter technical solutions.

“ But as said before, it is assumed that figures substructure will be ignored by AT.”

What really IS ignored by AT (at present) is the Contents item on Links, I’m happy to understand that you now say: ‘use an Alt Text, that is read instead of Contents item, think about the end user.’ But then again, I’m sure you won’t…
Anyway, my last reply here, I’m done with this discussion. Adobe, thanks for the change, most of use feel it is a oke change.
Lets wait for support for PDF2 and pdf/ua2, seems a better idea.

What should this link tell us or proof?
Indeed a good result of testing tools do not 100% proof its perfect conformance.
Running the mentioned ID2025 and ID 2026 tagging structure for link and figure in PAC, PDFix-veraPDF and Acrobat preflight both cases all get a green checkmark in all tools.

But that is logical! As i said both ways of tagging are not violating the spec. But as said before, it is assumed that figures substructure will be ignored by AT.

Just a reminder:
https://pdfix.net/pdf-accessibility-validators/

Of course there are (always) bigger problems within InDesign. But nevertheless even the small ones should be reported.

Standards are a good thing, and InDesign should follow the recommendation of the people who run the PDF standard.

As written, <Link> inside <Figure> is not strictly forbidden in PDF. So a check will not fail.
But PDF as the PDF 1.7 spec was written a long time ago it is not perfect. As so, there a guidances like the Tagged PDF Best Practice Guide to give hint how to use Tagged PDF the best way.

Hope Adobe will listen to the peoeple how wrote PDF/UA and to a opinion given by on person.

Thanks.

Klaas, it works, it is allowed and passes machine checks. It is fine, just give it a rest and focus more on actual user accessibility experience than technocratic rules (you won’t, I know).
Please Adobe, keep this change as it is perfectly allowed this way.

1. As the image is linked, it is semantically appropriate the bring this relation into tagging structure
2. In PDF 1.7 it is not expected substructure of <Figure> to even be available to AT due to the Alt. It is not prohibited substructure for Figure; it is simply assumed that it would be ignored.
3. The was a discussion about this in technical working groups, we all agreed that in PDF 1.7 context the InDesign 2026 ist not correct / practically.

And YES Frans, some AT might not give a good output. But InDesign should provide a correct tagging. I hope AT will handle this correctly in the future.

This is NO bug but intended. Both are allowed and the change means Placement Block/Inline is now correct. A good change.

Thanks for fixing it soon!