status of tikz and derived packages

[mbertucci47]

Since the latex-lab code adds the alt, artifact, and actualtext keys to tikz, should it and all packages that allow the user to pass the keys to the underlying tikzpicture be considered compatible, so long as they do not use any incompatible libraries (which as far as I currently know are external (#945) and matrix (#30))?

I ask because I worry this might be confusing to users since it is "opt in" without a warning if not given (hence my question in #1156), and the majority of tikzpictures will not produce reasonable tagging without one of these keys. Perhaps it is enough to comment in each package's entry that one of these keys must be given for reasonable tagging. For some packages, say genealogytree, it would probably be possible to produce some automatic alt text, but that would require significant work by the package author and I don't know if the package should be incompatible while that waits to possibly never happen. See also the several recent discussions about forest.

[cfr42]

forest is not a helpful example, IMHO. forest produces (generally fatal) compilation errors by default. The problem is not that the keys are not passed through, since forest passes all unknown keys to pgf/tikz.

And it does not make sense, IMHO, for all tikz-based packages to support exactly those 3 keys. actualtext is not sensible for forest or tikzcd. artifact is not sensible for a package providing mathematical symbols.

Passing the keys through is neither necessary nor sufficient, even if the user specifies one appropriately.

[mbertucci47]

And it does not make sense, IMHO, for all tikz-based packages to support exactly those 3 keys. actualtext is not sensible for forest or tikzcd. artifact is not sensible for a package providing mathematical symbols.

Sure, they don't all make sense for all tikz-derived packages. My point was that it will probably be up to the user to specify which one does.

Passing the keys through is neither necessary nor sufficient, even if the user specifies one appropriately.

Assuming the package does not error or produce spurious tags (so not things like forest), what is a situation where none of these three are sufficient?

Also, my point about tikz-derived packages being compatible mostly applies to packages that just define some commands that go inside a tikzpicture, say, tikzducks.

[cfr42]

Sure, they don't all make sense for all tikz-derived packages. My point was that it will probably be up to the user to specify which one does.

Possibly, though I think ideally some packages would do this by default.

Assuming the package does not error or produce spurious tags (so not things like forest), what is a situation where none of these three are sufficient?

I more meant that passing the keys through doesn't guarantee you don't get errors or spurious/missing tags.

But it also just isn't clear what a proper outcome is for some packages. E.g. if tikz is used to construct a proof, tagging that as alt might be the best of the three options, but it probably isn't exactly a good option.

Is it enough for compatibility if it is possible to use the package and create a correct result, even if that requires significant effort on the part of users? I don't know what the answer to that question should be, but it seems doubtful that e.g. game-theoretic trees, circuits etc. will get usable tagging if users must specify alt explicitly. or, rather, some will, but I guess that a lot won't, especially if we are talking about reprocessing an existing corpus. but I am not sure whether that's really relevant to the compatibility status?

Also, my point about tikz-derived packages being compatible mostly applies to packages that just define some commands that go inside a tikzpicture, say, tikzducks.

Fair enough.