Just wanted to drop in to say that this take reveals a blind spot with respect to visual impairment. Reflowability is really vital for visually impaired people who can still see enough to read.
Panning in two dimensions is very cumbersome and brutally inefficient compared to scrolling in just one direction, especially if you have to much of it. If you can only fit a few lines of readable text on your screen at a time, it's really painful to pan across a fixed layout.
(It's been my experience that PDFs are generally not as helpful to accessibility tools as HTML or similar formats can be, as well.)
All of this is exacerbated on displays with slow redraw as well, like e-ink. In the end, I don't even attempt to read comic books or fixed-layout textbooks on my e-readers, for instance. Nobody makes color e-readers big enough for me to read those things comfortably. And my vision is still pretty good— I don't necessarily use fullscreen zoom every day at work and I can still drive.
> the unpredictability of the layout messes with my ability to remember the location of the information of interest
Although technically the layout is fixed, navigation of fixed-layout zoom can itself feel quite unpredictable if you are also using fullscreen zoom, because now you have two layers of independent 2D panning, and all the while your viewport is only a fraction of the screen (in some cases even just 10% of it or much less). At that point, if you're looking at text, you can't see literally any UI elements, just the text. No display corners, no window borders, no title bars, no menu bar, no start menu. All of that spatial positioning you like to navigate by becomes state you have to keep track of in your head, your view of which is updated infrequently at best and only ever partially.
There's also nothing in principle stopping you from using a layout-preserving zoom on reflowable pages. Chrome and Firefox both support this, for instance. By the same token and without loss of generality, you're perfectly free to fix your browser's zoom level and your browser window's size in pixels. It's also trivial to convert HTML to PDF with any of a number of free tools that are easy to get. In contrast PDFs often make spatial navigation the only possible way to navigate, and converting the other way is much harder.
All that said...
> I really hate those who provide some technical documentation in HTML format, without offering [alternatives]
I completely agree with this. Accessibility is intimately related to flexibility, hackability, and ultimately, freedom. Docs should be provided in a way that doesn't assume or support only one way of reading/browsing/working.
I have a pet peeve kinda similar to your complaint, too: I hate it when tools have HTML docs (or even just READMEs or usage messages) but no manpage. Other formats often come in handy for me, too, but I want to be able to view the docs where I'm already using the tool, dammit!
Panning in two dimensions is very cumbersome and brutally inefficient compared to scrolling in just one direction, especially if you have to much of it. If you can only fit a few lines of readable text on your screen at a time, it's really painful to pan across a fixed layout.
(It's been my experience that PDFs are generally not as helpful to accessibility tools as HTML or similar formats can be, as well.)
All of this is exacerbated on displays with slow redraw as well, like e-ink. In the end, I don't even attempt to read comic books or fixed-layout textbooks on my e-readers, for instance. Nobody makes color e-readers big enough for me to read those things comfortably. And my vision is still pretty good— I don't necessarily use fullscreen zoom every day at work and I can still drive.
> the unpredictability of the layout messes with my ability to remember the location of the information of interest
Although technically the layout is fixed, navigation of fixed-layout zoom can itself feel quite unpredictable if you are also using fullscreen zoom, because now you have two layers of independent 2D panning, and all the while your viewport is only a fraction of the screen (in some cases even just 10% of it or much less). At that point, if you're looking at text, you can't see literally any UI elements, just the text. No display corners, no window borders, no title bars, no menu bar, no start menu. All of that spatial positioning you like to navigate by becomes state you have to keep track of in your head, your view of which is updated infrequently at best and only ever partially.
There's also nothing in principle stopping you from using a layout-preserving zoom on reflowable pages. Chrome and Firefox both support this, for instance. By the same token and without loss of generality, you're perfectly free to fix your browser's zoom level and your browser window's size in pixels. It's also trivial to convert HTML to PDF with any of a number of free tools that are easy to get. In contrast PDFs often make spatial navigation the only possible way to navigate, and converting the other way is much harder.
All that said...
> I really hate those who provide some technical documentation in HTML format, without offering [alternatives]
I completely agree with this. Accessibility is intimately related to flexibility, hackability, and ultimately, freedom. Docs should be provided in a way that doesn't assume or support only one way of reading/browsing/working.
I have a pet peeve kinda similar to your complaint, too: I hate it when tools have HTML docs (or even just READMEs or usage messages) but no manpage. Other formats often come in handy for me, too, but I want to be able to view the docs where I'm already using the tool, dammit!