RE: AccessModeSufficient

> I thought the fact there was audio in the book means one of the accessModes would mean “auditory” would be included.  

 

It’s messy. If the text is missing and only available in audio, then, yes, you would definitely have both auditory and textual as access modes. So, for example, if you have a book that only has headings and syncs those to full audio of the content, you’d list both. But that’s more of a case for accessibility republishers than something I’d expect mainstream publisher to produce.

 

If a mainstream publisher adds media overlays to their books, it’s more likely the audio is just an extra affordance that allows the user the option to turn on playback. It’s not required that they do that, and it’s not how the actual content of the book is encoded. We’d be saying that you have to be able to hear the content to fully read the book if it’s an access mode, even though you don’t. It’s an awkward case where you almost have an audiobook layered onto a non-audio book. That’s why I see media overlays as more of a sufficient access mode in these cases.

 

But you certainly could add more sufficient access mode sets when media overlays are present, since auditory could complement any of the non-audio options. So, for a work with textual and visual content, with text alternative and full media overlays, the complete set of AMS values would be:

 

textual,visual,auditory

textual,visual

textual

auditory

 

But this is also why I’m suggesting we should clarify the expectations here. I don’t find media overlays very intuitive because they can both fill missing gaps and be a secondary layer.

 

Matt

 

From: Charles LaPierre <charlesl@benetech.org> 
Sent: May 18, 2022 10:21 AM
To: Matt Garrish <matt.garrish@gmail.com>; Madeleine Rothberg <madeleine_rothberg@wgbh.org>
Cc: John Foliot <john@foliot.ca>; W3C EPUB 3 Working Group <public-epub-wg@w3.org>
Subject: Re: AccessModeSufficient

 

Hi Matt and all (including Madeleine)

 

I wouldn’t rule this out because EPUB’s media overlays feature means you could have a sufficient auditory pathway. Media overlays are not how the information is encoded or required to be played by default, so I wouldn’t expect the publisher to list auditory as an access mode based solely on their presence. But they do provide you an auditory playback option provided the complete text is narrated (i.e., they’re more like an affordance).

 

 

I thought the fact there was audio in the book means one of the accessModes would mean “auditory” would be included.  Now it might not be by itself as an accessModeSufficient unless you can really consume the entire book by auditory means, if it can be done then accessModeSufficient=“auditory” would be accurate. 

 

I am not as familiar with media overlays, but I would think that an accessModeSufficient would be also include “auditory, visual” as you listen to the auditory you can also visually view the images, and “auditory,visual,textual” if you can do all three at any time listen to the audio view the images and have access to the textual content.

 

Love to hear Madeleines take on this.

 

Thanks

Charles

EOM

 

Charles LaPierre

Principal, Accessibility Standards, and Technical Lead, Global Certified Accessible

Benetech

Twitter: @CLaPierreA11Y

 

 





On May 18, 2022, at 5:23 AM, Matt Garrish <matt.garrish@gmail.com <mailto:matt.garrish@gmail.com> > wrote:

 

Sorry for the late response, as I’m just getting back up to speed after being away!

 

Charles covered all the points you raised, but I just wanted to touch on this:

 

> As I am still a bit unclear, would I ever expect to see a metadata block like this:

> 

> <meta property=”schema:accessModeSufficient”>textual,visual</meta>

> <meta property=”schema:accessModeSufficient”>textual</meta>

> <meta property=”schema:accessModeSufficient”>auditory</meta>

 

I wouldn’t rule this out because EPUB’s media overlays feature means you could have a sufficient auditory pathway. Media overlays are not how the information is encoded or required to be played by default, so I wouldn’t expect the publisher to list auditory as an access mode based solely on their presence. But they do provide you an auditory playback option provided the complete text is narrated (i.e., they’re more like an affordance).

 

Does this make sense Charles, George, Avneesh, Gregorio? If so, perhaps we should better document this case.

 

Matt

 

From: Charles LaPierre <charlesl@benetech.org <mailto:charlesl@benetech.org> > 
Sent: May 5, 2022 3:12 PM
To: John Foliot <john@foliot.ca <mailto:john@foliot.ca> >
Cc: Matt Garrish <matt.garrish@gmail.com <mailto:matt.garrish@gmail.com> >; W3C EPUB 3 Working Group <public-epub-wg@w3.org <mailto:public-epub-wg@w3.org> >
Subject: Re: AccessModeSufficient

 

Hi John see below






