Determine if pdf.js accessibility can be tested with WPT and/or Acacia

[cookiecrook]

I've got an ARIA action to migrate the PDF role mappings (currently a private Google Doc) into an official AAM doc, as a joint deliverable of W3C and PDFA.

• Consider working with PDFA on a PDF-AAM document w3c/aria#2070

So it occurred to me we might be able to test the web implementation of roles and labels (more?) using Mozilla's PDF.js renderer.

• https://mozilla.github.io/pdf.js/

Seems like a good standalone task for a future Accessibility Investigation effort.

[cookiecrook]

FYI @spectranaut and @alice since Acacia testing of PDF may also be possible.

[jcsteh]

This seems workable. A few thoughts:

1. pdf.js probably doesn't support all PDF tags yet. Of course, that would be a real bug for users, but I mention it because I don't think we could say it's fully ready as a reference implementation yet.
2. pdf.js doesn't load the entire PDF document in one go. Rather, it loads pages on demand when you scroll to them. That could cause some challenges for multi page PDF documents. I'm not sure if there's a way to force load the entire document for testing purposes or not. I guess pdf.js probably has to deal with this in its own tests, so we might be able to borrow a solution.
3. I'm not certain, but I'm guessing even the initial page is loaded after the DOM is first populated. If so, we'll need some way to wait for it to be ready. Again, pdf.js tests might provide inspiration for this.

All of that said, we could certainly bring in some pdf.js folks to help guide us in the right direction.

[jcsteh]

I was discussing this with @zcorpan and two other things came up:

1. If we wanted to write the test assertions using the JS WPT framework, we'd likely need to load pdf.js into the test document, rather than embedding it as an iframe or similar. Otherwise, we'll probably run into issues accessing stuff we need in the iframe.
2. Because we're effectively exercising pdf.js rather than the browser, it may not make sense to test this in multiple browsers. Of course, any bugs in the browser's accessibility implementation will impact pdf.js, but those should be caught by HTML and ARIA WPT tests for that browser.

[zcorpan]

If we wanted to write the test assertions using the JS WPT framework, we'd likely need to load pdf.js into the test document, rather than embedding it as an iframe or similar. Otherwise, we'll probably run into issues accessing stuff we need in the iframe.

To clarify, the point it that we can't use Firefox's built-in pdf.js because such content is not reachable by author-level JS. The test needs to run pdf.js itself.