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 " property="schema:accessModeSufficient">textual</meta>
      <meta xmlns:html="http://www.w3.org/1999/xhtml " property="schema:accessModeSufficient">visual</meta>

and this:
      <meta xmlns:html="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 " property="schema:accessModeSufficient">textual, visual</meta>
      <meta xmlns:html="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 " 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 " property="schema:accessModeSufficient">textual, visual</meta>
      <meta xmlns:html="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"