Re: Proposal: PDF alternative using HTML (ZIP/GZIP)

Bill noticed I'd replied only to him! Resending to the list.


'm slightly changing around the order of which of Bill's points I am
responding to, to put the most important ones at the top.

On Wed, Jan 27, 2016 at 2:44 PM, Bill McCoy <bmccoy@idpf.org> wrote:

<snip>

> And most of all I don't think we should even consider forking yet another
> effort on something different. We already have a "PDF alternative using
> HTML (ZIP/GZIP)", it's called EPUB, it's already widely utilized and is
> expanding into new segments of content publishing, and with the PWP work
> we're hopefully going to take that alternative much further towards full
> convergence with OWP.
>


Yes, definitely! If an existing spec is inadequate, see if the existing
spec can be modified. We don''t need more specs if they can be avoided.

<snip>

> This makes PDF inherently not mobile-ready (in terms of adjustment of
> content to different sized screens), not very accessible, and not very
> semantically intelligible in various machine-processing workflows.
> Computers can drive cars so clearly they can reconstruct text and structure
> from visual information, but it's a heuristic process. As Leonard indicates
>  it's possible in theory to create accessible PDFs but since the logical
> structure features were grafted onto PDF's sequence-of-page-images
> architecture years after the fact the result is pretty awkward which is one
> reason that most PDF creation tools (including many from Adobe) don't even
> attempt it at all, much less to the level needed to meet WCAG 2.0 standards
> (it is nearly impossible to fund PDF content that is actually conformant to
> the PDF/UA profile ).
>
<snip>

> But I do think we need to tease apart the key attributes and not conflate
> "reliable" with "packaged" with "fixed-layout". Portable Web Publications
> need to support all of these attributes even though individual instances
> may choose which ones they fully deliver on. I would, with hesitation, even
> add "accessible" to this list of separable attributes.
>

Yes, this, absolutely, except I do not hesitate over "accessible".
Reliable, packaged, and fixed layout are three different qualities. A
document can have one of them, or it can have all three of them. I would
restate the "accessibility" attribute as "something can be reliable,
packaged, and fixed layout without being accessible at all, but it
*shouldn't* be. (Technically, fixed-layout and accessibility can be
conflicting constraints; if a document is unreadable to a sighted user
without three columns, should it also be unreadble to someone using a
screen reader? And if not, why are the columns so important that sighted
users are required to use them? But that's a digression.)

Fixed-layout would not be such a problem for _everyone_ if accessibility
were built in as a baseline spec. As an example, for all PDF's very real
utility, people would not have such strong negative feelings about it if it
were possible to reflow on a portrait display such as a laptop screen, or a
small display such as a mobile device. If accessibility were part of the
minimal baseline, then tools could assume reflow would reliable work, and
that print-formatted brochure could be equally readable on your apple watch.


> I would like all content in the next-generation portable document format
> to be accessible, but as a broad-based part of OWP it's not clear that this
> is realistic to set as  a baseline requirement (hence one thing IPDF is
> considering in conjunction with our EPUB 3.1 revision is separating
> accessibility requirements into a layered profile, separate from the base
> specification).
>

Accessibility is *always* the requirement that drops off the bottom. We
have an opportunity to make that harder for people to do. If a validator
fails on accessibility check failure (at least for the machine readable
components of accessibility; obviously whether alt text is useful can't be
automated, while its mere presence can be), then it's not valid.

Deborah Kaplan