What is meant by "functionality"?

[DuffJohnson]

I’m reviewing guidance for “Understanding Conforming Alternate Versions" as given here:

https://www.w3.org/WAI/WCAG21/Understanding/conformance#conforming-alt-versions

I note that a “conforming alternate version” is one that “...provides all the same information and functionality in the same human language." (emphasis added).

What is meant by “functionality” here? As used by WCAG, is this term intended to address “functionality” in terms of the content itself (links, forms, etc)... or does it also imply the "inherent functionality" (if you’ll excuse the term) of specific media?

An illustration may be useful….

A bank posts a customer’s statement as both a non-conforming PDF file and a conforming alternative HTML page. It posts the PDF because customers need the PDF's capabilities to do their work.

What are the functional characteristics of the PDF that inspire the bank to deliver their statements this way? They include:

• The ability to download the statement to be read or shared offline
• The ability to extract or merge individual pages (e.g., to assemble documentation to support a loan)
• The ability to redact content (e.g., to remove personally-identifiable information)
• The ability to annotate (e.g., to add a note for my accountant)

The above-described functionality is not (conventionally) available via the HTML page “conforming alternate”. However, AT users are entitled (presumably) to the above-mentioned functionality given that (a) the utility of this functionality isn't based on ability, and (b) these capabilities are provided to all other users.

Perhaps WCAG's definition of "functionality" could be improved to clarify that it only applies to the content, and not to the media (if that's the right way to think about it)?

If "functionality" isn't intended to encompass the capabilities mentioned above, then what is the WCAG perspective on such capabilities?

[yatil]

Functionality in WCAG refers to the web content, not the user agent. The functions you list are all provided through browsers or PDF readers, not through the web content itself. A browser could provide functionality that is equivalent to what is done with PDF files. (For example, Safari allows a website to be saved as a web archive for offline viewing.)

[DuffJohnson]

So far as I am aware, WCAG never clearly defines the boundaries of what is considered “content functionality” vs. “user agent functionality”.

Ok, let’s assume that WCAG doesn’t, and isn’t intended to, address the functionality I’m referencing - maybe that is (or should be) UAAG and ATAG stuff.

One difficulty, from my perspective, is that legislative and other efforts to govern communications technologies for the purpose of addressing users with disabilities tend to focus on WCAG. Accordingly, these other categories of functionality are off the table. AT users do not have any basis to expect that WCAG conformance implies better access to annotation, redaction, document management features and others if WCAG's idea of "functionality" remains the only basis for determining the obligations of responsible parties.

In particular, this raises questions about when and whether a served web-page can serve as a “conforming alternate”. If AT users are interested in functionality that WCAG ignores, how can WCAG sensibly define what constitutes a “conforming alternate”?

[patrickhlauke]

WCAG is a floor, not a ceiling. It wants to make sure that people have baseline ability to access information. It gets tricky when a certain alternative then provides further options/ability to manipulate things that go beyond this basic access need. If the problem is legislative efforts, that may be the place to push for changes, rather than trying to crowbar this back into WCAG?

[DuffJohnson]

WCAG is a floor, not a ceiling.

Certainly, that’s the designed-intent… but in practice it doesn’t seem to work out that way thus far, IMHO.

It wants to make sure that people have baseline ability to access information.

Does WCAG mention “functionality” only in service of “access to” information? Or does functionality imply use within a workflow? Surely also the latter?

One ask I’d have is to improve the text discussing “functionality” to clarify the scope of what classes of functionality WCAG is intended to consider or not consider. This would be of use is helping implementers to consider accessibility in use cases that fall outside WCAG’s scope.

It gets tricky when a certain alternative then provides further options/ability to manipulate things that go beyond this basic access need.

It does. However, if WCAG isn’t intended to address classes of functionality that tend to occur in common workflows, then, probably, what’s meant by “conforming alternate” should be reconsidered (tightened).

If the problem is legislative efforts, that may be the place to push for changes, rather than trying to crowbar this back into WCAG?

I agree - don’t crowbar it back into WCAG. But, perhaps clarify WCAG to ensure that legislators better understand its scope, and can thus account for (and thus drive investment towards) accessibility in common use-cases that aren’t addressed by WCAG.

[DuffJohnson]

I wrote a short article to elaborate on this subject:

https://pdfa.org/functionality-is-not-constrained-by-content/

If my point is valid I'm happy to work on suggestions for specific changes to text.

[GreggVan]

WCAG is a floor, not a ceiling.

Certainly, that’s the designed-intent… but in practice it doesn’t seem to work out that way thus far, IMHO.

Not sure what the intent of this comment is. WCAG clearly states that is a floor and that more needs to be done.

It wants to make sure that people have baseline ability to access information.

Does WCAG mention “functionality” only in service of “access to” information? Or does functionality imply use within a workflow? Surely also the latter?

Not sure what "in service to" means. We talk about the functionality of the page. We do not know or have any control over the myriad of different uses that any particular user may make of any particular page. We do consider the process that the page is intended to be used in when known and especially if it is part of a workflow on the website.

One ask I’d have is to improve the text discussing “functionality” to clarify the scope of what classes of functionality WCAG is intended to consider or not consider. This would be of use is helping implementers to consider accessibility in use cases that fall outside WCAG’s scope.

This is a good ask. But it is not clear exactly what you are asking for. If you can suggest actual text changes it would help. We can then consider it for the Understanding WCAG 2 doc and also for our work on W3

It gets tricky when a certain alternative then provides further options/ability to manipulate things that go beyond this basic access need.

It does. However, if WCAG isn’t intended to address classes of functionality that tend to occur in common workflows, then, probably, what’s meant by “conforming alternate” should be reconsidered (tightened).

Can you explain what this means and give specific examples? Again any specific wording changes you can propose - it would be most helpful in understanding your comments.

If the problem is legislative efforts, that may be the place to push for changes, rather than trying to crowbar this back into WCAG?

I agree - don’t crowbar it back into WCAG. But, perhaps clarify WCAG to ensure that legislators better understand its scope, and can thus account for (and thus drive investment towards) accessibility in common use-cases that aren’t addressed by WCAG.

Suggestions? Suggested text?

[DuffJohnson]

Not sure what the intent of this comment is. WCAG clearly states that is a floor and that more needs to be done.

We absolutely agree more needs to be done! The intent of the comment is to observe that, regardless of what WCAG states, those adopting it appear to:

1. regard WCAG conformance as a “target", rather than a “floor” or a “ceiling”, and
2. regard WCAG as specifying, not only accessibility for “web content” but for digital content in general.

Not sure what "in service to" means. We talk about the functionality of the page.

Ok, so I've imputed the intended meaning of “functionality” correctly.

We do not know or have any control over the myriad of different uses that any particular user may make of any particular page.
We do consider the process that the page is intended to be used in when known and especially if it is part of a workflow on the website.

I appreciate the clarification that WCAG doesn’t consider functionality outside that provided by the web content itself. This makes sense, but implies caution in considering whether a WCAG-conforming alternative is an appropriate replacement if it lacks the original's functional attributes.

It does. However, if WCAG isn’t intended to address classes of functionality that tend to occur in common workflows, then, probably, what’s meant by “conforming alternate” should be reconsidered (tightened).
Can you explain what this means and give specific examples? Again any specific wording changes you can propose - it would be most helpful in understanding your comments.

The example given in the OP and my article is that of bank statements, which are commonly presented in both PDF and HTML.

Consider another common use case: bookmarks. Anchor locations (i.e. id attributes) are in web-content… but web-content users can only bookmark author-provided anchors (if any), the existence and location of which are not within the user’s control. Contrast this with PDF, which allows end-users to define and control arbitrary bookmarks.

It’s easy to imagine use cases in which bookmarking functionality is important to users, but is disregarded by WCAG-conforming HTML-based alternatives. PDF bookmarks are heavily used in a very diverse range of cases. And yet, WCAG conformance leaves these use cases on the floor, and thus sends the wrong signals to developers, authors and regulators alike.

PDF provides value to users in these use cases owing specifically to the functionality that PDF makes possible.

Given the intended definition of “functionality”, WCAG’s focus is on whether the text is readable, the figures have alt text, the colors have appropriate contrast, the fields and selectors are accessible, etc. WCAG does not address functionality such as whether the content can be redacted, or annotated, or bookmarked, or subdivided without loss of semantics or styling.

I am prepared to develop proposed changes to requirements / information pertaining to “conforming alternatives” but IMO this would be wasted effort unless the definition of “functionality” is first clarified.

Accordingly, I suggest the following change to the formal definition given here:

Current text:

"processes and outcomes achievable through user action"

Proposed text:

"processes and outcomes defined by the content, and achievable through user action”

[GreggVan]

@DuffJohnson
that would not be the definition of "functionality" that would be the definition of the "functionality defined by the content" or "functionality of the content".

But the word functionality by itself is not restricted to content -- except by its use in a sentence in the guidelines. And the functionality is a function of not only the content but the underlying platforms (browsers and OS) without which nothing functions.

Not sure what your intent is here. What misunderstanding are you trying to prevent?