Download pdf - accessibility for screen readers - pdf

I'm curious how to make an accessible button for screen readers which downloads PDF.
I know that there is an option using href and pass there an URL to the pdf file, and even a download attribute inside an anchor to open a download window.
But it's not a good way for a screen reader. The screen reader reads it as a link but actually, this is not a link because it triggers downloading a pdf file rather than redirect to another page. So this can be confusing for people with vision disorders who rely on their screen readers.
Is it a good accessibility way to create such a button? Or relying on <a href='path-to-pdf'>...</a> is completely enough and not confusing for people with disabilities ?

General answer and basics of file download
Both a link and a button are perfectly fine, it doesn't make much difference.
IN any case, it's very important to explicitly indicate that the link or button is going to download a file rather than open a page, to avoid surprise.
The simplest and most reliable is just to write it textually, i.e. "View the report (PDF)".
You may also put a PDF icon next to the link to indicate it, but make sure to use a real image, i.e. <img alt="PDF" /> and not CSS stuff, since the later may not be rendered to screen readers and/or don't give you the opportunity to set alt text (which is very important).
A good practice is also to indicate the file size if its size is big (more than a few megabytes), so that users having a slow or limited connection won't get stuck or burn their mobile data subscription needlessly.
It's also good to indicate the number of pages if it's more than just a few, so that people can have an idea on how big it is, and if they really can take the required time to read it.
Example: "View the report (PDF, 44 pages, 17 MB)"
Note that similarly, that's a good practice to indicate the duration of a podcast or video beforehand.
Additional considerations with PDF
First of all, you should make sure that your PDF is really accessible. Most aren't by default, sadly.
You should easily find resources on how to proceed to make a PDF accessible if you don't know.
Secondly, for an accessible PDF files to be effectively read accessibly, it has to be opened inside a real PDF reading program which supports tagged PDFs, like Adobe Reader.
The problem is that nowadays, most browsers have an integrated PDF viewer. These viewers usually don't support tagged PDFs, and so, even if you make an accessible PDF, it won't be accessible to the user if it is open inside that integrated browser viewer.
So you must make sure that your link or button triggers an effective download or opening in a true PDF reading program, rather than opening in an integrated viewer of the browser.
Several possibilities that may or may not work depending on OS/browser to bypass the integrated viewer. They have to be tested to make sure they work:
Send a header Content-Disposition: attachment; filename="something.pdf"
Send a Content-Type different than "application/pdf" or "text/pdf", e.g. "application/octet-stream" to fake out basic type detection
Make the link don't ends with .pdf
Use the download attribute of <a>
The most reliable are response headers. Most browsers don't rely only on file extension alone to decide what to do.

Either a link or a button is fine. The most important thing is that the user is informed about what the element does - i.e. it downloads/opens a PDF file. So, this should be reflected in the element's label, whether that is a visible text label or an icon that uses alt text or aria-label to explicitly describe the element's purpose.
I agree with Quentinc's suggestion to also inform the user upfront about the number of pages and size of the document - that's a nice touch that I don't see very often!
PDF accessibility is a whole other topic, but again as QuentinC points out, there's not much good in allowing a user to download or view a PDF that isn't accessible, so it's a good idea to ensure the PDF has been tested against JAWS/NVDA/VoiceOver/TalkBack to ensure it is readable.

Related

Generate a url for a specific text or area in a pdf (like a bookmark)

So that the link can be used in some external applications, and users in that application can click the link and navigate to that specific location (text or area) in the pdf.
Is this possible?
There are several different URL # (fragment) constructs that were introduced by Adobe for use with their web browser PDf viewer plug-in. The current accessible list is at https://pdfobject.com/pdf/pdf_open_parameters_acro8.pdf
Many newer competing PDF enabled browsers may use similar, but there is no guarantee one URL.pdf#Fits all. Most will respect #page=number&zoom view or fit but it is very variable, thus you need to check each feature across browsers.
Important to switch off any PDF remember my view settings
For your previous request using Bookmarks can be unreliable (as can the comments ID) unless you are using Acrobat and can check the bookmark function. By far the more reliable may be the use of zoom at a scroll location so here using MS Edge:-
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" file:///C:/Users/.../Desktop/CEI-PID-Sample-Rev4annotsC.pdf#zoom=300,200,200
I support SumatraPDF however its browser plug-in whilst still functional is way past EOL thus unsupported, it had a limited support for those fragments even though the CLI was recently extended for some Acrobat /Action commands.
However related to your desire the one single portable EXE can jump to well formed text blocks. Here I call "V 4508" in a fairly similar fashion
"C:\Program Files\SumatraPDF\SumatraPDF.exe" "C:\Users\WDAGUtilityAccount\Desktop\SandBox\apps\Graphics\CEI-PID-Sample-Rev4annotsC.pdf" -zoom 300 -search "V 4508"
And if I press A then the text will be highlighted for comments

Putting an iframe overlaid on a pdf document in a browser extension

