search

web-platform-tests / interop-accessibility

Accessibility Testing for WPT
https://wpt.fyi/results/?q=label%3Aaccessibility
43 stars 5 forks source link

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

Open cookiecrook opened 1 month ago

cookiecrook commented 1 month ago

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.

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.

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

cookiecrook commented 1 month ago

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

jcsteh commented 4 weeks ago

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 commented 4 weeks ago

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 commented 4 weeks ago

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.