Add accessibility note

[dhh1128]

This addresses the feedback in issue #225 . There is only one reference to images in the spec, so I placed the text there despite the somewhat awkward flow.

---

Preview | Diff

[gkellogg]

I read the issue differently. Common feedback for specifications is to make sure that images used within the spec have a description. Note how we handled this in json-ld11.

https://github.com/w3c/json-ld-syntax/blob/f3edaa5b2db307bf3aff765af604cf4d89c6a748/index.html#L4947-L4964

<figure id="fig-linked-data-graph" style="text-align:center">
    <!-- Source for this file is at https://docs.google.com/drawings/d/1_bRm1d9hTTqAqv5q8KEBzI47HxAUrbceA0EE5APh8hA/edit?usp=sharing -->
    <object data="linked-data-graph.svg" style="width: 75%" type="image/svg+xml" aria-describedby="fig-linked-data-graph-alt">
      <p id="fig-linked-data-graph-alt">The image depicts a linked data dataset with a default graph
        and two named graphs.</p>
    </object>
    <figcaption>An illustration of a linked data dataset.<br/>
      A <a href="#fig-linked-data-graph-descr">description of the linked data dataset
      diagram</a> is available in the Appendix. Image available in
      <a href="linked-data-graph.svg" title="SVG image of a linked data dataset">
        <abbr title="Scalable Vector Graphics">SVG</abbr>
      </a> and
      <a title="PNG image of a linked data dataset" href="linked-data-graph.png">
        <abbr title="Portable Network Graphics">PNG</abbr>
      </a>
      formats.</figcaption>
  </figure>

Note that there is also a reference to an appendix with more detailed descriptions.

This is what I understand Janina to be requesting.

[msporny]

While it doesn't address the original spec a11y issue, there is text in here that we want to pull into the spec.

[msporny]

Agree with @gkellogg, this isn't what Janina and the Accessibility folks were requesting (they wanted descriptions of the images used in the W3C VC specification), so suggest that we strike it (but keep the rest of the PR).

[msporny]

@dhh1128 is raising a good concern related to expressing VCs that contain images to people with Accessibility needs. I'm not certain we have enough experience to say much at this point other than something to this effect: "If you use images, you're making future Accessibility concerns more difficult... stick to just expressing pure data in VCs so that systems can choose how to render the VC appropriately (e.g. audio, braille, high contrast graphics, vibrations, etc.)."

[msporny]

We should keep this change and the one below...

[msporny]

This is now in the spec.

[TzviyaSiegman]

I totally dropped the ball on this. I was supposed to write an accessibility note, which is more far-reaching than including image descriptions. I will get to this before the end of September.

[ChristopherA]

Not a request to change this PR, but I thought this advance topic paper from the upcoming #RebootingWebOfTrust on “Verifiable Displays” https://github.com/WebOfTrustInfo/rwot7/blob/master/topics-and-advance-readings/verifiable_displays.md may be relevant for future discussions.

“This emphasis on machine verification is essential, but what's not in scope of the VC Data Model is scenarios where a human participates in verification. In the Educational/Occupational space, suppose a recipient has received an academic credential that they want to share with a potential employer. The potential employer can cryptographically verify the content, but the employer is typically not looking at the raw json content of the credential; instead they are looking at an image, PDF, or some friendlier visual representation.

The question arises: how does the employer know that the friendly display they see is what the issuer intended? In general, how do they know the display matches the content? This is currently addressed in a variety of (sometimes incomplete) ways.

This paper surveys existing solutions to the problem, and develops a set of requirements based on lessons learned. This proposes a general solution based on the authors' experiences developing Blockcerts and Validbook.”

[stonematt]

also related to PR #238 and PR #246

[msporny]

All of the bits that we wanted to save in @dhh1128's PR are now in the spec via #246 and other PRs. Closing this one.