Open brittnylapierre opened 1 week ago
Hi, @brittnylapierre - Thanks for creating the new issue. This is useful for documenting some of the use cases that we should be thinking about for Presi 4 and accessibility. It might be helpful if you could begin the use case with a bit more about what you are trying to achieve and why, more of the problem you are trying to solve rather that the proposed solution. For example, is this to assist screen readers? How is this meant to enhance accessibility?
Thank you! I will edit it - but for a short answer it is for screen reader accessibility, yes :)
Questions:
Desired outcome of having this data in a manifest
Enable IIIF viewer developers to provide a universal experience of exploring IIIF content, regardless of a user's mode of access. (Ideally, having content rendered as hierarchical, accessible HTML with text-based data.)
All of this background info results in people using screen readers having to download a tagged PDF to access the content in manifests for library and archive print materials, instead of being able to use the content from object pages on access websites directly in IIIF viewers, like other users.
What is the ideal way for IIIF to support very detailed, hierarchical, screen reader friendly representations of IIIF images within manifests?
What functionality does tagged PDFs give with a screen reader?
About screen readers:
Through IIIF, some adopters currently use ranges for table of contents ability, and annotations created from OCR and AI solutions for displaying content of their IIIF images in screen readable text.
Some adopters also use the rendering field to provide alternative representations of their content, for example, tagged PDFs. Tagged PDFs are very labor intensive to produce, and still not as ideal as HTML for screen reader technology.
With all of their faults, tagged PDFs, similar to current annotation based OCR-correction workflows, offer digitization librarians GUI based technologies to do their tagging and text correction, and that is why they are commonly used.
Tagged PDFs are also used for accessible representations, because in theory, they provide the following:
An interesting thing to note is that tags in PDFs do not alter the visual appearance but augment a structure in PDFs to make them more compatible with assistive technologies.
Essentially, tagged PDFs are PDFs which are marked up with HTML-like tags for screen reader compatibility.
More on tagged PDFs. More on HTML vs Tagged PDFs
To read more about how AI is being used to create document structures in scanned images and PDFs, see: Azure Doc Layout Intelligence Most AI services are similar to this.
What would happen if there are two table of contents one for chapters and one for accessibility?
For this question, I think we would need a way for tools developers to know which one was which, to handle them differently in their GUI. I think someone during the meeting we had discussed the possibility of adding the 'provides' property to ranges in V4, since the accessibilityFeatures property on schema.org supports both table of contents and structured navigation.
Other thoughts/considerations A non-native IIIF solution would be to recommend people to use HTML files in the rendering field to support accessibility, and tools developers to ensure that they display this HTML in the browser for end-users, but this does not support our communities current OCR correction workflows, or the idea that they can use the content search api, and is not a IIIF-native solution.
Some things IIIF API creators could consider when thinking about how to support the functionality tagged PDFs provide to end users, natively in IIIF are…
Other pain-points for current range and annotation based solutions include the following:
More IIIF Considerations I can think of/were discussed when we met:
Related cookbooks
Thank you! I hope this helps provide more background and context (and not too much all at once!) If the spec writers want to have a Q/A with people who are deep into the accessibility space for print materials let me know and I can also arrange one to support these efforts.
Edit: This issue was moved from the Cookbook Recipes repo. We are looking for technical specifications writers to help us determine the best solution in the IIIF context for detailed structural navigation. See the big comment I added for detailed context: https://github.com/IIIF/api/issues/2320#issuecomment-2457744843
Recipe Name
Structural navigation using Ranges: 2 Ways
Use case
You can enhance your manifest by adding Ranges that reference specific parts of canvases. By using the label field to describe these references with text, you can create structured navigation similar to a tagged PDF. Learn more about structural navigation here.
Way 1: Attaching Annotations to a Range via a supplementary AnnotationCollection Example manifest: https://upcdn.io/kW15cD4/raw/html-annots-3-anns-in-range1.json
Pros
Cons
Example of what the viewers should support - displaying annotations with the range titles:
Way 2: Using ranges with label fields, referencing positional canvas URLs Example manifest: https://upcdn.io/kW15cD4/raw/partial-ranges-nav.json Pros
Cons
Theseus screenshot: