Programmatically Linking Conformance Statements

Hi All,

TL;DR:
Today, Bruce asked about the "Programmatic linking" part of the Assertions
part of the proposal. I noted on the call that currently, ePub has a
mechanism **similar** to what I am suggesting, which can be found here:
https://www.w3.org/TR/epub-a11y-11/#sec-conf-reporting

There ARE a few differences in the proposed mechanics of "How To Do" this,
but the overarching idea of having a machine readable (machine
"discoverable"?) Conformance Statement remains.

And of course, while ePub still uses XHTML, we'll need a proper "HTML"
solution (and perhaps other markup langagues as well... thinking ahead to
XR, and other emergent web-tech). So I caution everyone not to get too
caught up on the specific mechanisms right now, and instead focus on the
larger outcome and goal: do we need or want a programmatically linked
conformance statement as part of WCAG 3?

************************
Deep Dive:
In ePub documents, the structure is somewhat unique in that it is a fixed
collection of essentially static XHTML documents that are then packaged
into a single file (in fact, it's easy to do: gather all of your XHTML
documents+, add them to a ".zip" file, and then change the file
extension from .zip to .epub. Easy Peasy!)

However included in that zip/ePub file is another document (in ePub it's
known as the OPF file) which is essentially a 'manifest' file in
applicability. ePub uses the OPF file to then make certain accessibility
statements, and reports those outcomes using metadata constructs found at
Schema.org (for example, here: https://schema.org/accessibilitySummary).

ePub's mechanism envisions <meta> statements in the OPF file
(e.g. *<meta property="dcterms:conformsTo"
id="conf">EPUB-A11Y-11_WCAG-21-AA</meta>*), however, as the Schema.org
pages show, these values can also be expressed using other forms of
notation (JSON for example) because at the end of the day, they are all
just key-pairs.

I had suggested EARL <https://www.w3.org/TR/EARL10-Schema/>as a reporting
language, but I think that is also secondary to the larger discussion: the
format for reporting is less crucial than what is actually being reported.
Additionally, for mainstream "web" content, I think that a <meta>
declaration in the <head> of the document would minimally suffice:

*<head>*
*  <title> The XYZ Widget Company - Home</title>*
*  <link rel="WCAG 3" href="http://xyzwidget.com/conformance.html
<http://xyzwidget.com/conformance.html>"> *
*</head>*


However, if the larger idea is accepted, we'll need to do a deeper dive
into the specific linkage mechanics, to be sure we have the best mechanism
available - and using the above suggested method would NOT constrain the
content author from providing other linkage mechanisms (on-screen
hyper-link for example) - only that one such mechanism (link rel or other)
would be the 'normative' or 'required' way of achieving the goal: a
mechanism that enables Digital Content to express Accessibility practices
in a standard format (in both machine- and human-readable formats), that
can be retrieved automatically and interpreted easily by user agents. It's
been done before, and I think we can do it again to our benefit!

Thanks!

JF

Received on Friday, 17 June 2022 17:50:58 UTC