One of the hardest things I remember from my time as a web consultant was explaining to my customers why PDF is not a suitable replacement for HTML. They always tried to replace half of their pages with pdf documents...
* If your internal workflow is designing documents then the conversion to a web document will be clunky at best.
* Every end-user device has a PDF reader and their web browser probably opens it transparently.
* You need the PDF either way way because the website will never be the authoritative source so now you have the problem of making sure they don't get out of sync.
* You probably have a few internal graphic designers that can do wonders with print but it's unlikely you have an internal web development team.
* It's much easier to make a PDF accessible than a website. (Before you disagree remember that the offices we're talking about likely don't have a dedicated web designer) You can be sure it will print correctly, and for most users it's automatically offline.
You'd have the same problem trying to read a regular book through a mobile-phone-sized window. That doesn't make books an unsuitable vehicle for document delivery.
Certainly not if the publishers took that attitude. And what you consider suitable simply isn't relevant if half the audience is now using a mobile device.
It's not a developers job to tell me whether or not my device is suitable for reading their information because they can't be bothered to make it available as HTML.
All the issues you stated stem from the fact that people don't want to change. Just because it's not the easiest way doesn't mean it's not a good one.
Everyone that can design a PDF can learn to design a nice HTML document.
I don't think it's that people don't want to change, you're still going to need print designs regardless and it's much easier to host a print design than it is to convert a website into one.
> Everyone that can design a PDF can learn to design a nice HTML document.
I mean I wish that was true. I think people can learn to write content in a web compatible way but a designer that spends all their time in PS and ID isn't going to suddenly be able to crank out high quality web pages.
Hopefully not forever.
I'm pretty sure the team at Gov.uk wrote a pretty decent article on this topic.
For example,
1. The web is a medium where you cannot (within reason) exercise too much control over the design of things. You lay out general guidelines that tell the browser how to render whatever content is thrown at it. I won't pretend this gets us predictable design, but at least it's uniform, which is good for human consumption.
2. The web is a medium that lends itself to structural document construction in such a way that it is easy to use and reuse the content in ways not anticipated. This is good for machine consumption, which in turn empowers the human.
These arguments may seem philosophical, but they do have real-world effects. Once I managed to explain it in ways the customer understood, they were always eager to be of assistance in the endeavour.
Zooming PDFs on mobile can be a pain but it's certainly less of a pain than using some fixed width site from the early 2000s with a jQuery menu you can only operate with a mouse and links so small that a mouse would fat finger them.
Machine consumption of the documents is one of those benefits that sounds cool but really just boils down to SEO because very few other things are going to be scraping your site. Certainly worth something but it's usually not high on the priority list for governments and search bots scrape PDFs anyway.
I think the main point in favor of the web is that you can have multiple presentation layers for the same underlying content and you can improve presentation independently of content. Not necessarily that it's reusable because that's just templates and a style guide but that you can backport all your fixes.
Let's take perhaps the simplest most important accessibility feature: How do I increase the font size without making the content absurdly wide, while viewing a PDF?
What we really should have done for our governments is figured out the 20 or so essential layouts and pre-coded CSS for them, but always allowed the government to fallback to custom HTML / CSS.
Documents are generally created and laid out for print and email distribution and often have very carefully laid out data tables, charts and page number referencing (as well as less important cosmetic formatting). Simply changing the file format isn't going to solve the accessibility problems and is going to create new formatting/compatibility issues, and and changing the workflow of every member of the civil service to require them to use an accessible HTML generation tool in place of word processors for anything that might be later made public isn't a trivial undertaking either. Said accessible HTML generation tool is probably going to want to change those nice HTML files back to PDF or Word files for restricted email distribution too...
You can write everything in Markdown and export to your org's Word template and have HTML, LaTeX, etc. export.
These people aren't programmers, most of them will only have a loose grasp of what a file format is. What they need are tools that don't require a programming background.
Yes, but it's not a fully ACCESSIBLE document, which is half of the point of the article.
Normal human beings understand pages, in the papery sense of the word. They don't understand viewports. It takes an enormous leap of abstraction to reason about a document that could be any shape or size. Responsive design is a fundamentally unintuitive process. A lot of professional designers fail to understand this, even after years of designing for the web.