Re: AccessModeSufficient

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.

*************
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)*

<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")*


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.

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>


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

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

<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?)


Thanks for your patience!

JF

On Thu, May 5, 2022 at 12:30 PM Matt Garrish <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>
> *Sent:* May 5, 2022 10:57 AM
> *To:* 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"