Yet another baffling UX decision from Adobe

As of mid-June 2020, Adobe seems to have fixed this. Whether it was a bug or a poor decision is hard to say. I’m leaving this post up for two reasons: first, it is entirely believable that Adobe would do this intentionally; and second, regardless it’s still a good case study in the impacts of this sort of decision.

Adobe apparently updated Acrobat DC recently, which I’m only aware of because of a completely inexplicable change that’s wreaking havoc on my muscle memory (and therefore, my productivity). I haven’t seen any sort of update notification, no changelogs. But on multiple computers spanning multiple Creative Cloud accounts, this change popped up out of the blue. The change? Online help is now accessed via F2 instead of F1.

Actually, this isn’t true. Presumably, sensing that such a change would break years of muscle memory for folks who use F1 to access help1 and/or realizing that this change completely violates a de facto standard that has been nearly universal across software for decades, Adobe actually decided to assign both F1 and F2 to online help. F2 is, however, the key blessed with being revealed in the Help menu.

So, good! Adobe didn’t break anyone’s muscle memory! Except… for those of us who spend all day in Acrobat doing accessibility work. As I wrote in a 2017 post about efficiently using the keyboard in Acrobat, F2 is was the way to edit tags (and other elements in the left-hand panel) from the keyboard2.

Properly doing accessibility work in Acrobat often requires going through an entire document tag-by-tag. Unlike, say, plaintext editing of an HTML file, this is accomplished via a graphical tree view in Acrobat. It is comically inefficient for such a crucial task; attempting to make the most of it was largely the purpose of that earlier post. Fortunately, there is a new way to edit tags via the keyboard: CtrlF2.

This is an incredibly awkward chord, and I have Caps Lock remapped to Ctrl; it’s far, far more awkward using the actual Ctrl key. But let’s pretend for a minute that it’s no more miserable to press than F2. I cannot see any reason why this decision was made. It presumably won’t be used by folks who have muscle memory and/or decades worth of knowledge that F1 invokes online help. It isn’t (currently, maybe they do plan to remap F1 freeing up an additional key. It breaks the muscle memory of users who need to manipulate tags, objects, &c. It’s completely inexplicable, and therefore entirely predictable for the UX monsters at Adobe.

It’s worth noting, in closing, that this isn’t solely an accessibility issue. However, it’s extremely frustrating that there is one tool in this world that actually allows accessibility professionals to examine and edit the core structural elements of PDFs, and that the developers of this tool have so little respect for the folks who need to do this work. I could come up with countless features that would improve the efficiency of my process3, yet… Adobe instead insists on remapping keyboard shortcuts that make the process even slightly manageable. Keyboard shortcuts that I’ve been using for versions upon versions. It’s incredibly disheartening.


An accidental PDF bomb

Recently I was tasked with ensuring a two-page document was §508 compliant, something that I do every day. I didn’t really expect any hang-ups; even the most complicated two-page PDF is still only two pages. I got through the first page with ease. Navigating via the Tags panel, as I do, I landed on a table in the second page. Acrobat immediately stopped responding. Frustrating, but Acrobat is not the stablest of software, so I didn’t think much of it.

WTPDF: Role Mapping

PDF 1.7 supports a limited number of standard tags, limited enough that I can freely list them here: Document, Part, Article, Section, Division, Block quotation, Caption, Table of Contents (TOC), TOC item, Index, Paragraph, Heading, six hierarchical Heading levels, List, List item, List item body, Label, Table, Table row, Table header cell, Table data cell, Table header row group, Table body row group, Table footer row group, Span, Quotation, Note, Reference, Bibliography entry, Code, Link, Annotation, Figure, Formula, and Form.

Acrobat: The disparity of tagging methods

Prompted both by troubleshooting a comrade’s accessibility work (related to this short RPG collection which you should absolutely check out!) and a recent instance of tags in a work document turning to random bytes, I thought it might be valuable to briefly go over the three main ways to tag elements in a tagged PDF in Adobe Acrobat. Ultimately they should all do the same thing, but because it’s an Adobe product, they all come with their own unique quirks.