I created a browser extension that lets you look up words in Wikipedia or Wiktionary without needing to open a new tab ( https://addons.mozilla.org/en-US/firefox/addon/in-page-lookup/ , almost done porting to Chrome). It is very useful when you are doing research and come across a word you don't know or want to know more about. The only thing is, a lot of research content is in PDF format. A long time ago (~2013ish) I had an older version of the app based on the old Firefox add-on framework and that did let iframes show up over pdf documents but this has not been the case for many years. I don't think the extension is even recognized in pdf documents, I get "Error: Could not establish connection. Receiving end does not exist" and there is no extension content script on the pdf page. So, my question is, is it possible to put an iframe over a pdf document? Do I need to work on the background side, and if so, how? Thanks.

Edit texts in a PDF on Chrome using Chrome inspect

Is there any way to modify texts in PDF on Chrome using the Chrome inspect tool? I was stuck because in the Chrome inspect element, differently than any other websites and even PowerPoint presentations opened in Chrome, I'm able to modify texts, while with PDFs I cannot. Does anyone know how to do it?
Edit: Yes I know that the changes made through Chrome DevTools are temporary, but usually I'm able to make those changes, even if they're temporary. But with PDFs I can't.
There are differences in the way some browsers handle PDF data.
Chromium based browsers are more traditional in that the PDF plug-in is based on a Foxit/Skia collaboration, So you need to understand in that case, the downloaded PDF you are viewing is in the binary application/pdf (file already outside of the html wrapper).
Just as you cannot edit the PDF text in Acrobat Reader, the most you can do is incrementally add comments/annotation or field data to the end of the file, before save as a secondary download. The server cannot see your changes unless you submit as an upload.
With Firefox and Google docs there is often a different approach where the PDF is "Repr"oduced as an "Ex"ample (A ReprEx of the PDF) so it is built of a hybrid image and text overlay to emulate that part of the real PDF source. When you previously or later save the underlying downloaded PDF (for viewing) it would not necessarily include any browser based HTML editing, in the saving.
There are other techniques for other cases, but to answer the basic OP question most simply, the answer is NO you cannot change a PDF body, only add notes, etc via extensions. Microsoft variant of Chrome I.E. Edge has some inbuilt annotation ability thus does not need a second extension.
Found this question because I was googling a similar situation--I was wanting to manipulate type sizes and margins on a PDF in inspector via Chrome. I found that FireFox DevTools will allow you to view those styles and even alter the content in the PDF while in browser. I am late to the game but hope this provides answers for someone else in the future.

Can a downloaded, fillable PDF form submit data to a server via JavaScript?

Although it would be nice to not use PDF, we are using a legacy system that only generates PDF forms.
I am working with some PDF forms that embed JavaScript to submit data back to a server. The form works when viewed and filled out in the browser.
Unfortunately, our users like to download the forms to their computer, fill them out completely, and only then get an error from Acrobat Reader that it cannot submit the form unless it is loaded in a browser.
How can I make the JavaScript form submission work outside of the web browser, prevent the users from downloading the form, or have the form warn them it won't work before they fill it out?
My knowledge of PDF is probably at least one version of Acrobat behind the curve, but I think the short answer to your question is "You can't".
From a bigger picture point of view: the use of PDF as a data entry user interface is a path of much pain and suffering.
If your objective is to provide a picture-perfect UI available over the web, look at solutions like Blueprint CSS.
If your objective is to provide a 'rich' user experience, look at JQuery.
If your objective is to save yourself the work of replicating an existing document as a web form, then you have not yet learned how much real work it takes to use PDF as a data-entry mechanism.

How can I embed a PDF in an email?

I've already referred to this SO post. I've been embedding images using an AlternateView for PNG files. Now I'm wondering how to do it with PDFs.
Should it work, for the LinkedResource, to just say:
Dim document As New LinkedResource(pdfFilePath, "image/pdf")
I'm just trying to figure out how to get the PDF to be embedded like I could with an image, or is that not possible and I'll have to do it as an attachment?
You can embed images since they can be rendered in place by an email client. PDFs cannot do that, so I'd recommend either having a thumbnail of the PDF that links to your web site with the actual PDF. Or just attach the PDF to the email message.
There are a few options that I know of.
1) Is the simplest way okay? The easiest by far would be to attach the PDF as a normal attachment. Then render the first page of the pdf as an image, embed it in the email and link it to open the PDF if you can. Entourage kind of does this on the Mac.
Alternatively, what I found was the following:
2) FLASHPAPER embedded in HTML displaying a PDF. Adobe has a technology called Flashpaper. It is a flash based file viewer. You can use flashpaper format documents that go into it, or PDFs as the source.
Check out some examples. That's really flash. http://www.adobe.com/products/flashpaper/examples/
Assuming you send an HTML email that will get through (images aren't turned off, etc), you can can embed the Flashpaper viewer right in your HTML code as a normal Flash object.
Most HTML email clients use Internet Explorer Bits, Webkit bits, or Gecko bits to render the html. Flash player is pretty well installed on everything, so it works well. A good example of this is when we open an email and it has video playing in it. It's almost always Flash.
I have had luck doing it this way -- the only thing you'd have to decide is if most of your clients can see this and how much (if any) today's software might block it.
What I ended up doing was a hybrid. 1) Attach it to the email, 2) Embed the Flashpaper viewer. They get it either way.
Flashpaper is available seperately for $75. It has come in handy where the client was not able to install adobe acrobat on each computer and it had to be 100% web based.
I would imagine you should be able to do the same using any language with a little more effort and using something like Flashpaper.
Hope that helps
This is not possible--at least not in a way that will work with many clients. You'll need to just attach the file.
If you have only one client to worry about, it might be possible--but not likely without manually changing settings on each client.
The MIME type of a PDF is "application/pdf" not "image/pdf"