On May 5, 2022, at 9:57 AM, John Foliot <john@foliot.ca <mailto:john@foliot.ca> > wrote:

 

Hi Matt, 

 

Thanks for this - it is very helpful.

As I am looking primarily at an authoring *system* (as opposed to individual book(s)) my primary goal is to find patterns. If I am to understand your response, for accessMode the BEST authoring pattern is the single entry pattern:

<meta property=”schema:accessMode”>textual</meta>

<meta property=”schema:accessMode”>visual</meta>

 

This is easy enough.

Yup, and if there was any audio in the book then you would include 

<meta property=”schema:accessMode”>auditory</meta>





*************
However, with accessModeSufficient, I am understanding that there is a conceptual 'array' of the different modes of consuming (based on the users possible non-disabled input modalities), which I am interpreting as: 

 

<meta property=”schema:accessModeSufficient”>textual, visual</meta>
      (user must be able to process text and imagery)

This would mean there are both textual elements and visual elements within the book

The visual elements may or may or may not be described.

 

<meta property=”schema:accessModeSufficient”>textual</meta>
     (user must be able to process text - that ALL imagery has text alternatives, and when required longer descriptions available. i.e. "screen-reader friendly")

 

Yes, except the concept of longer descriptions need not come into play here that would be covered under WCAG 1.1.1 and conformance issues and can be included with the accessibilityFeature=“longdescriptions"

 






Is this correct? A few knock-on questions then:

* If my initial understanding is correct (correct-ish?) does the order specified matter? In the code example you provided, it seems that the second line/declaration is a sub-set (or is it an alternative?) to the first declaration.

Order does not matter.






As I am still a bit unclear, would I ever expect to see a metadata block like this:

 

 

<meta property=”schema:accessModeSufficient”>textual,visual</meta>

<meta property=”schema:accessModeSufficient”>textual</meta>

<meta property=”schema:accessModeSufficient”>auditory</meta>

 

This would imply the following:

<meta property=”schema:accessModeSufficient”>textual,visual</meta>

You can consume this book using a combination of visual and textual modalities, which also means that the “auditory” modality is covered by one of these two either the auditory is represented visually say morse code, or textually.

 

<meta property=”schema:accessModeSufficient”>textual</meta>

You can consume this book solely with textual, meaning all images have a textual component as well, and since you stated there is an “auditory” modality to this book all auditory elements also have a textual representation that is accessible.

 

<meta property=”schema:accessModeSufficient”>auditory</meta>

You can consume this entire book with auditory so all text and images are described via auditory content.






 

That doesn't feel right, but?...  FWIW, this 'feels' more appropriate:

 

<meta property=”schema:accessModeSufficient”>textual,visual, auditory</meta>

 

 

Yes, this would have been missing in your previous example as this would really be one of the ways you can consume this book ie. Textually for the raw text, visually for the images, and auditory for any audio contained in this book.






<meta property=”schema:accessModeSufficient”>textual</meta>

<meta property=”schema:accessModeSufficient”>visual, auditory</meta> 

(where the third declaration states the user requires the ability to see imagery and hear audio, but the user does NOT need to be able to 'read' or process text content. Am I getting that right?)

 

Right in this case you are saying that to consume this entire book you could do this with the combination of visually and auditory which I would think this would be a children’s book with images and an audio track on each page.

 

Thanks

Charles.

 






 

Thanks for your patience!

 

JF

 

On Thu, May 5, 2022 at 12:30 PM Matt Garrish <matt.garrish@gmail.com <mailto:matt.garrish@gmail.com> > wrote:

Hi John,

 

It’s easier to think of accessMode as an array and accessModeSufficient as an array of arrays. The problem with EPUB is it can’t represent complex metadata and HTML really isn’t any better.

 

So with accessMode, you’re identifying all the ways that content is represented by default. The recommended practice is to put only one value per metadata element. So if you have:

 

<meta property=”schema:accessMode”>textual</meta>

<meta property=”schema:accessMode”>visual</meta>

 

for a book composed of text and images, the result should be an array of all the values. Since you can’t do proper arrays in EPUB or HTML, that means the closest single-element equivalent would be:

 

<meta property=”schema:accessMode”>textual,visual</meta>

 

But then you rely on the user agent processing the values as a comma separated list and not a plain text string.

 

If we had JSON at our disposal, for example, the more accurate way to express the metadata would be:

 

“schema:accessMode”: [“textual”, “visual”]

 

