Document accessibility roles and responsibilities

This article was inspired by a review of W3C’s ongoing project to set out Accessibility Roles and Responsibilities Mapping (ARRM). The ARRM framework maps the responsibility for achieving each of WCAG’s various success criteria to defined roles within an organization.

The ARRM draft is understandably focused on the modalities and roles associated with preparing and publishing web content. Other use cases, workflows, and content, such as PDF, may require different roles, responsibilities, tasks, and skills.

Background

Accessible PDF documents occur at the confluence of several factors and activities. From authors to software developers, it is best to clearly define each role’s responsibilities within an organization, as well as dependencies on other organizations, applications and vendors.

When accessibility is left until PDF files are otherwise ready to be shared, the responsibility for ensuring the PDF files are accessible falls on remediators, whether on-staff or outsourced. These personnel have the unenviable (and generally avoidable) tasks of tagging and validating documents, pushing back on authors and designers regarding inaccessible design choices and, when all else fails, identifying costly, time-consuming and often less-than-ideal solutions.

Websites and Documents

W3C’s ARRM model establishes an approach to ensuring that all players in the development of web content – from creators to technologists to business people – can understand their respective responsibilities in achieving an accessible website. The roles and tasks associated with websites share many features with the roles and tasks of organizations that create, use, manipulate, or retain documents over time, but there are also key differences.

Many publication environments – from journal publishing to statement generation – can, much like websites, leverage controlled workflows to deliver guaranteed accessibility in output documents. In these contexts applying the existing ARRM model is relatively straightforward.

In other cases, documents are not publication system outputs, but individual instances from general-purpose document technology. Once a user takes possession of a document (PDF file or otherwise), each individual page may be signed, extracted, combined, redacted, or undergo other processes; all with implications for accessibility.

Unlike websites, where all content is centrally managed and supported by content and technical teams, organizations produce and collect heterogeneous PDF files created by arbitrary software, and then manipulate them with additional arbitrary software. Instead of reloading a page after solving a problem, a revised or remediated document must be redistributed.

These facts imply that the roles and responsibilities for ensuring accessible digital document content imply a distinct ARRM mapping for documents, addressing a distinct set of skills for those seeking to map WCAG success criteria to individual roles, responsibilities, and tasks within an organization.

Roles

W3C’s draft ARRM defines six macro-level roles encapsulating the range of activities typical of website development, and then maps WCAG success criteria accordingly:

The draft ARRM regards “Advanced tagging in a PDF document” as an Author’s Publishing role, which is reasonable in many cases. However, this framing doesn’t address roles existing largely (but not exclusively) outside the website paradigm, such as:

• Organizational accountability for document accessibility, regardless of the distribution mechanism (hosted on public website, hosted on internal website, sent externally via email)
• Retrofitting accessibility features to existing documents (remediation)
• Altering documents (e.g., extract, add, reorganize pages, adding metadata) while retaining accessibility
• Signing or otherwise annotating documents, ensuring that these annotations are accessible
• Redacting documents to protect sensitive information while retaining accessibility features

It’s interesting to consider a set of roles and skills that would more fully encapsulate the document paradigm, allowing for a more extended mapping of WCAG success criteria – as well as PDF/UA conformance – into organizations.

Tasks

The ARRM’s Tasks table is its “meat and potatoes”. Once a set of roles applicable to document use cases is defined, the document world should unabashedly copy this idea (with all attribution) to produce a new resource similar to the Matterhorn Protocol, which the PDF Association first published in 2014.

In doing so, it will become clear how an ARRM for web content might be adapted to address documents and support organizations across all forms of content. For example:

• Ad hoc documents and automatically generated documents do not share tasks
• Ad hoc document authors take on more responsibility than front end web developers
• Titles can be handled differently in documents; they need not be regarded as part of the heading structure
• Pagination introduces new complexities and requires new skills to be able to identify and resolve issues
• Various unique features of documents (such as bookmarks, annotations and digital signatures) may require updated skills to identify and fix accessibility issues
• Task SEM-017 is inappropriate for PDF.

For each role, the ARRM supplies a collated collection of tasks appropriate to the role (e.g., for Visual Designer), as well as a case study and additional resources.

Decision Tree

The decision tree leverages the relationship between WCAG success criteria and roles to provide a model for determining accountability and responsibility in ensuring documents are accessible. In this, the ARRM is similar to the RACI concept of responsibility roles, but applied as follows:

• Primary → Accountable
• Secondary → Responsible
• Contributor → Consulted

This model applies to high-volume document applications, but not to ad hoc documents, with fewer interlocking sets of responsibilities. At least at the content level, this feature may be overkill for a document-centric ARRM. This framing, however,  would help organizations identify opportunities to cross-skill their existing workforce in order to support both web content and documents holistically.

Conclusion

Documents are a distinct content format across critical domains – science, education, government, business, law — yet current ARRM guidance is web-centric and fails to fully account for the unique accessibility responsibilities, skills, and technologies associated with accessible digital documents.

A dedicated, document-focused ARRM would empower organizations to clearly assign roles, close compliance gaps, and scale accessibility across digital content formats beyond web content.