Unicode bloats and emoji kitchens

Unicode 13 is coming, and bringing with it a handful of exciting things. Particular to my interests is a new Legacy Computing section with characters like seven-segment display numerals and graphics characters like those found on the Commodore 64 and other machines of the era. Of course, new emoji are coming as well, including among other things a magic wand, a beaver, and the trans pride flag (finally!). Unicode is doing a lot of necessary language work behind the scenes as well; the 12.

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.

Accessibility myths: The misguided war on merged cells

One of the stranger accessibility myths that I often run into is that merged cells in tables are to be avoided at all costs. This is entirely antithetical to semantic structuring of data and really points to a larger issue: often, folks who are doing and talking about accessibility have no concept of tabular structure, data relationships, and the importance of context. This goes both ways – often, folks that I receive documents from will have put multiple pieces of data in a single cell, either because they don’t know how to make the cell border invisible, or because they’re afraid to merge a cell that spans all the pieces of data.


Accessibility myths: The deceitful panacea of alt text

One of my favorite1 accessibility myths is this pervasive idea that alternate text is some kind of accessibility panacea. I get it – it’s theoretically2 a thing that content creators of any skill level can do to make their content more accessible. Because of these things (and because it is technically a required attribute on <img> tags in HTML), it seems to be one of the first things people learn about accessibility. For the uninitiated, alternate text (from here on out, alt text) is metadata attached to an image that assistive tech (such as a screen reader) will use to present a description of an image (since we don’t all have neural network coprocessors to do deep machine-learning and describe images for us).

This is all very good, if we have a raster-based image with no other information to work with. The problem is, we should almost never have that image to begin with. Very few accessibility problems are actually solved with alt text. For starters, raster images have a fixed resolution. And when users with limited vision (but not enough-so to warrant use of a screen reader) attempt to zoom in on these as they are wont to do, that ability is limited. Best case scenario, the image is at print resolution, 300dpi. This affords maybe a 300% zoom, and even then there may be artifacting. Another common pitfall is that images (particularly of charts and the like) are often used as a crutch when a user can’t figure out a clean way to present their information. Often this means color is used as a means of communicating information (explicitly prohibited by §508), or it means that the information is such a jumble that users with learning disabilities are going to have incredible difficulty navigating it.


Accessibility myths: The delusion of accessibility checkers

There is a delusion that I deal with, professionally, day in and day out. That nearly any piece of authoring software, be it Microsoft Word or Adobe Acrobat, has some inbuilt mechanism for assessing the accessibility of a document. Before I get into the details, let me just come out and say that if you are not already an accessibility professional, these tools cannot help you. I understand the motivation, but in my experience, these things do more harm than good. They allow unversed consumers to gain a false sense of understanding about the output of their product. That sounds incredibly condescending, but that’s honestly how it should work when you’re talking about fields that require extensive training.


Tagging in Acrobat from the keyboard

December 2023 update via a prior May 2020 update. At some point within the Acrobat DC lifecycle, the behavior of F6 has changed. .

Since much of my work revolves around §508 compliance, I spend a lot of time restructuring tags in Acrobat. Unfortunately you can’t just handwrite out these tags à la HTML, you have to physically manipulate a tree structure. The Tags panel is very conducive to mouse use, and because Adobe is Adobe, not very conducive to keyboard use. Many important tasks are missing readily available keyboard shortcuts, and it has taken me a while to be able to largely ditch the mouse1 and instead use the keyboard to very quickly restructure the tags on very long, very poorly tagged documents.

A couple of notes – this assumes a Windows machine, and one with a Menu key2. While I generally prefer working on MacOS, I’m stuck with Windows at work, so these are my efficiencies. Windows may actually have the leg up here, since the Acrobat keyboard support is so poor, and MacOS does not have a Menu key equivalent. Additionally, this applies to Acrobat XI, it may or may not apply to current DC versions. Finally, all of this information is discoverable, but I haven’t really seen a primer laid out on it. If nothing else perhaps it will help a future version of myself who forgets all of this.