“Functionality” is not constrained by content

Accessibility considerations for digital content aren’t limited to navigation, reading and interaction. For example, people routinely use documents to accomplish daily tasks. These tasks pretty much always involve navigating, reading, and basic interaction (such as following links, filling out forms, etc), but in other cases, they involve more involved tasks such as:

• File, archive a copy offline, or add to a library for future reference
• Extracting a subset of content for use in another context
• Bookmarking arbitrary locations within content
• Removing personally identifiable information (PII), or redacting other sensitive information
• Adding comments, annotations, or reviewing markup made by others
• Protecting content (e.g. via encryption, digital signatures, etc.)

All of the above tasks pertain to “content”, albeit in contexts that extend beyond basic navigation, consumption (reading) and interaction with content. All of the above tasks are of interest to any user, regardless of ability.

This article was inspired by an effort to unpack “functionality” in order to assess WCAG requirements regarding what I’ll call “contextual functionality”.

Background

The Web Content Accessibility Guidelines (WCAG) recognize that functionality is a broad concept, not intrinsically limited to the content itself. WCAG’s glossary says:

“Functionality … processes and outcomes achievable through user action”

• WCAG 2.2, W3C

WCAG regards “functionality”, not only with respect to web content, but in establishing WCAG’s objectives for a “conforming alternate” version of non-conforming content:

“A conforming alternate version … provides all of the same information and functionality….”

• WCAG 2.2, W3C (emphasis added)

What is meant by “functionality”?

Besides WCAG, W3C establishes requirements pertaining to accessibility in two other broad domains:

• Authoring Tool Accessibility Guidelines (ATAG), and
• User Agent Accessibility Guidelines (UAAG).

These specifications were intended and designed for online web content, with varying degrees of applicability to use cases involving offline contexts or “user actions” such as annotation and redaction.

Even as WCAG (more so than ATAG and UAAG) has become the global standard for accessible content, the standards’ limitations in terms of non-web content deserve recognition. What should that look like?

As noted earlier, users’ interest in contexts such as drafting, reviewing, reusing, or redacting content is not limited to those who don’t need assistive technology. If functionality beyond basic navigation, reading, clicking links and filling forms is essential to a person’s legitimate use of a given set of content, it follows that either:

• the original document is made accessible, and remains that way throughout its various contexts, or
• a “conforming alternate” must enable similar functionality as the original.

A real-world example: banking

Banks understand the necessity of accommodating contextual functionality.

Banks must consider that their end-users often perform many different types of activities with their statements and other banking documents. This is why banks provide statements as PDF files (these days, usually accessible PDF), irrespective of whether they also provide access to recent information using HTML. Of course, banks also appreciate that, by delivering PDF files, they can easily offload long-term retention to their customers (and ex-customers)!

Unlike HTML…

• PDF is easily captured for offline storage and subsequent use with no loss of information, presentation or functionality,
• PDF offers a stable appearance and styling consistent with the bank’s presentational and branding choices as well as downstream users’ expectations for formal documents,
• PDF documents can be annotated (e.g., to add a note for one’s accountant or attach a spreadsheet),
• PDF documents may be bookmarked at arbitrary locations (i.e., users can define their own anchors and create their own bookmarks),
• PDF documents can be redacted to protect information,
• PDF documents can include content from various sources (e.g. scans of receipts or related invoice documents might be appended to create a single more encompassing document),
• PDF files can be digitally signed and the signature subsequently independently validated) to establish authenticity and non-repudiation,
• PDF files can be encrypted, to control future access.

The web technology stack can do some of these things, but it’s the combination of features that makes PDF valuable in its own right.

The web makes it easier to filter recent banking transactions but, unlike PDF, does not establish the results as a reliable “document of record”. If a customer changes their bank, or if their bank is acquired, or if the bank only hosts statements for a given period of time, users may no longer have access to their old banking information which they may need for tax, loan applications, etc.

These functional attributes are not merely “nice to have”. PDF provides the offline portability, reliability and flexibility demanded by users in a wide variety of digital document contexts.

Content vs. contextual functionality

For digital text and images functionality may be understood in two broad categories: content and contextual.

Content functionality

Content functionality is WCAG 2.x’s focus. It supports accessibility in basic user actions such as:

• Navigating
• Clicking a link
• Filling a form
• Using a control

Content functionality is primary - contextual functionality is irrelevant if the content cannot be understood. The full range of “processes and outcomes” users act on, however, is broader.

Contextual functionality

Contextual functionality may be considered at the document (or page) level or the content level. Examples of document / page contextual functionality include:

• Retain a trusted copy for offline reference
• Search for a word or phrase (addressed in UAAG)
• Bookmark or share links (addressed in UAAG)
• Encrypt or digitally sign (or validate) content

Examples of contextual functionality for content include:

• Editing, including accessibility features (addressed in ATAG)
• Add markup or other annotations that are not part of the page content
• Redact specific elements of content or metadata
• Extract / unify subsets of content - including from offline sources - while retaining layout, styling and semantics (addressed - in principle at least -  in UAAG, depending on whether styling is considered as “content”).

Conclusion: implications for “conforming alternates”

Modern organizations have an unambiguous responsibility to provide equal access and functionality to all users, irrespective of ability. But what do these organizations consider as “functionality”?

WCAG is now the established authority across all forms of content, including web pages, EPUB, word processors, PDF, and more. As of this writing, however, WCAG and the other W3C accessibility publications do not provide clear guidance on what "functionality" means for digital documents in general. This should change, and accordingly, WCAG’s discussion of “conforming alternates” needs improvement in recognition of the real-world “user actions” that may involve web content but are not constrained by it.

Absent this improvement to guidance, WCAG’s implementers will continue ignoring substantial categories of functionality.

WCAG is invaluable in terms of establishing conventions for "content", but it’s not quite sufficient to address content across all reasonable contexts. Tagged PDF has existed for 23 years, and supports WCAG-compliant content, but this is only part of what is required for electronic documents.

The broader industry still has a long way to go to ensure that the comprehensive set of common “user actions” on digital documents are accessibility-supported. This is, at least in part, due to mixed signals. If policymakers came to understand that the full scope of “functionality” requiring accessibility support isn’t defined by the functionality inherent in “web content” - the prompts to authoring software vendors, document management vendors, the PDF technology folks, and many others, would improve.