Accessible InDesign Fixed Layouts?

I’d heard rumour about the use of XHTML for fixed layouts in InDesign before the announcement of the new Creative Cloud 2014 suite this month, and having text-based pages — instead of them being purely image-based — sounded like a fantastic thing.

Add that Adobe included the ability to export the epub:type attribute, and it seemed like there was a lot to look forward to as far as making accessible ebooks.

But the all important question lingered… what would the actual output look like, and would it match the hype?

Full disclosure, I’m not a power user of InDesign. I’m not even much of a user of InDesign, to be honest, as I don’t work on book layouts. I’ve certainly had enough exposure to what comes out of the program over the years, however, having converted publisher files to braille.

My point is only that I’m not going to engage in anything resembling a comprehensive review of the program. I downloaded the trial version out of curiosity to keep up with how the EPUBs are being generated, and what follows are observations focused solely on some key accessibility criteria.

The Basics

My primary curiosity was to see what would happen to basic markup structures like headings, lists and tables in fixed layout rendering, so I added a few samples and… the output file only had paragraphs in it. Alas.

To make sure I hadn’t misformatted the document, I exported to a reflowable EPUB and sure enough there were all the proper list and table tags, including the start attribute on a continuation. So there is a bright side.

I honestly wasn’t terribly surprised to see lists and tables turned into paragraphs, either, as I had a feeling that an InDesign fixed layout would mimic the text areas of PDFs (we are talking about Adobe, after all). But not even retaining heading markup was a bit of a let down.

Looking closer at the lists, the first thing that caught my attention was that the list numbering was retained in the visual output, but there were no numbers in the markup (i.e., no indication to the user that they were in a list, or what kind of list).

My first thought was that a CSS style was injecting the numbers, but the paragraphs all had the same class values. Digging a little further into the CSS, I found a transparent background image with the numbers underlying the paragraphs (it also provides the table borders):

List numbers and table borders

Lists are about as poorly formatted for accessible reading as you can get, in other words, short of using br tags to separate entries.

Tables, as you might imagine, weren’t any better. Each cell is a paragraph, so any indication of what is a header and where rows begin or end is lost. The user gets a sea of paragraphs to navigate through.

Reading Order

I expected to find a way to designate the reading order of the objects on the page, but with fixed layouts you have to be aware that the order you add the objects is the order they will be generated in the output.

You’re probably familiar with the Articles pane, and being able to drag the objects into it to build a reading order for export, but this doesn’t appear to have any effect on the EPUB fixed layout export. I built a new order and exported to both reflowable and fixed layout, and only the reflowable version matched the article order.

In other words, be aware of the order in which you add new text objects to a page if you’re only generating a fixed layout ebook. If you’re inserting dialogue, for example, and add one character’s answer before the other asks the question, that’s how some people will read it.


The other feature being touted in this release is the ability to add the epub:type attribute to the output. To do so, you have to select the object you want to tag, go to the export options and then you can select a semantic:

Export options dialog showing epub:type semantic options

While this is generally a good thing to be able to do, the list of semantics isn’t completely valid; you may wind up with errors depending on which ones you use.

There were a number of draft educational terms added in 3.0.1 that were changed during the development of the EDUPUB profile. The original, now invalid, terms are available under the educational section: assessment, practice, practices and standard. Only qna has survived from the list. All of the others are now prefixed with “learning-” to avoid future conflicts.

Similarly, the heading-number semantic in the titles section is now ordinal.

Although the epub:type field in the dialog allows you to input any value you want, the annoying thing is it will reject any value that isn’t in the dated list that was used to add the presets. In other words, you’ll have to wait for a future update before can use the correct terms. In the meantime, I’d suggest avoiding all of the above.

Additionally, a number of terms have deprecated and are no longer recommended for use:  note, sidebar, warning, marginalia, annotation and annoref. I’m not sure yet how epubcheck will report these, but whatever future version incorporates the changes will likely only emit an informational note about their use. Still, best to avoid deprecated things.

You’ll also need to avoid the figure semantic, as it’s not valid in XHTML content. Like the table and list semantics, it was added to enhance the navigability of media overlays (i.e., to allow escaping and skipping of structures). But unlike the table and list semantics, which have been rightly excluded from InDesign’s list, figure was not. Go figure.

