Call for content review: Accessible IIIF Manifests

[Brittny Lapierre]

Hello everyone,

A few of us in the community are developing accessibility best practices for IIIF manifests, mainly drawing on recommendations from W3C and NISO related to EPUB documents. I have attached the current version of our working document for your review.

If you are interested in contributing to these recommendations or know of others who might be, please let me know, and I would be happy to share the working document with you.

Best regards,

Brittny Lapierre

[Lynema, Emily]

Brittany,

 

I’m very interested in this work. I am co-chairing the AV Annotations TSG that was born out of the AV community’s need to be able to declare special kinds of annotations to be properly rendered by media players, particularly captions, transcripts, and audio description. We have a proposed solution that will likely go into Presentation 4 to handle these situations. If this were to become an accepted recommendation for the IIIF community, I think we’d want to include these.

 

Are you working within the auspices of an existing community group? Is there a Slack channel where you are taking feedback?

 

-emily

 

From: iiif-d...@googlegroups.com <iiif-d...@googlegroups.com> on behalf of Brittny Lapierre <blap...@crkn.ca>
Date: Friday, September 20, 2024 at 9:08 AM
To: IIIF Discuss <iiif-d...@googlegroups.com>
Subject: [External] [IIIF-Discuss] Call for content review: Accessible IIIF Manifests

You don't often get email from blap...@crkn.ca. Learn why this is important

This message was sent from a non-IU address. Please exercise caution when clicking links or opening attachments from external sources.

 

--
-- You received this message because you are subscribed to the IIIF-Discuss Google group. To post to this group, send email to iiif-d...@googlegroups.com. To unsubscribe from this group, send email to iiif-discuss...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "IIIF Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iiif-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/iiif-discuss/769ce7e2-0a94-4e43-8bb3-2f7328ce122an%40googlegroups.com.

[Robert Sanderson]

Hi Brittny,

Sorry to rain on a very valuable goal, but this isn't a good use of the metadata field, I'm afraid. To quote the specification:

An ordered list of descriptions to be displayed to the user when they interact with the resource, given as pairs of human readable label and value entries. The content of these entries is intended for presentation only; descriptive semantics should not be inferred.

(bold added)

Putting flags into metadata about accessibility will serve only to reduce accessibility, as screen readers and other assistive technologies try to then read them out to the user.

The manifest also isn't the viewer... a strange but compliant viewer implementation would be to render everything as a single image (including the metadata and other text) and then have the user zoom and pan within it. So there would be an image of text saying that the manifest was accessible to the user ... when it absolutely would not be.

Rob

--

-- You received this message because you are subscribed to the IIIF-Discuss Google group. To post to this group, send email to iiif-d...@googlegroups.com. To unsubscribe from this group, send email to iiif-discuss...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "IIIF Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iiif-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/iiif-discuss/769ce7e2-0a94-4e43-8bb3-2f7328ce122an%40googlegroups.com.

--

Rob Sanderson

Senior Director for Digital Cultural Heritage

Yale University

[Brittny Lapierre]

Hey Emily,

I am working on organizing an Accessibility and UX IIIF community group! I'm planning a few community needs gathering sessions for October. If you'd like to be involved in please feel free to message me on Slack and I can send you the charter which is being reviewed, too.

I was posting about this topic in the a11y channel as well - it includes a link to an editable version of this document that you can contribute to if you have the time!

Thanks again,

Brittny

[Brittny Lapierre]

Hey Robert! No problem, thanks for taking the time to look at the document. Can you help me understand the difference between describing and presenting? The goal would be to show this data to end users, like how this guide indicates for the analogous metadata encoded in EPUB XML format:  User Experience Guide for Displaying Accessibility Metadata 1.0 (w3.org) Displaying this information for end-users will help them understand if the content of the resource is usable by them or not, so we would want it read out loud by screen readers. Is this still considered descriptive rather than for presentation purposes? Thanks again for your help and insight I do appreciate it!

[Robert Sanderson]

Thanks Brittny! Perhaps you can help us to understand how the information would be conveyed with some examples of what you would expect to see in the Manifest?

