March 14, 2019

Why not just fix document accessibility at the source?

Doug Koppenhofer | Senior Field Sales Executive
hand pressing virtual image with page icon

The successful mantra of organizations striving for digital accessibility is: “always direct efforts at the source applications” because unless you address accessibility issues there, it will be impossible to keep up as changes propagate throughout content over time. This works swimmingly for website design where you have relatively few source systems, and proven strategies that can be employed equally well across those systems.

Take, for example, the use of tables. When designing web content, the accessibility best practice is to use tables only for tabular data, not as a design layout scheme. Tables must have table headers for rows and columns so people reading the table can understand the relationship of the cells. This edict works very well and can be replicated easily across an organization’s few web design environments.

Take this same idea of accessible tables, and apply it to documents, and the model quickly breaks down. Organizations usually have handfuls, or worse, sometimes dozens of ways that it creates documents. End users generate content in MS Office, including Word and PowerPoint and in Google Docs, Sheets or Slides. There are also desktop publishing applications such as Quark or Microsoft’s SSRS, Adobe InDesign and many others. Then there are handfuls of corporate systems that generate high volume transactional content or reporting content. All of these systems generate content differently. Regarding tables, some document systems will default to creating tabular data in what screen readers interpret as paragraphs, losing much of the context required to navigate the data. So, applying one overall rule even to handle something as self-contained as tables, quickly turns into a very difficult task, and requires working with many different content system authors.

This is just one reason why many large organizations choose to tackle document accessibility both before and after the content is created. For platforms that have rich accessibility capabilities, such as Microsoft Office, build in accessibility when the content is created. But for platforms that struggle or have limited accessibility flexibility, this is where post-authoring accessibility becomes a life-saver. A post-authoring accessibility system can create templates that predict what will be in your most common document streams, and can either create all of your content in accessible formats, or you can invoke this type of system on-demand, only when a document is being pulled for use. And, as you would hope, a post-authoring system has a wealth of flexibility in setting up important elements such as tables, paragraphs, lists, heading structures, URL links and alternate text for graphical content. Post-authoring systems can even make up for bad decisions made upstream in the authoring process, such as poor heading structures, or lack of alternate text for graphics.

Come see me and Crawford Technologies at CSUN 2019 in Booth 515.