I.e. thanks to using a PDF we can give authors full flexibility on how to lay out their article, which allows folks to be really really creative (as you can see in this issue). The obvious problem with that (apart from countless hours foxtrot_charlie - our DTP/PDF programmer - has to spent on fighting with PDF weirdness) is that reading an A4 PDF isn't great for phones, computers screens, or tables. It's even worse if you're using a screen reader, since getting PDFs in the way we get them and making them screen reader compatible is... complicated, to say the least (that's why it's not yet there). On the flip side, everyone has a PDF reader nowadays, articles look everywhere the same (this wouldn't be true for other formats), and it's also printable almost out of the box.
So, pros and cons. At the end of the day I don't think there's an easy out for us without breaking any of the things which make Paged Out! what folks like about it. The things I want to improve is getting printed versions more accessible, and some day finally getting solid screen reader support. But other than that I do believe the scrolling problem with remain with the zine.
ETA: Actually I also want "readings" of articles to become a thing. From the get go we put the in the author's license (note: not all articles use it, but most do) the ability for folks to agree to have their articles be recorded in an audio form. I think that would be cool for folks who like consuming things like audiobooks or podcasts. And it would save us from scrolling (for the cost of having illustrations described instead of seeing them).
I'd still keep in mind that this format severily limits reach in times where short (kudos for one page thing!) and accessible form is an expectation.
Nevertheless - I will keep reading and spreading the word.
Tangenatially. How would audio reading work for posts with code samples and diagrams in it? Do you have an example of that?
Most illustrations are a bit simpler to handle than code and the way is pretty much paved by HTML img alt texts (the well written ones, that actually can substitute for the illustration by conveying the same information). Ideally we should receive the ALT texts from article authors, but effectively (for now) it would be up to the person reading to come up with a solid substitution text.
Code is a different can of worms. My favorite idea so far is to basically explain what the code does as close as possible, without actually reading it, and then having a separate audio track with the code being read (likely just by a text-to-speech algorithm, though possibly augmented a bit to include things like "next line" or "this line has a 2-level indent" for Python code).
I don't have an example yet, but let me get back to you on that next week, since I was thinking of doing recordings for my two articles in this issue.