727819 - Make PDF.js accessible

Status: RESOLVED INVALID

(Firefox :: Disability Access, defect)

Description

[Artur Adib]

This is a follow-up thread from our Mozilla Central integration discussion in:

https://bugzilla.mozilla.org/show_bug.cgi?id=714712

Basically the main challenge is that we use a 2d Canvas to render the PDF content, and we're not sure what's the best or recommended solution for making a Canvas app accessible. 

At the moment we have a text selection backend that replicates the Canvas text into regular divs in the DOM. However, this is mostly a hack, so we're considering going all-out Canvas - see rationale below:

https://github.com/mozilla/pdf.js/pull/1205

Because of this new proposed backend, ideally any A11Y solution would not depend on our current text selection layer - although in principle we could create one just for the sake of A11Y.

I see there's some sort of support for caret selection in the W3C Canvas spec, but without any examples or experience in the subject it's hard to know what exactly the proposed API does:

http://www.w3.org/TR/2dcontext/#caret-selection

It seems to suggest we can navigate the content of a Canvas with a caret (F7?), but it's hard to imagine how that works since Canvas is rasterized. I must be missing something.

We're open to suggestions and words of wisdom from folks who have experience with making Canvas content accessible (Or perhaps PDF.js is going to be the very first accessible Canvas app? That'd be awesome :))

I guess a good starting is: What A11Y addon/software should we use to test PDF.js against?

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks for filing this Artur. I'm cc'ing
Marco - to QA any builds we can throw his way.
Alexander, Ehsan - for comments on caret/selection.

For end user testing we generally recommend using:
http://www.nvda-project.org/wiki/Download (on Windows)

Other tools and dev details are mentioned here:
https://wiki.mozilla.org/Accessibility/Contribute

Comment 2

[Marco Zehe (:MarcoZ)]

To me, this sounds like it heavily depends on the work done in bug 495912, right?

Comment 3

[Masatoshi Kimura [:emk]]

Focus management / Caret and selection management were removed from latest Editor's draft.
http://dev.w3.org/html5/2dcontext/Overview.html
See public-html-a11y about discussions.
http://lists.w3.org/Archives/Public/public-html-a11y/

Comment 4

[arky [:arky]]

I did some early a11y testing on Linux using orca. There were some UI issues with keyboard navigation, unnamed buttons and lack of accessible notifications. I believe that the pdf.js UI was planned to be revamped.  

The pdf content was accessible, the screen reader for the first few pages. There was some bug related this somewhere. 

Currently on community building road trip in India. Will pull the latest sources and continue the testing.

Comment 5

[Michael[tm] Smith [:sideshowbarker]]

(In reply to Masatoshi Kimura [:emk] from comment #3)
> Focus management / Caret and selection management were removed from latest
> Editor's draft.
> http://dev.w3.org/html5/2dcontext/Overview.html

I realize there have been some claims they were removed, but if you examine the actual editor's draft, you'll see that's simply not true. They were never removed. The editor's draft  in fact has included text that attempts to address them since before May of last year; see the following:

http://dev.w3.org/html5/2dcontext/#dom-context-2d-drawsystemfocusring
http://dev.w3.org/html5/2dcontext/#dom-context-2d-drawcustomfocusring
http://dev.w3.org/html5/2dcontext/#dom-context-2d-scrollpathintoview

Whether or not that spec text actually addresses the use cases and requirements sufficiently is something that should probably better be discussed in the W3C bugzilla.

Comment 6

[Marco Zehe (:MarcoZ)]

I ran a test with this URL:
http://mozilla.github.com/pdf.js/web/viewer.html

First thing I noticed was that there actually is text in the HTML that a screen reader can work with. At the top there are the controls, below that the text begins by listing all the authors.

What I noticed was that there do not seem to be any headings. I don't know the original of this PDF shown here, so do not know if the tags (if any) provide that information, but if dealing with a tagged PDF, those tags should definitely be translated by pdf.js, since they are specifically for accessibility.

If the PDF has no tags, we can make an approximation. Adobe, for example, can deduce tables and some other structures by analyzing untagged PDFs and providing an educated guess on accessibility.

In fact, much of what this PDF shows, esp in the code examples, looks like it would in such an educated guess scenario of Adobe Reader.

I also noticed that the PDF never seems to load fully. Whenever I hit Ctrl+End to go to the end of the document, new portions were loaded and appended.

Responsiveness was OK, there was only a slight lag when new stuff was loaded.

So, whatever mirroring takes place currently is actually quite useable with a screen reader such as NVDA that walks our accessibility tree.

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to Marco Zehe (:MarcoZ) from comment #6)
> I ran a test with this URL:
> http://mozilla.github.com/pdf.js/web/viewer.html
> 
> First thing I noticed was that there actually is text in the HTML that a
> screen reader can work with. At the top there are the controls

Marco, are the controls all labelled well?

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

I'll note that for a sighted keyboard user the controls seem to work perfectly.

Comment 9

[Marco Zehe (:MarcoZ)]

(In reply to David Bolter [:davidb] from comment #7)
> Marco, are the controls all labelled well?

Yes, no problem there!

Comment 10

[(no longer active)]

Can somebody please file a new bug only about the caret/selection stuff, and provide a clear description of what needs to happen there?  It's very hard to extract this information from this bug.

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to Ehsan Akhgari [:ehsan] from comment #10)
> Can somebody please file a new bug only about the caret/selection stuff, and
> provide a clear description of what needs to happen there?  It's very hard
> to extract this information from this bug.

And cc me.

I heard we are changing the selection backend?

Comment 12

[Bill Walker [:bwalker] [@wfwalker]]

(In reply to David Bolter [:davidb] from comment #11)
> (In reply to Ehsan Akhgari [:ehsan] from comment #10)
> > Can somebody please file a new bug only about the caret/selection stuff, and
> > provide a clear description of what needs to happen there?  It's very hard
> > to extract this information from this bug.
> 
> And cc me.
> 
> I heard we are changing the selection backend?


Although we have investigated Canvas-based text selection as a prototype, we have not committed to it, no.

Comment 13

[David Bolter [:davidb] (NeedInfo me for attention)]

Marco do we have a bug filed for tagged pdf?

(BTW I'm not sure this bug is useful anymore?)

Comment 14

[James Teh [:Jamie]]

Two things worth noting:
* Support for tagged PDF (and guessing where there aren't tags) will very much change the structure of the HTML representation of the content. Aside from headings, tables, etc., text should also flow better. That is, a single block of content (e.g. a paragraph) should appear in a single block element instead of multiple block elements. Right now, text breaks in awkward places.
* Tagged PDF can specify the reading order of the content. In extreme cases, the reading order can actually mix content from different pages. There are valid use cases for this; e.g. a 2-page brochure where you are meant to read some parts across both pages instead of reading all of one page and then the other.

Comment 15

[Marco Zehe (:MarcoZ)]

(In reply to David Bolter [:davidb] from comment #13)
> Marco do we have a bug filed for tagged pdf?

Yes, bug 861157.

Comment 16

[Marco Castelluccio [:marco]]

This tracking bug has served its purpose.