Meeting20260825

Accessible Synchronized Multimedia for Publishing Community Group Meeting

Date: 2026-08-25

Location: Zoom

Agenda

• Recurring meeting has been scheduled
• Use case review: what we have so far
• Collecting samples

Minutes

Participants

• Avneesh Singh
• Christian Egli
• Daniel Weck
• Gautier Chomel
• George Kerscher
• Hadrien Gardeur
• Johanna Partanen
• Jonas Lillqvist
• Marisa DeMeglio (chair)
• Oscar L. Carlsson
• Stacy Branham

Summary

Recurring meeting time

The team noted a new recurring meeting schedule every other Tuesday at 1400 UTC

Use case review

This meeting focused on reviewing use cases currently tracked in their GitHub repository. The team identified the need to break down complex use cases into more atomic requirements.

Use case: Read-aloud highlighting must not move the text it is highlighting

The first use case, from Minori Ikeda, involves text layout issues during synchronized playback, particularly with Japanese vertical writing where highlights can cause text to shift, making it difficult to read.

Use case: The phrase being read aloud must be on a page the reader can see

This one is also from Minori Ikeda. It says that media overlays doesn't necessarily specify that the text has to be in view, like in the sense of the reading system has to be on the right page when it's reading. This should be explicitly stated.

Use case: Blind student must use audio and their screen reader with TTS and braille

This use case is from George Kerscher.

George shared a detailed use case about synchronizing screen reader experiences with pre-recorded audio, particularly for textbook content with braille displays. The group discussed technical challenges around screen reader synchronization, particularly noting platform differences between Mac and Windows, and the limitations of current APIs for reading systems to achieve precise text element targeting.

The group discussed challenges with screen reader compatibility for e-book readers, particularly focusing on how different screen readers like NVDA, JAWS, and VoiceOver handle focus events and navigation in HTML documents. Daniel explained Thorium's approach of using focus and blur events to guide screen readers to specific locations in web-based documents, noting that bookmark functionality sometimes doesn't accurately return to the saved location. George mentioned a new NVDA feature called native mode selection that attempts to sync the DOM with visual display, though he noted it's still improving and doesn't always accurately return to bookmarked locations. The discussion concluded with Daniel suggesting the possibility of exploring alternative mechanisms beyond element IDs for referencing text fragments, including Character Fragment Identifiers (CFI) or other methods to improve screen reader navigation.

The group discussed text selection and styling challenges, with Daniel explaining that selecting arbitrary character ranges is less easily stylable than selecting whole elements. Marisa highlighted a relevant text highlight API from Minori Ikeda's use case and noted parallels with EPUB's locator specificity discussions.

Use case: Life-critical public information for residents with disabilities in a nuclear emergency planning zone

Marisa introduced a new use case from Hiroshi Kawamura regarding life-critical public information for residents with disabilities in nuclear emergency planning zones. The situation described is a resident receives an instruction that a protective action is required. Some emergency has happened, and they need to do something to stay safe, and they need to determine within minutes which action applies to them in their circumstance at their location. And then they need to act, perhaps together with neighbors who don't know their language. A successful story is that the resident perceives that something has been issued. They understand its content in their own first language. They see that it applies to them. They can confirm with somebody nearby and they can take the correct action. Warning response literature describes this as hearing, understanding, believing, personalizing, deciding, and acting is the sequence that has to happen. And if any of those steps fail, then all the subsequent steps fail.

There are also requirements around connectivity. So the connection may be weak or it may have failed already in a disaster, so the content needs to work offline. And it has to fit on the consumer device, perhaps with some graceful degradation in quality. The document must remain readable decades after production. It could be a variety of settings, a public kiosk. Or being mobile, maybe you're not at home when the disaster happens, so you're in transit and you're on your device, and your connectivity might be unreliable.

In all these situations, you need to be able to access the content in the right language, in the right modality, uusing whatever mode of interaction you have available to you at the time, which could be different in the situation.

Breaking down complex use cases

The team discussed breaking down a comprehensive use case into more specific, manageable scenarios in order to better be able to extract requirements. They discussed modifying the existing use case template and agreed it could be slightly improved by removing complex W3C WCAG sections and making more fields optional to simplify the process.

For issue #5, Stacy volunteered to create a master list of potential use cases and permutations before others begin creating specific scenarios.

For issue #4, George said he could create a few smaller use cases.

Samples

The team established a process for contributing samples to the repository's new Samples folder, with participants able to fork the repository and submit pull requests with their content examples. Also, participants may instead email the files to Marisa.

Action items

• Christian
  • Consider contributing a use case that explicitly states the desire to retain all current media overlay features.
• Daniel
  • Contribute use cases specifically in the field of sign language, signing videos, and synchronization with text/audio.
• George
  • Break up his submitted use case into at least two separate use cases: one for read aloud functionality and one for media overlays.
• Marisa
  • Update the use case template to make more fields optional, remove the WCAG section, and possibly collapse some fields.
• Oscar
  • Attempt to upload sample media overlay files to the repository via a pull request, or send them to Marisa if that fails.
• Stacy
  • Create a shorthand master list of all the use cases and permutations from Hiroshi's big use case.
  • Brainstorm and contribute use cases around collaborative reading scenarios and early literacy skills for blind children.
• All participants:
  • Contribute any example content (media overlays, SMIL, experimental) to the "Samples" folder in the repository via pull request or by sending to Marisa.