Conforming alternate version - what this means for non-web documents and software

[maryjom]

On the text-based applications sub-group call quite some time ago we discussed a change to the section on text-based applications in Pull request 172. The subgroup thought the concept of what may or may not be acceptable as a "conforming alternate version" might be a more general topic for WCAG2ICT to cover. WCAG covers it in the sense of a full Web page being a conforming alternate version of a non-conformant page. For non-web documents and software, this would equate to a non-web document being a conforming alternate of another, or a non-web software application being a conforming alternate of another.

The 2013 WCAG2ICT document included the WCAG definition of conforming alternate version, but the guidance did not make word substitutions or notes. This was because WCAG2ICT didn't provide direct interpretation of the conformance requirements where that term is used. Here's what the WCAG2ICT guidance on "conforming alternate version" says:

Applying “conforming alternate version” to Non-Web Documents and Software

The guidance in this document does not use the term “conforming alternate version”.

See the section Comments on Conformance.

Thinking about "conforming alternate version" in the context of non-web ICT raises many questions. Some questions are posed in Issue #196, including:

• Can one non-web application act as a conforming alternate version of another non-web application, on the same or different operating system?
• Can a non-web application act as a conforming alternate version of a web application or vice versa?

We might also want to answer:

• Can one non-web document act as a conforming alternate version of another non-web document, of the same document format or a different document format?
• Can a non-web document act as a conforming alternate version of web pages, or vice versa?

First, we need to decide whether or it is within the scope of WCAG2ICT to answer these questions, and if so, what that content or guidance might be (e.g. It might take the form of word substitution and notes for the definition of "conforming alternate version".)

Here's WCAG's definition of a "conforming alternate version" to help with this discussion:

conforming alternate version

version that

1. conforms at the designated level, and

2. provides all of the same information and functionality in the same human language, and

3. is as up to date as the non-conforming content, and

4. for which at least one of the following is true:

   1. the conforming version can be reached from the non-conforming page via an accessibility-supported mechanism, or
   2. the non-conforming version can only be reached from the conforming version, or
   3. the non-conforming version can only be reached from a conforming page that also provides a mechanism to reach the conforming version

NOTE 1: In this definition, "can only be reached" means that there is some mechanism, such as a conditional redirect, that prevents a user from "reaching" (loading) the non-conforming page unless the user had just come from the conforming version.

NOTE 2: The alternate version does not need to be matched page for page with the original (e.g., the conforming alternate version may consist of multiple pages).

NOTE 3: If multiple language versions are available, then conforming alternate versions are required for each language offered.

NOTE 4: Alternate versions may be provided to accommodate different technology environments or user groups. Each version should be as conformant as possible. One version would need to be fully conformant in order to meet conformance requirement 1.

NOTE 5: The conforming alternative version does not need to reside within the scope of conformance, or even on the same Web site, as long as it is as freely available as the non-conforming version.

NOTE 6: Alternate versions should not be confused with supplementary content, which support the original page and enhance comprehension.

NOTE 7: Setting user preferences within the content to produce a conforming version is an acceptable mechanism for reaching another version as long as the method used to set the preferences is accessibility supported.

See Understanding Conforming Alternate Versions

[mapluke]

I share @mraccess77's views expressed in his comment on Issue#196 that because we are not mapping separate parts of a non-web software application to pages, but mapping entire applications to a web page, the ideas behind providing an alternate versions of a web page don't really map either. Even the mapping of individual documents in a set to web pages also makes the concept of alternative versions a little difficult to interpret.

For these reasons, in EN 301 549 no attempt to have an equivalent to the WCAG Conformance Requirements was made for either non-web software nor for non-web documents. So the problem of interpreting alternate versions for non-web software and documents has not arisen and there was no concern about WCAG2ICT's lack of a suitable mapping.

A proposal that there ought to be equivalent conformance requirements for non-web software and documents has been raised during our current revision process, but I suspect that we might reach the same conclusion as last time for the same reason unless WCAG2ICT comes up with a convincing and bullet-proof mapping that could be used in software and document conformance requirements.

[bruce-usab]