At the top of the document, it calls out metadata as the field to use, and then various labels, values and definitions below. I imagined something like:

    {"label": {"en": ["Screen Reader Friendly"]}, "value": {"en": ["No"]}}

following your definition:

Screen Reader Friendly
Value: Textual, Yes / No / Unknown
Definition: Indicates if the publication is readable by screen readers (true text format).
Rationale: Ensures access for screen reader users, avoiding image-only content.

Which then made me think that it was intended for machines to process, not to display to humans, as calling yourself out for not being screen reader friendly seems unlikely to be useful to anyone (and "Unknown" especially so). If it's for humans, then constraining the value to only three options seems unnecessary?

Equally, screen reader friendliness and much of web accessibility generally is from the application layer, not the the manifest. You could display the above field in some very clever application that does make it screen reader friendly through automatic transcription, translation, summarization and description of images for example.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/iiif-discuss/bcedec1a-19af-4fa3-bde6-821d97a581f0n%40googlegroups.com.

[Brittny Lapierre]

Thanks again Robert I really appreciate this help!

Hmm thinking more critically about displaying this information, and providing specifications for implementors, I am starting to think that it may be more helpful to ask for the most useful of these fields to be considered new descriptive fields in the presentation API v4. That way, like with other descriptive fields, we could suggest how clients should render them.

Out of the fields I took from the EPUB guidelines, I think the accessibility summary could provide a good, end-user readable version of all the details from the other more specific fields. Then, in the API spec, we could say: Clients must render the accessibility summary of a resource if it exists.

Then cookbooks on how to make good accessibility summaries, noting accessibility features, access modes, hazards, etc. could be made. this would give the community examples of what useful accessibility summaries look like. This is the EPUB docs on writing accessibility summaries that we could lean on: Accessibility Summary Authoring Guidelines for EPUB Publications (w3.org)

With that in mind, we could ask clients to render accessibility summaries under summaries for manifests, for example:

Manifest summary

Les cloches de Saint-Boniface : Vol. XXII, No 7 (juillet 1923)

"Les cloches de Saint-Boniface" is a historical periodical published in July 1923 by West Canada Publishing Co. in Saint-Boniface, Manitoba. This volume, designated as Vol. XXII, No. 7, features a collection of 32 images that provide a visual insight into the cultural heritage of the region. The publication is primarily in French and serves as a valuable resource for researchers and enthusiasts interested in the history of Saint-Boniface and its community.

---

Accessibility SummaryThis publication strives to meet accepted Web Content Accessibility Guidelines (WCAG) at the AA level. Subject experts were used to create the ALT text. A comprehensive index is included with links to the top of the page. Page numbers are present and navigation to pages is supported. This publication contains a comprehensive multi-level table of contents for navigation through the various chapters and sections.

This seems like a logical and balanced approach to me, can you think of any possible issues with this approach?

Thanks again,

Brittny

[Brittny Lapierre]

I thought of another likely good candidate yesterday - maybe we could also suggest Accessibility features as a property, and as clients to use this to render the features if they exist. For example, (these need to be refined:)

• Clients (should or must) render a textual alternative representation if the ''alternative text" value is present
• Clients (should of must) render annotations if the "annotations" value is present
• Clients (should or must) render structural navigation if the "structural navigation" value is present
• Etc. 

(You can see the values of accessibility features for EPUB here, which we could use or adjust for the IIIF context: Schema.org Accessibility Properties for Discoverability Vocabulary (w3.org))

[Glen Robson]

Hi Brittny,

Emily mentioned the work of the Av Annotations TSG and some of the suggestions below are getting close to what is being discussed in the provides property:

https://github.com/IIIF/api/issues/2308

We haven’t looked at what the spec will say about requiring behaviour from clients but the provides property is intended to let the client know for example that a VTT subtitle file ‘provides' captions for a video. 

Thanks

Glen Robson
IIIF Technical Coordinator
International Image Interoperability Framework (IIIF) Consortium
http://iiif.io

To view this discussion on the web visit https://groups.google.com/d/msgid/iiif-discuss/d25308be-e912-459b-87e0-93a491ed2c52n%40googlegroups.com.

[Brittny Lapierre]

Thank you Glen! This is perfect, I am continuing the conversation on this in the GitHub issue.