I have a website where the users can download & view PDFs in browser. I noticed when running an accessibility report on those pages, they are failing in the following two issues:
Documents must have title element to aid in navigation.
html element must have a lang attribute.
The browser page that the PDF sits on does have a title and lang attribute, I can confirm.
I gather this is related to the actual PDF, so I downloaded it then opened it in Adobe Acrobat Reader. If I then go to File > Properties > Description, I can see the document does have a title field. Equally, if I go to the Advanced tab I can see the language is set to en-GB.
Can anyone advise on why it is therefore failing the accessibility scan on those elements?
These errors concern the PDF viewer integrated in the browser, and there is nothing you can do about that.
Both Firefox and Chrome do not assign a language to the HTML that is loading the viewer in the tab. Firefox does expose the document title in <title>, Chrome does not (the whole <head> is empty).
Practical tips
You can provide hints, but cannot control which software opens the linked PDF on the user’s system.
You should make sure that the link makes clear that the target is a PDF file, so that users can take a choice how to treat the link. They might choose to download it from the context menu and then open it in their desktop application.
Many users prefer to know the file type when opening a file that results in opening a new application to view the file, so it is often regarded as useful to include this additional information. However, this is not required for compliance with this Success Criterion.
It’s also helpful to state whether the linked PDF is accessible or not.
Example: Welcome Book (PDF, not tagged for accessibility)
See also PDF link and accessibility -- download yes or no?
Related
I'm creating a site with downloadable PDF links in which we add a parameter at the end of the file download URL to tell the browser how to serve up the file:
https://example.com?ref=0&download=y
Using the parameter download=y opens the browser's file download dialog, asking the user to save the file to their desktop so they can open it with their machine's default PDF viewer.
Using download=n will open the browser's built-in PDF viewer, allowing the user to read the PDF without saving it to their machine.
I'm trying to understand which approach is more accessible for mobile / desktop / users with disabilities. Is one approach inherently better than the other from an accessibility perspective?
You could always let the user decide. If your link went directly to a PDF, then the user can change their browser settings to either view the PDF within the browser or to use an external viewer. I much prefer that over the web developer trying to choose for me (no offense). Personally, I like to view the PDF externally in Acrobat because the screen reader handles the PDF pretty well if the PDF is tagged. If you don't have a tagged PDF, then it won't matter how you serve up the file because the visually impaired user will have a tough time reading it.
Letting the user decide is the correct approach. This isn't a setting that you should be attempting to configure for accessibilty purposes.
Having properly tagged PDF documents is vastly more important.
It's also good practice that any HTML links to PDF documents be labeled as such in the anchor text.
e.g. Title of Document (PDF)
My web application has an feature wherein preformatted RTF documents are used as templates and the user can select the source of data and then merge with the RTF documents templates to create merged RTF files. The RTF templates have placeholders which get replaced with user selected content. The final doc can either be saved or opened directly if word/wordpad is available on the local users machine.
Now, I have a requirement to display the merged document to the user for confirmation. The user may either print or save the document to the system directly. The display should not be word/wordpad application but should be within the application itself, using textarea or something similar to render the document. Can you please let me know if its possible to render the RTF document in textarea or not. Along with the displayed content, there should be options to print and save the document.If I have to convert the RTF to Html and then display the html content in textarea , please let me know how i can do the conversion and then display the html in the page.
That's a very difficult requirement. First of all, let's dismiss the idea about a <textarea>, because it does not support any formatting at all. All the WYSIWYG editors you've seen out there are based on <iframe>s.
Secondly, no browser can directly display a RTF. You can embed it as an <object>, and some might show it (IE probably will), but I can't say which ones won't. Portable devices almost certainly won't. But you should test this though, maybe it works well enough after all.
Failing that, HTML conversion is also out of question, because RTF has very very many features that cannot be emulated in HTML. There are some converters out there (google), but but they will all come with serious limitations. If you want full support, you will have to do your own rendering via Canvas or Flash or something.
To this end I'd suggest checking out Google Docs. They've gone through all of this hassle and have a rather feature-full engine for displaying most possible documents. I think it was also possible to embed them in your own webapges, though I've never checked it out myself.
Use a <PRE> tag to Display/Render RTF doc in browser.
My web app allows export of data in a variety of formats. The export is triggered by selecting an export format from a dropdown (<select>), which causes the form to be POSTed and the file returned and downloaded in the requested export format.
This works fine on all browsers except for IE - on IE the "To help protect your security" blocker appears, and clicking on the "Click here for options" causes the page to reload instead of allowing the actual download.
In short IE users can't download files due to the blocker and the subsequent reload instead of download.
I know we can ask users to change their security zone settings to enable download, but for a variety of reasons this is not practical - there are a lot of users in a lot of different environments and they tend to ignore instructions.
Are the rules for what causes the blocker to come up documented somewhere? What's the legitimate, recommended way of allowing file downloads in IE? That is, for the scenario detailed below, how can I setup the HTML/form to actually let the user download the file?
Show the user a list of file formats
Once the user selects a file, download it to her computer without triggering the download blocker on IE
Have your <select> block simply inject (using JavaScript) click here to download text somewhere else in the DOM tree. Then, the user clicks on a standard link and it reloads the full page, downloading the file directly.
You can even have the click to cause GET requests..
Page of the site, built on a client-side xml + xsl technologies, some browsers like Firefox, Google Chrome, etc.. save the file as pure xml. Without the xsl and css. As a result, saved the page looks horrible. Is it possible to force the save page as html?
If you use Firefox's save dialog (6.0.2), you can see that one of the options is Web Page, Complete. This means that just like normal XML, it also finds all the other linked documents (like CSS files for example) and saves them in the appropriate directory for offline browsing.
If your browser has this feature, then you can see it in its save dialog. Otherwise, it simply doesn't have it.
In Chrome: open F12 to bring up developer tools. Go to Elements tab and right click on html-element and select Copy../Copy element in context menu. Paste into you text editor of choice and save it as an html page.
I want to know whether it's possible to get Information about opened pages in Chrome (page title, url) from third party app (not extensions)?
You can try use the Accessibility techniques. Chrome implemented IAccessible interfaces in Chromium that any screen readers can read. If you implement a screen reader like application you can easily get those data. But to do that, you would need to understand how accessible applications work.
Or you can check out ManagedSpy, where the source code is provided: http://msdn.microsoft.com/en-us/magazine/cc163617.aspx
It's definitely possible using Fiddler. In the Web Sessions list, it shows all the URLs that are accessed, and the program (and PID) that accessed them, including Chrome. If you click on one of the URLs and look under Inspectors on the right, then Text View on the lower section, you can see the <title> section for each page.