[Ally]: requires longer PDFs to have headers

[teepeemm]

Ally complains that the following "PDF does not have headings":

\DocumentMetadata{tagging=on,lang=en-US,pdfstandard=ua-2,
 tagging-setup={math/setup=mathml-SE}
}
\documentclass{article}
\usepackage{lipsum}
\title{My Title}
\begin{document}
\maketitle
\lipsum[1-9]
\end{document}

According to https://help.anthology.com/ally-lms/en/administrators/ally-accessibility-checklist.html, this check is enabled when a document has at least three pages.

VeraPDF reports that this PDF is compliant with UA-2. This item is copied from https://tex.stackexchange.com/q/758803/107497, which has a possible work-around.

AllyRequireHeader.pdf

[cfr42]

Is this really a problem with Ally, though?

I guess my thought is this: a document can compile with UA-2 while still having accessibility deficits. So it doesn't follow from a document's complying with UA-2 that a validation failure by Ally is erroneous. That's only true if the problem it complains of is not actually a problem in terms of accessibility.

I can imagine the headings requirement may indeed be egregious. I don't see why a document of more than 3 pages necessarily requires headings. E.g. a short story or a long poem could easily exceed 3 pages, but wouldn't necessarily be made any more accessible by adding headers. And headings aren't the only way to add structure anyway.

So I'm sympathetic to the claim Ally's wrong here, but I don't think that can be read off directly from the fact that VeraPDF doesn't complain (or even that the document complies with UA-2 in fact).

[FrankMittelbach]

PDF/UA-1 or PDF/UA-2 have machine checkable as well as human checkable requirements. Among the human ones, one is that the tagging should be semantically appropriate. So missing headings could certainly be a semantic defect, but in that case it would be a semantic defect for any consumer of the document whether they are viewing or listening or nativating through somehow via some AT.

However, to make this a failure is a bit presumptuous in my opinion. In fact, requiring headings, say, in a short story or in a long poem, just because the page count exeeds 3 pages is in fact incorrect and may well invalidate the requirement that the tagging is semantically appropriate (and therefore would not allow for unnecessary headings). Thus, at most Ally should flag it as a warning to do a check for appropriate semantics but not fail the document and therby forcing the author to add headings that are not meaningful for recipients -- just to get a checkmark of approval.

[FrankMittelbach]

So bottom line, it is a problem with Ally

[cfr42]

My point wasn't that this is not a problem with Ally. (Sorry, I thought it would be obvious from the examples I gave that I'm at least inclined to think this is indeed a problem.)

But if you want to make the case - either to Ally that they should change their criteria or to institutions that they should change their validator - then you have to say why it is problematic. You can't just say some other validator doesn't object and some standard doesn't require it, because Ally can cite accessibility standards which do mandate it.

This seems to me a more fundamental problem with their approach. Although standards for pdf and web pages will clearly have a lot of common ground, it seems to me wrong-headed to think all documents should conform with accessibility standards for web pages.

But I doubt you will convince them to abandon that, since it has enabled them to check all kinds of documents for accessibility based on a more-or-less one-size-fits-all approach. So probably you must either try to persuade them to mitigate the most detrimental effects or you must persuade organisations that Ally is the wrong tool for non-web pages.

It seems a pretty peculiar choice for academic course content, which rarely involves web pages authored by instructors. It's almost all going to be word processing documents, powerpoint, pdf etc., all of which are after-thoughts as far as Ally is concerned.

[Maybe I am wrong about this, but that is my impression. That validating web documents in primary and everything else is more-or-less tacked on. That's not the best basis for evaluating academic course content for accessibility.]

[teepeemm]

Related: I asked Ally about this at https://usergroup.ally.ac/s/discussion/post/post/view?id=2473

The closest to an official reason there is they want instructors to add headings.

The Ally checklist refers to WCAG 2.2 - 1.3.1 Info and Relationships. Looking at its "How to meet" techniques, there's a lot about how to use headings, but not an actual requirement to use headings (at least that I can see).

[cfr42]

Indeed, as far as I can figure out the WCAG is the basis and then there are some other additions for web. Then they just modify this more-or-less successfully for the various non-web formats they support.

I admit I hadn't actually read the WCAG guidance, though. I took it their interpretation for granted. :( But having investigated the links you gave, it is really not obvious how that guidance turns into Ally's requirements. Aren't the criteria saying sections are one way to satisfy the need for structure? That is, headings seem to be sufficient, but not necessary.

I also don't see anything in the guidance for PDF there which suggests headings may not skip levels (which is another thing Ally doesn't like).

[cfr42]

It is somewhat ironic that in order to contribute to their user-group, you must pass a visual captcha???

[u-fischer]

@teepeemm
While the PDF standard does not require a heading it is not unreasonable to check for it in a longer document and I do not think that it makes sense to discuss such a requirement with an artificial lorem-lipsum document; the example you mention in the Ally discussion is more helpful here.

And this example imho demonstrates the two real problems:

• Ally does not recognize the Title tag (which is a pdf 2.0 tag)

• Ally doesn't follow its "12 paragraph" rule. In the discussion one wrote

  For Word documents, we use a minimum length threshold of 12 paragraphs before requiring headings, as paragraphs are typically the best way to define the length of a document. However, PDF documents don’t always define this (PDFs are often just a bag of characters), , which is why we use 3 pages as the minimum threshold for PDFs.

  which is more or less nonsense: we have a tagged PDF here, so it is not "just a bag of characters". The PDF has three paragraphs (if one count also the Title) and one list and Ally should count that as it does in Word instead of falling down to pages. If Ally accepts a Word document with such a structure it should accept the PDF too instead of disregarding the PDF structure.

[FrankMittelbach]

• Ally does not recognize the Title tag (which is a pdf 2.0 tag)

I guess that should be a separate discussion entry because it is a somewhat independent issue.

[teepeemm]

• Ally does not recognize the Title tag (which is a pdf 2.0 tag)

I guess that should be a separate discussion entry because it is a somewhat independent issue.

I'm not sure it's an independent issue. To clarify, Ally does't recognize the Title tag as a header. Ally is not advanced enough to check whether the tags being used in a document are valid tags. (Unless there's a UA-2 specification that the Title tag should be considered a header, which would be something we could tell Ally.)

[cfr42]

A lot of this boils down to

1. Ally doesn't use PDF accessibility standards at all.
2. Insofar as Ally recognises PDF features, it does so only for those in PDF 1.x.

From their point of view, implementing distinct criteria for different document types is obviously not a very attractive option.

[Well and they claim the web standards are the ones aligned with legislation, though they do not specify any jurisdiction and I have no idea if it is true or not.]