-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Display accessibility metadata and use it as a filter #1332
Comments
Just to clarify this statement: EPUB3 Media Overlays (including ones generated / converted from DAISY full text/audio, or audio-only) are not yet identified as such in the library window / bookshelf. Thorium displays their duration / narrator (authored metadata) in the "about" modal dialog box, but these publications are not considered "audio books" per se. |
From what I have read, the W3C a11y document does not consider publications with media overlays as audiobooks neither. |
Well... https://w3c.github.io/publ-a11y/UX-Guide-Metadata/principles/#audiobook
...arguably, the intended purpose of the statement "(text) is not required to use the (audio) publication" is to open the interpretation of audio + text captions / transcript (Thorium does in fact have a "captions" view for Media Overlays playback). Now, the "audio book" / "audio-only publications" distinction is indeed useful to the end user (different UX expectations). What sets a EPUB3 Media Overlays apart (inc. DAISY talking books) is that they usually include recorded human narration, as opposed to the "read aloud" TTS experience which relies on reading-system synthetic voices (i.e. not authored, therefore not declared / advertised in publication metadata). The Additional resources: |
The trigger for the "Audiobook" property is detailed in the a11ty techniques: https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/epub-metadata.html#audiobook. I don't think the EPUB3 with Media Overlays will get the meta "accessModeSufficient:auditory"; but this is something which should be made clear. Let's bring your comment to the attention of the EPUB3 WG a11Y task force. I'll do it. And in fact, because the Audiobook property is a direct mapping on EPUB3 metadata, I agree we should display it when the conditions are met. |
Indeed:
...can in fact be included in a EPUB3 Media Overlays, but most publishers / content creators will probably just include:
|
Also note: w3c/publ-a11y#28 |
Not sure at all: "textual, auditory" means both textual AND auditory abilities are necessary to access the data (in the Audiobook section). |
I'm not sure either. The spec. says:
|
Links to Laurent's mailing list messages: |
In my opinion, in a fulltext/fullaudio book with human narration using media overlays we should use these 3 entries in the metadata: meta property="schema:accessModeSufficient">textual</meta .... at least this is how I interpret |
Hello Manfred, I would have thought that the default |
well I am by no means an expert but would be happy to know how before we start distributing these books ;-) from this Example: I thought that if the full text is there, that"textual" needs to stand as a separate entry. |
I asked Madeleine Rothberg to weigh in here as she is the leading expert regarding accessibility metadata. |
This is confusing, and most people have some part of this correct, but not all of it. I hope this is helpful. Let me know if I should address other use cases here. Full text, full audio book:
In addition, it could have the following line as well, which would indicate that a user could listen to the audio and look at the text simultaneously: Unless there are significant images in the book, there is no need to reference visual access modes. It is not relevant whether the user uses their eyes to look at the text, uses a screen reader to convert it to audio at the time of reading, or prints it on a braille printer and reads it that way. The resource itself is textual. |
@madeleinerothberg thanks for the information. This implies that EPUB with media overlays will get the mention A confusing indication is that "W3C Audiobook" is a standard based on another format than EPUB. But the culprit is certainly the generic name given to a specific format. In such a case (EPUB with media overlays), shouldn't Note that I see all these metadata values stacked in https://w3c.github.io/publ-a11y/UX-Guide-Metadata/techniques/epub-metadata.html#example-9.1-all-metadata-fields-present. |
We were only discussing |
Note: in the Display Techniques for EPUB a11y metadata, "Audiobook: yes" has been replaced by "Full Audio: yes". |
Related (webpub-manifest JSON): readium/webpub-manifest#85 |
Parser bug: readium/r2-shared-js#37 |
This comment was marked as outdated.
This comment was marked as outdated.
This is a great start. My first comments: We should make so that the UI model of this modal window is not totally modified by the addition of accessibility metadata.
|
Regarding filters, the table handles filters via hyperlinks, each column can support one filter only. The new filters must follow this model. The previous proposal does not allow that. We could treat "Accessibility Information available" (this label is too long) as a new column, as it is simply a boolean. "True" may be display as an image (the Vitruve man?) or a text (which should be short). For filters corresponding to reading modes (Display transformability; Fixed-layout; TTS & Screen reader friendly; Text & audio synchronised) we have a first question to solve: could we consider that choosing one only is enough (i.e. a user is not angry if he cannot choose Fixed-layout + TTS & Screen reader friendly. In this case, a single column would suffice. If not we have a UX issue to solve. |
This comment was marked as outdated.
This comment was marked as outdated.
Also to have in mind, this addition makes a lot of elements to localize. |
Edit after team call, relevant points listed here:
reviewed proposalThis proposal intends to simplify access to key information displaying it outside of a details box. Others information are still boxed, but redundancies are not exposed anymore. more details on how to fill information is provided below. Book detailsElements actually displayed by thorium (book details) are not mapped but kept here for reference.
AccessibilityThis is a title (h level to be determined)
If any Hazard information set to true, it should be displayed here too.
More about accessibilityThis is a If none of the information is provided, display into a To avoid redundancies the following are not implemeted:
accessibilitySummary is now at the very end of this section.
Search filtersThis part can be added later once some iterations have been done on the Book information panel. Add a column titled Accessibility in the All books view. Populate it with one of the following information if present. It should be looking like a bloc (like tag).
|
Because conformsTo URLs leads to technical specs, it is of no use for users. Here is a mapping URL to understandable text :
|
Right, but note that ConformsTo (the data model property) can be parsed from EPUB OPF XML |
thorium-reader/src/renderer/common/components/dialog/publicationInfos/publicationInfoA11y.tsx Lines 200 to 212 in 4cdd2d1
|
Add to Thorium Reader the features described in User Experience Guide for Displaying Accessibility Metadata.
The fact that a publication is an Audiobook is already clear in Thorium, therefore we won't duplicate it with an "Audiobook" property. UI details will be defined by a designer before implementation.
Note:
The text was updated successfully, but these errors were encountered: