Missing support for PDF/UA-1 export

[SeSodesa]

Let's take the following Typst document:

#import "@preview/zero:0.6.1"

#set document(
  title: "PDF/UA-1 issues"
)

#title()

#zero.num(0)

#zero.zi.mm(0)

When compiling this with zero:0.6.1, the first line beginning with #zero causes the following error:

error: PDF/UA-1 error: missing alt text
   ┌─ @preview/zero:0.6.1/src/formatting.typ:14:2
   │
14 │   math.equation(sequence(items))
   │   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   │
   = hint: make sure your images and equations have alt text

For the second line, the error is similar but points elsewhere:

error: PDF/UA-1 error: missing alt text
    ┌─ @preview/zero:0.6.1/src/units.typ:337:15
    │
337 │       result = $result$
    │                ^^^^^^^^
    │
    = hint: make sure your images and equations have alt text

Both instances of math.equation seen here should be equipped with the alt argument that provides a textual representation of the formatted number or quantity. There might also be other issues not presented here, but I have not yet tested for those.

[Mc-Zen]

Hi @SeSodesa ,
Thanks for reporting!

I can add an alt parameter to Zero that let's users add a custom description to numbers and quantities. On top and beyond that, maybe Zero can generate a sensible default description in English.

[SeSodesa]

A localization mechanism might also be implemented that looks at context text.lang and generates an appropriate localization from a dictionary of translations, such as

// context above
alt: number.sign
  + number.mantissa
  + sym.plus.minus
  + number.uncertainty
  + translations.times.at(text.lang)
  + number.base
  + translations.power-of.at(text.lang)
  + number.exponent

Or something similar. Not all localisations would have to be supported initially and the community could contribute to this.

[Mc-Zen]

This is definitely possible. It gets a little trickier with units but not impossible.

I must say that I'm not sure whether automatic alt descriptions should be added by default because they might add substantial computational cost when applied to tables of data (I need to measure this). An option would be for num.alt to accept none | auto | str with none being the default and auto the automatic generation.

[Mc-Zen]

Also notable:

In the future, Typst will automatically make math accessible in HTML and PDF 2.0 by leveraging MathML technology.

From https://typst.app/docs/guides/accessibility/. But I believe that Zero can do better for its specific case than a generic method that works for all math.

Before starting with on this, I want to gather a few considerations (list in progress)

• What's with the decimal separator, should it just take the value of num.decimal-separator? (I think this would be best)
• How should uncertainties be described?
• What can we do with the math: false mode? It uses no equations so the compiler will not complain about accessibility. However, a screen reader will struggle with reading the output nicely.

[SeSodesa]

Also notable:

In the future, Typst will automatically make math accessible in HTML and PDF 2.0 by leveraging MathML technology.

From https://typst.app/docs/guides/accessibility/. But I believe that Zero can do better for its specific case than a generic method that works for all math.

Before starting with on this, I want to gather a few considerations (list in progress)

• What's with the decimal separator, should it just take the value of num.decimal-separator? (I think this would be best)
• How should uncertainties be described?
• What can we do with the math: false mode? It uses no equations so the compiler will not complain about accessibility. However, a screen reader will struggle with reading the output nicely.

Alternative texts are superior to MathML alone, which is why even MathML itself has the intent property,: https://w3c.github.io/mathml-docs/intent-explainer. This is essentially an implementation of alternative texts within MathML.

The decimal separator is language-dependent, so you could either do as you said or require that the proper separator is provided in the localisation dictionary, if that is implemented. After a bit of consideration, it might make sense to flip the order of language and translation components in the dictionary hierarchy because it would allow you to provide a template function which determines the keys that need to be present in a valid translation (a kind of custom type).

Uncertainties could just use translations.at(text.lang).plusminus or sym.plus.minus. Or if zero supports separate upper and lower error bounds, have a separate translations.at(text.lang).plus and translations.at(text.lang).minus and inject these at proper positions in the alt text.

I don't really have a stance on math: false because I do not know why it exists.

[Mc-Zen]

I started work on implementing this!

I don't really have a stance on math: false because I do not know why it exists.

This mode is an option to render numbers/units without math.equation (instead it uses sub and super and so on) which can be useful when using a font that has no visually similar math-capable font.

[SeSodesa]

Nice. I might provide Finnish translations at some point, unless somebody beats me to it.