Why not just fix document accessibility at the source?
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.
Follow me here for more updates as accessibility for
documents expands and improves. Next up will be a discussion about the
convergence of artificial intelligence and document accessibility. Oh, and I’ll
be at CSUN in Anaheim, March 12-15:
