[Grouping Accessibility Metadata] merging "Reading Mode: Audio" and "Reading Mode: Non visual"?

[gregoriopellegrino]

This issue is part of the wider work presented in the issue #144 Proposal for Grouping Accessibility Metadata into Categories.

Working on a system for grouping accessibility metadata into distinct categories the editors had this question that we repost in this issue so that it can be discussed by the community.

The question is about the proposed group "Reading Mode: Audio": perhaps we can merge "Reading Mode: Audio" with "Reading Mode: Non visual", or at least bring it back as a sub-category. What's your opinion?

[clapierre]

I agree to combine these into one category.

Let's say we have the category of "Non Visual" then an accessMode of "audio" would go here, also "tactile" as well. But an accessMode of "visual" would be put somewhere else right like under Visual Adjustments"?

So the different accessMode's could show up in multiple categories.

[ManfredMuchenberger]

Will there also be a "Reading mode: visual" if there is a "Reading mode: Non-visual"? Or is the "reading mode: visual" not necessary because it is self-evident?

I don't see this in the spreadsheet https://docs.google.com/spreadsheets/d/1rUCXkVE0bFeXf0hJvyPkKkIBeBHIGPYUFWKrQqLJHl8/edit#gid=0

[avneeshsingh]

Right now we have Reading mode: non-visual and visual adjustments. As @ManfredMuchenberger said, reading mode: visual is self explanatory. From accessibility purpose what is important for us is visual adjustments.

[avneeshsingh]

the issue was discussed in February 9, 2023 call. The relevant part of the minutes of meeting follow. We have action to find a better name for non-visual reading. gpellegrino: "Reading Mode: Audio" and "Reading Mode: Non visual" should we merge them.

AvneeshSingh: Synthetic speech vs. human narrated audio

JF: I would argue against merging them, what about Braille Output. … , tactile reading mode.

gpellegrino: non-visual reading mode jumping from 1 heading to another, the audio is more beginning to end,

AvneeshSingh: maybe its the name that is a problem.

Madeleine: Non-Visual seems like not a lot of users would understand. Audio everyone would understand. we need to make book providers are already making those types of books easier to find.

JF: +1 to Gregorio

gpellegrino: audio may also mean media overlays in EPUB,

JF: could we call it "Reading mode - Pre Recorded"? … , non-tech people know what we are talking about.

AvneeshSingh: Media Overlays?

JF: well those overlays would be pre-recorded right?

gpellegrino: Yes, but could be done with deep learning voices apple / google is pre-recorded is right word. what about a different word for non-visual.

wendyreid: challenges here straying into reading systems. non visual reading via reading system with TTS. … , if a RS has these features could have a audio based reading modality when a reading system offers this even if the EPUB itself didn't provide this. … , auto-generated from AI audio books.

AvneeshSingh: non-visual needs to be replaced then we can decide what fits. … , lets discuss this online in GitHub / a future call.

[clapierre]

What about "Alternative Reading Modes" This would support, audio, tactile / braille etc.

[wareid]

I like @clapierre's suggestion, but we have to think about what we are trying to express with reading mode. What info are we trying to convey to the end user? We also want to avoid blurring into things that will be reading system features that are out of the control of the content creator.

I think what we are looking for is an efficient way to inform the user that nothing in the file is blocking/preventing the use of alternative reading modes like TTS, screen readers, and braille. It's additionally important to note when a file has additional features like synchronized audio (media overlays), but I wouldn't lump that into this area.

I would say that accessibilityFeature = synchronizedAudioText does a sufficient job of describing when the content creator has provided an additional reading mode through audio.

Otherwise, I think reading mode = non-visual covers the remainder, as long as we make it clear in the description of that descriptor that this means the content creator has done everything they can to ensure non-visual reading modes are supported.

[avneeshsingh]

I also feel that term reading mode is reading systems oriented. What we want to convey to user is that the content supports non-visual reading. If we can find out a short term for communicating this, it would solve our problem.

[avneeshsingh]

In February 23, 2023 meeting we decided to find a suitable term for this. The minutes are as follows: gpellegrino: w3c/publ-a11y#148

WendyReid: we have to take care of respect content creator here. Is he capable do determine his content can be read non visually?

gpellegrino: the question to solve from user point of view is does this content fits the needs?

wendyreid: content creator can say "we have done nothing to block non visual reading". On retail side I prefer to display what is available. Non visual reading will depend on RS possibilities.

AvneeshSingh: Since this is non-visual reading, Gregorio, I think that the main issue to solve is to have a term to indicate that the content enables reading system and assistive technology to provide non-visual reading experience. We mainly need a good term for it, as reading mode is more of reading system capability. Let us get back to GitHub and settle on a good user oriented term.

Hadrien: screen reader friendly is too technical, we decided to say readable through synthetic voice or text to speech

[clapierre]

What about "EPUB Supported Content Access Methods"

[avneeshsingh]

should we think about something more descriptive? I am little concerned that we need to use these grouping names in user experience guide and some of the group names are not self explanatory. What this group of metadata is indicating is: "enable reading without sight".

[gregoriopellegrino]

I think I can close this issue, as we decided not to move in this direction.