The accessModeSufficient property represents ways in which users can read the content, which is why it’s arrays of arrays. So when you have:

 

<meta property=”schema:accessModeSufficient”>textual,visual</meta>

<meta property=”schema:accessModeSufficient”>visual</meta>

 

What this would properly combine to, using JSON again, is:

 

“schema:accessModeSufficient”: [

              [“textual”, “visual”],

              [“textual”]

]

 

One pathway is being able to visually read the text and images while a second pathway has the information available in textual form alone (e.g., allowing TTS).

 

You don’t create a single array by taking a union of the values, otherwise you lose all information about what pathways are available to the user. But without being able to express arrays, we had to resort to using a comma-separated syntax for each list of values for this property. It’s hacky, but that’s not surprising for EPUB.

 

Hope this helps,

 

Matt

 

From: John Foliot <john@foliot.ca <mailto:john@foliot.ca> > 
Sent: May 5, 2022 10:57 AM
To: public-epub-wg@w3.org <mailto:public-epub-wg@w3.org> 
Subject: AccessModeSufficient

 

Hello All,

 

I am struggling a bit with this metadata declaration, or more specifically the authoring pattern.  The examples shown at: http://kb.daisy.org/publishing/docs/metadata/schema.org/accessModeSufficient.html are a bit confusing to the uninitiated, but I believe I am understanding this correctly. Can I test that assumption?




As I understand it today, both meta values (AccessMode & AccessModeSufficient) can be expressed in one of two ways: each Mode value expressed on its own line as a separate entry, OR as a single metadata declaration with a comma separated list of values. (This is where the Daisy examples get a bit confusing.)

As I understand it then, this means that for the user-agent, this: 
      <meta xmlns:html=" <http://www.w3.org/1999/xhtml> http://www.w3.org/1999/xhtml " property="schema:accessModeSufficient">textual</meta>
      <meta xmlns:html=" <http://www.w3.org/1999/xhtml> http://www.w3.org/1999/xhtml " property="schema:accessModeSufficient">visual</meta>

and this: 
      <meta xmlns:html=" <http://www.w3.org/1999/xhtml> http://www.w3.org/1999/xhtml " property="schema:accessModeSufficient">textual, visual</meta>

...are processed identically (that somehow the user-agent consuming the metadata is 'concatenating' the single value declarations programmatically, or accepting the author's concatenated declaration).

This also suggests then that this: 
      <meta xmlns:html=" <http://www.w3.org/1999/xhtml> http://www.w3.org/1999/xhtml " property="schema:accessModeSufficient">textual, visual</meta>
      <meta xmlns:html=" <http://www.w3.org/1999/xhtml> http://www.w3.org/1999/xhtml " property="schema:accessModeSufficient">auditory</meta>

…could be (would be?) processed the same as: 
      <meta xmlns:html=" <http://www.w3.org/1999/xhtml> http://www.w3.org/1999/xhtml " property="schema:accessModeSufficient">textual, visual, auditory</meta> 

Is that correct? That if, in my metadata block, I make two accessModeSufficient declarations, one a comma separated list followed immediately by another declaration with a single 'third' (or fourth but different) value, that the user-agent will still process it as a concatenated list of all values in practice? Additionally (and perhaps conversely), is the concept of cascading in play here? By that I mean, if the metadata block states: 
      <meta xmlns:html=" <http://www.w3.org/1999/xhtml> http://www.w3.org/1999/xhtml " property="schema:accessModeSufficient">textual, visual</meta>
      <meta xmlns:html=" <http://www.w3.org/1999/xhtml> http://www.w3.org/1999/xhtml " property="schema:accessModeSufficient">textual</meta> 
(This is an actual example on the Daisy page: Example 1 — EPUB 3)

... is it suggesting that the second declaration, without the second value of visual, "removes" or otherwise "erases" or overrides the previous declaration: first declaration = textual and visual, second declaration = textual; which may mean that 'visual' is no longer required (using a mechanism similar to CSS cascading)? Or is it that textual is redundantly declared a second time? (That is what is unclear in the Daisy KB entry I referenced.) Thanks in advance for the clarification(s).

JF

-- 

John Foliot | 
Senior Industry Specialist, Digital Accessibility | 
W3C Accessibility Standards Contributor |

"I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"




 

-- 

John Foliot | 
Senior Industry Specialist, Digital Accessibility | 
W3C Accessibility Standards Contributor |

"I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"