Re: AccessModeSufficient

Matt writes:

> we should clarify the expectations here.

Yes Please!

JF

On Wed, May 18, 2022 at 9:54 AM Matt Garrish <matt.garrish@gmail.com> wrote:

> > 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> 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>
> *Sent:* May 5, 2022 3:12 PM
> *To:* John Foliot <john@foliot.ca>
> *Cc:* Matt Garrish <matt.garrish@gmail.com>; W3C EPUB 3 Working Group <
> 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> 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>
> 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"
>
>
>


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