As Mary Jo notes at top of this issues, 2013 just notes that it does not use the term. That seems elegant to me.

We might note that it is possible for a web page to be considered as the conforming alternative version of a non-conforming non-web document – but in those cases, the non-web document should conform to WCAG2ICT to the extent possible.

[maryjom]

IMO "conforming alternate version" doesn't make sense for non-web software as currently defined. There are multiple ways to make inaccessible software content accessible through the use of mechanisms such as:

• a mode of operation using accessibility settings or an accessibility mode,
• alternate views of content available inline, by using a link or through some mechanism that shows an alternate accessible view (e.g data tables or a summary of insights vs. an inaccessible visualization of the data)
• providing a CLI or API that provides the same functionality as the GUI application (as is typically employed by network management software, etc.)

On a larger scale, this topic also brings into question whether an accessible mobile app or an app on a particular OS platform can be considered a conforming alternate version for other platforms where the app is inaccessible. Or can a web-based application be a conforming alternate version of an inaccessible non-web software application? This is somewhat similar to how websites previously would be tuned to being more accessible in Firefox or Chrome vs. some other browser when accessibility and ARIA support was so different between the various browsers.

Then for documents, as @bruce-usab notes, an accessible document in a particular format (either a web page or some other format) could be an accessible alternate if it contains the same content, but in an accessible form.

The question that remains is whether WCAG2ICT should address these possibilities (whether in the Comments on Conformance section, using notes on the "conforming alternate version", or in both places); or should we leave it to other standards or regulatory spaces to define what can or cannot considered a conforming alternate version?

[pday1]

See latest update in #196 (comment)

[bruce-usab]

Law makers are in desperate need for guidance with applying WCAG to software, including closed systems. If that guidance is not explicitly included in WCAG2ICT, there is evidence that regulators will not do the analysis themselves.

[maryjom]

This is a very complex topic with many use cases and potential caveats for an accessible alternative.

For software applications, can the former item be an accessible alternative for the latter item? Consider the following combinations:

• inaccessible mobile application developed on one platform vs. an accessible mobile application on another platform (e.g. iOS is accessible, Android is not)
• inaccessible native desktop application developed on one platform vs. an accessible native desktop on another platform (e.g. Windows vs. MacOS)
• inaccessible Web application vs. an accessible native desktop software application
• inaccessible Web application vs. an accessible native mobile application
• inaccessible GUI application in any platform vs. an accessible Text-based application (e.g. CLI)
• inaccessible mobile application and an accessible native application

For non-web documents:

• an inaccessible document a particular document format vs. one that has the same content in a different document format that is accessible (e.g. PDF and Microsoft Word)
• an inaccessible document in a particular format vs. an accessible Web-based format (e.g. anything vs. HTML)
• a visually oriented document format vs. a text-based format (e.g. a diagram vs. a text description/text based document)

Others can add to this, if they wish.

[maryjom]

Copying in WCAG's definition of an accessible alternative to discuss concerns with particular parts of the normative language. There are a number of notes (not copied here) that seem to broaden what would be able to meet this definition and seem to be going into the realm of redefining the normative language without changing the normative definition for backward compatibility. It seems that WCAG 3 should be at liberty to make adjustments to the language of this definition to handle the wider scope of how one could provide conforming alternate versions.

WCAG's definition:

conforming alternate version
version that

1. conforms at the designated level, and

2. provides all of the same information and functionality in the same human language, and

3. is as up to date as the non-conforming content, and

4. for which at least one of the following is true:

   1. the conforming version can be reached from the non-conforming page via an accessibility-supported mechanism, or
   2. the non-conforming version can only be reached from the conforming version, or
   3. the non-conforming version can only be reached from a conforming page that also provides a mechanism to reach the conforming version

Concern with Item 2:

In the near future, AI or other pluggable services (that may not even be part of the ICT) to deliver alternative content or alternative UIs. These could intentionally be served up in a different language (e.g. sign language). So it seems that Item 2 boxes this into a specific way of providing conforming alternatives.

Concern with Item 4:

Regarding list item number 4 above (and its sub-bullets), requiring one of the 3 options is not open-ended enough for non-web documents and software. The conforming version may be well-documented in a separate place as to which is the conforming version, how to use preferences to set up an "accessibility mode" or access alternative views of pieces of inaccessible content. When there is an inaccessible non-web document, it may not have a direct linkage to an accessible non-web document but may easily be made available through some other mechanism. It may not be known where an alternative document will reside to have a working linkage automatically be provided. Consider installable software with documentation provided. The user can choose where to install the documentation. Archived content may have accessible alternatives made available upon request or made available through some mechanism or process established by an organization. These should also be considered conforming alternate versions.

Missing coverage:

As @nitedog (Shadi) noted in the meeting today (28 Mar.), there may be alternatives specifically tuned for certain disability types that would access the non-web software functionality via another means altogether (example given was an Alexa device that typically one speaks commands to and auditory information is returned or some command is executed that has an alternate interface accessible through a web or a mobile application to provide the same capabilities but in a form that is accessible to people who are deaf, hard of hearing, or who cannot vocalize with enough precision that voice commands are properly recognized. These alternate methods of user input are not linked to by one another, and it would make no sense to do so. Proper documentation of features and how to use them would address this well enough.

The notion of each piece of the software being "fully conformant" to WCAG might not even be possible, but the whole of the system with its various software applications combined could make the product fully accessible.

A website or web application is basically a big document (or set of documents) of content with functionality that has easy built-in capabilities to provide links. Such links are not necessarily possible when using different layers or services to provide the same functionality but in a form tuned to address specific functional performance criteria (without sight, without hearing, etc.).

This is why I still believe that WAG2ICT should NOT include guidance of this nature. I believe it is outside of the scope of our TF's brief to determine what is and isn't a conforming alternate version. If we decide to add some notes on this topic, they should be with notes that talk about concerns with applying this term in a non-web context.

[cwadamsoforacle]

The questions raised in issue 196 require answers that appear to require WCAG2ICT TF to go beyond its remit. Our scope is to create a note that describes how specific WCAG SC can be applied to non-web technology, and the questions require answers that will move us to discuss the overall conformance model of WCAG and how that model can be applied to non-web technology. My concern is that AGWG will feel this is beyond our scope of crafting specific guidance for WCAG Success Criteria.

[maryjom]

@cwadamsoforacle The overall objective from the work statement says:

The objective of the WCAG2ICT Task Force is to develop documentation describing how WCAG 2.x and its principles, guidelines, and success criteria could apply to non-Web Information and Communications Technologies (ICT).

I consider our overall scope of work to be a little more broad than just WCAG SC. We technically don't say anything in the bulleted scope of work about providing guidance on WCAG definitions (which we have been working on) and this is a definition in WCAG (though not used in an SC). However, I agree that this discussion is wandering into areas that are "explicitly out of scope" in our work statement's scope of work. We cannot provide normative changes that would address the concerns with the definition in my previous comment nor can we state what would or wouldn't potentially meet the definition of a conforming alternate version.

My suggestion is that development of an alternate definition, with examples of what would/wouldn't meet the definition of a "conforming alternate version" should be taken up in a different forum. Either a standards group that has a focus on requirements for non-web ICT (like ETSI). Or a W3C community group could be started to work on out-of-scope items such as this to make a proposal to submit to those developing non-web ICT standards. An industry association, such as ITI, could develop a position paper regarding the need for this guidance and could provide suggestions for policy makers.

I am working on a potential way for WCAG2ICT to simply point out the limitations and difficulties with this definition if it was to be applied to non-web documents and software as it is today that would avoid going outside of our scope of work.

[maryjom]

After the discussion in the 18 April meeting, the TF decided to leave the current text regarding Applying "conforming alternate version" to non-web documents and software as-is, as doing any sort of interpretation would lead to us going beyond the WCAG2ICT TF scope. It is too complex a topic to handle with simple word substitutions. Current text in the editor's draft:

The guidance in this document does not use the term “conforming alternate version”.

See the section Comments on Conformance.

Since no document changes will be done, closing this discussion.