Description:
We are adding support for filling another kind of PDF forms, using XFA.

How do we test this?
Open XFA PDFs (you can find many in the bugs blocking bug 1706133, or in its "see also", or in the archive under https://drive.google.com/drive/folders/1_0UVYYrUkQ45iIHx4uXPIfy77xPkMC_Y), try to access the information in them and fill them.

When will this ship? Firefox 91
Tracking bug/issue: bug 1706133
Design documents (e.g. Product Requirements Document, UI spec): N/A
Engineering lead: Calixte
Product manager: N/A

The accessibility team has developed the Mozilla Accessibility Release Guidelines which outline what is needed to make user interfaces accessible:
https://wiki.mozilla.org/Accessibility/Guidelines
Please describe the accessibility guidelines you considered and what steps you've taken to address them:
We have simply built on top of the already existing pdf.js code base, so inherited its accessibility characteristics

Describe any areas of concern to which you want the accessibility team to give special attention:
Nothing specific, attention should be given to the entire experience of filling the forms

Can you grant me access to the drive (mreschenberg@..)?

(In reply to Marco Castelluccio [:marco] from comment #0)

Open XFA PDFs (you can find many in the bugs blocking bug 1706133, or in its "see also", or in the archive under https://drive.google.com/drive/folders/1_0UVYYrUkQ45iIHx4uXPIfy77xPkMC_Y), try to access the information in them and fill them.

The archive contains non-XFA PDFs too, I can upload an archive with XFA PDFs only if required (but probably the PDFs in the bugs related to bug 1706133 are already enough for the review).

(In reply to Morgan Reschenberg [:morgan] from comment #1)

Can you grant me access to the drive (mreschenberg@..)?

Done.

(In reply to Marco Castelluccio [:marco] from comment #0)

We have simply built on top of the already existing pdf.js code base, so inherited its accessibility characteristics

Note that initial support for tagged PDF was added recently; see bug 861157. As a result, there are definitely a11y features supported in normal PDFs that aren't yet supported for XFA PDFs.

(In reply to James Teh [:Jamie] from comment #3)

(In reply to Marco Castelluccio [:marco] from comment #0)

We have simply built on top of the already existing pdf.js code base, so inherited its accessibility characteristics

Note that initial support for tagged PDF was added recently; see bug 861157. As a result, there are definitely a11y features supported in normal PDFs that aren't yet supported for XFA PDFs.

Are these a11y features supported in PDF forms that are not XFA-based?

(In reply to Marco Castelluccio [:marco] from comment #4)

Are these a11y features supported in PDF forms that are not XFA-based?

Headings are exposed, yes. Some of the other parts aren't; e.g. image alt text isn't exposed correctly. However, the fact that we previously shipped an inaccessible feature (AcroForms support) shouldn't be a justification to ship more inaccessible features (XFA forms support). That is also true for the other bugs here that aren't XFA specific, but ultimately make XFA support (a new feature) inaccessible to people with disabilities.

OK, I was considering XFA form support as an addition to AcroForm rather than a totally new feature, but I see your point.
I'm adding back the bugs that affect AcroForm support too then so we can more easily track all of them.

The review has been carried out, so I'll close this. The individual bugs will track the individual improvements identified during the review.