These semantic flaws are minor in the grand scheme of things, as I’m not sure what uptake adding them will gain. It’s more likely the education semantics won’t see wide usage until EDUPUB is more stable, at which point InDesign would need a patch to align with it.

So while pure fixed layouts don’t look too appealing for accessible reading, not all is doom and gloom with InDesign. The markup coming out of the reflowable export is very nice.

If I were a betting man, I’d interpret the way fixed layouts have been implemented as providing a meaningful route to accessible reflowable publications, while retaining the concept of a pixel precise page. While some features may net no benefit for fixed layouts, like setting the reading order, they will net you a good reflowable alternative, so it’s not like they’re useless and not worth doing.

As it is, though, the fixed layout output itself is a probably a step down from a tagged PDF, at least as far as structure retention goes. There’s hope the markup and accessibility will improve with time, as the reflowable output has, but for now a fixed layout EPUB coming out of InDesign isn’t reaching the pinnacles of accessible markup.

As I said out the outset, though, having the text available is still miles ahead of any program that generates bitmap images to make fixed layouts.

And once the Multiple Renditions Publications spec is finalized, who knows, maybe Adobe will add the option to export both versions and let the end user choose which they prefer.

Until then…

8 Replies to “Accessible InDesign Fixed Layouts?”

  1. Hi Matt,

    I’ve used InDesign for a single project (so I have only one data point for reference) and that project was an FXL EPUB. Over the course of a month or so, I created the eBook layout in InDesign and then exported the FXL EPUB. I then took about another month to edit that XHTML and CSS with Dreamweaver to create the EPUB that I wanted. I agree that InDesign CC 2014 didn’t get me nearly as far as I had hoped, but it got me a long way toward the final product.


    1. Right, and it wasn’t my intention to suggest the program isn’t useful for what it does. I just had a sneaking suspicion that there’d be a “text area” approach in the FXL output that could impact on readability for some users, and the only way to confirm or deny was to get my hands dirty.

      It’s great to see the semantic output continuing to improve on the reflowable side, too, as it leads to higher-quality books getting to readers without someone having to go under the hood and tweak the output.

  2. You did not mention one other issue: InDesign’s FXL output wraps each word in a span element, each with its own independent CSS transforms (for pixel-perfect output purposes, which I think is a wrong perspective to have even for FXL, and at any rate one that can never succeed given the hererogenousness of web engines). That can cause text selection to be wonky (in iOS it does; not that proper text selection was possible already without proper reading order, but this affects intra-sentence selection too) and breaks multi-word text searches.

    So to sum up: non-semantic, partially non-selectable, non-searchable text that screen readers cannot properly read due to unreliable layout order.

    Adobe should have a sense of responsibility when releasing things in the wild proportional to the size of its user base.

    1. Ah, interesting, I wasn’t looking at individual words. I was using sequences of numbers and “foobar”s to test the structure output, so never spotted that quirk.

      I’ll assume, since I’ve let the trial lapse, that vocal emphasis of words (em/strong) is also lost, too — to the extent that it becomes CSS. Further confirms my impression that the FXL is basically the equivalent of an untagged PDF as far as meaningful structure goes.

  3. Matt, thanks for this article.

    Jorge, thanks for your insights.

    Interestingly, I remember one of their webinars whose goal was to demo the Fixed-layout export, using a badly-made reflowable EPUB as a comparison. What was remarkable, though, is the fact that several participants actually asked if ID exported accessible fixed-layout. Know what their answer was? They sticked to “the EPUB format is accessible”. And that’s it.

    Now, a lot of software vendors are using this as a marketing motto. So…

    Any chance a “conformance test” is created so that we users of this type of software can see who’s lying and who’s not when it comes to accessibility? Who knows, it might also kickstart some developing teams….

  4. Not entirely related to fixed layouts, but another problem I’ve seen is that ID uses divs and absolute positioning to layout figures and captions, and then clips any text that overflows the box it creates.

    Aside from the general awfulness of absolute positioning in reflowable documents, this approach also means that if you resize the font upwards, your caption will slowly disappear outside the boxed area, making it impossible to read.

    Only people not dependent on visually seeing the text will be unhampered, for an odd turn of events.

Leave a Reply to Antonio Cancel reply

Your email address will not be published. Required fields are marked *