Re: More metadata questions

Hi Tziya, all,

I am a huge fan of metadata, but I personally believe that for metadata to
be the most useful, it needs a good and consistent structure so that
consuming systems know what they are dealing with unambiguously.

I have found that the expected values (and the instructions for furnishing)
the metadata values for both *accessibilitySummary* and *accessModeSufficient
*are cryptic at best, and down-right confusing at other times. Adding to
the confusion is multiple sources of information (the W3C ePub WG, the W3C
ePub Community Group, Daisy Consortium, others), and each source seemingly
offering conflicting or dis-similar examples... you are right Tziya, I am
both comfortable and experienced with digital accessibility as a topic (20+
years), and reading/working with W3C digital standards as a practitioner,
and yet I've been struggling here, and I share Tziya's concerns - this is
*really* geeky and hard to understand.

My fear is that (at least it as it appears to me) in an effort to be as
flexible as possible, (and possibly seeking to meet ePub publishers where
they are today, and NOT where we wish them to be tomorrow) that this
ambiguity around metadata is actually holding back the standardization
progress.

A classic example here is the *accessModeSufficient* authoring patterns,
which suggests either/both of comma separated values as well as individual
values line-by-line are acceptable. Which is it? Pick one, and make that
the standard - to my mind 'multiple options' is the antithesis of
"standard" (but that's just one person's opinion). I often echo back the
following re-working of Postel's law
<https://en.wikipedia.org/wiki/Robustness_principle>: "*Be specific in what
you ask for, and generous in what you accept.*"

Finally, I personally tend to be a visual/experiential learner, and
inspecting code examples is a preferred mode of learning for me - yet as I
noted for *accessibilitySummary *and the current Community Group document, the
two furnished code examples
<https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/#examples>
don't even align with each other (versioning question for WCAG). This makes
arriving at any expected outcome very difficult to achieve, as I do not
even have a "whole pattern" example to inspect and pattern my output
against. I offer this, not as a complaint, but as constructive criticism.

Respectfully,

JF

On Wed, May 25, 2022 at 9:21 AM Siegman, Tzviya <tsiegman@wiley.com> wrote:

> I will be not be able to attend the meeting on Thursday either, but I
> think John’s questions highlight some major concerns. John has years of
> experience in the a11y world but is relatively new to EPUB. What about
> someone who is new to both? What about someone who just wants to read a
> book and understand if their accessibility needs are being met? I know that
> we are writing best practices for reading systems too, but I don’t think
> that we can assume those will be followed. I stress again that we must talk
> to users. This includes individuals who are assessing their own needs,
> people from DSOs, and the people writing the metadata at large scale. I
> fear that we are writing a perfect specification for a world that does not
> exist.
>
>
>
> *Tzviya Siegman*
>
> Information Standards Principal
>
> Wiley
>
> 201-748-6884
>
> tsiegman@wiley.com
>
>
>
> *From:* John Foliot <john@foliot.ca>
> *Sent:* Wednesday, May 25, 2022 9:17 AM
> *To:* kerscher@montana.com; public-publishingcg@w3.org; W3C EPUB 3
> Working Group <public-epub-wg@w3.org>
> *Subject:* Re: More metadata questions
>
>
>
> ⛔
>
> This is an external email.
>
> Greetings All,
>
>
>
> After George's response to my question yesterday, I also received a
> meeting notice for this Thursday's call, where one of the topics is
> "Accessibility Summary Authoring Guidelines - Draft Community Group Report
> 24 May 2022". I hope to attend that call, but would also like to ensure my
> questions are documented.
>
>
>
> I have done a perfunctory review of that document, and note that 2 of my
> questions from yesterday remain vaguely defined. Specifically:
>
> 1) Should the accessibilitySummary reference the *version* of WCAG being
> used? In the 2 examples provided in that note, the first example DOES
> reference WCAG 2.0:
>
>  ("
>
> The publication meets WCAG 2.0 Level AA.")
>
> ...however, the second example does not:
>
> ("...
>
> and it also meets the Web AccessibilityContent Guidelines (WCAG) at the
> double  "AA"
>
> level.")
>
> [JF please note the typo - requires a space between Accessibility and
> Content.]
>
>
>
> Could this question be clarified and better specified in the document (I
> would personally recommend that it DOES reference the version number, but
> normative guidance one way or the other would be appreciated).
>
>
>
> 2) "Structured" summaries - in my initial email I posed the question,
> 'could the summary be formatted as structured content?' - i.e. in my
> example I offered a summary that contained a number of bullet points. Would
> that be acceptable, or would that be discouraged (or worse, non-conformant)?
>
> EXAMPLE:
>
>
> *accessibilitySummary "**This publication conforms to the EPUB
> Accessibility 1.1 specification at WCAG 2.1 Level AA*.
>
> ·       *This publication contains mark-up to enable structural
> navigation and compatibility with assistive technologies. *
>
> ·       *Images in the publication are fully described. *
>
> ·       *The publication supports text reflow and allows for reading
> systems to apply options for foreground and background colors along with
> other visual adjustments. *
>
> ·       *Print page numbers are present to enable go-to-page
> functionality in reading systems. *
>
> ·       *There are no accessibility hazards. *
>
> ·       *The publication is screen-reader friendly."*
>
>
>
> Might I request that these questions be answered in the emergent document?
>
> Additionally, what is the intended publishing track for this document -
> will it end up being an ePub WG Note? Other status?
>
>
>
> Thanks in advance!
>
>
>
> JF
>
>
>
>
>
> On Tue, May 24, 2022 at 11:01 AM <kerscher@montana.com> wrote:
>
> Hello,
>
>
>
> In the Publishing Community Group, we are working on the guidelines for
> the Accessibility Summary. We meet Thursdays at 14 UTC. I think it would be
> best to review the work happening there and join that discussion.
>
>
>
> John, let me know if you want me to forward you the agenda and meeting
> information.
>
>
>
> Best
>
> George
>
>
>
>
>
> *From:* John Foliot <john@foliot.ca>
> *Sent:* Tuesday, May 24, 2022 8:41 AM
> *To:* W3C EPUB 3 Working Group <public-epub-wg@w3.org>
> *Subject:* More metadata questions
>
>
>
> Hello,
>
>
>
> After reading through the documentation, I still have a question or two
> related to *accessibilitySummary*. Specifically, there are examples out
> there that, if not contradicting themselves, show different authoring
> patterns/examples which leaves me a wee bit uncertain what is the best
> pattern to use.
>
>
>
> Specifically, at Schema.org
> <https://urldefense.com/v3/__https:/schema.org/accessibilitySummary__;!!N11eV2iwtfs!qad7OFsEY9Sm78_5YJSvo2XnGqGWPVHRkjyD0TYqfekUqiVR75yOio3qWjtGQ5FB6uqTYylQw5-c$> (linked
> from EPUB Accessibility 1.1
> <https://urldefense.com/v3/__https:/www.w3.org/TR/epub-a11y-11/__;!!N11eV2iwtfs!qad7OFsEY9Sm78_5YJSvo2XnGqGWPVHRkjyD0TYqfekUqiVR75yOio3qWjtGQ5FB6uqTYyr8Ie0_$>)
> the example offered there is:
>
> *accessibilitySummary*
>
> "*Captions provided in English; short scenes in French have English
> subtitles instead.*"
>
>
>
> However, at the Daisy
> <https://urldefense.com/v3/__http:/kb.daisy.org/publishing/docs/metadata/schema.org/accessibilitySummary.html__;!!N11eV2iwtfs!qad7OFsEY9Sm78_5YJSvo2XnGqGWPVHRkjyD0TYqfekUqiVR75yOio3qWjtGQ5FB6uqTYwnjJn3i$> Accessible
> Publishing Knowledge Base
> <https://urldefense.com/v3/__http:/kb.daisy.org/publishing/docs/metadata/schema.org/accessibilitySummary.html__;!!N11eV2iwtfs!qad7OFsEY9Sm78_5YJSvo2XnGqGWPVHRkjyD0TYqfekUqiVR75yOio3qWjtGQ5FB6uqTYwnjJn3i$> the
> example offered there is:
>
> *accessibilitySummary*
>
> "*This publication conforms to the EPUB Accessibility specification at
> WCAG Level AA*."
> (JF: and specifically calling out WCAG, but without the version number).
>
>
>
> I want to presume that the W3C publication is "more up-to-date", and while
> the examples don't directly contradict themselves, there are significant
> differences in what is offered as an authoring example. I want to make the
> following presumptions, but am seeking a sanity check here (please).
>
>    - The accessibilitySummary *SHOULD
>    <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc2119__;!!N11eV2iwtfs!qad7OFsEY9Sm78_5YJSvo2XnGqGWPVHRkjyD0TYqfekUqiVR75yOio3qWjtGQ5FB6uqTYzorRd57$> *reference
>    the *version* of WCAG that the ePub conforms to.
>    - The accessibilitySummary *SHOULD *provide content authored *primarily
>    to be read by a human*.
>
>
>    - The accessibilitySummary *MUST NOT *use structured content (i.e.
>       avoid using lists or tables in the Summary), although correct punctuation
>       is important (seperate key concepts with a semicolon or period). The
>       assumption here is that while the metadata text is likely just string-text
>       (i.e. does not support HMTL markup), the punctuation makes the content more
>       'readable'.
>
> Based on the two examples, I am looking at essentially merging the prose
> content from those examples together, to end up with something like:
>
>
>
> *accessibilitySummary*
>
> *"**This publication conforms to the EPUB Accessibility 1.1 specification
> at WCAG 2.1 Level AA*. *This publication contains mark-up to enable
> structural navigation and compatibility with assistive technologies. Images
> in the publication are fully described. The publication supports text
> reflow and allows for reading systems to apply options for foreground and
> background colors along with other visual adjustments. Print page numbers
> are present to enable go-to-page functionality in reading systems. There
> are no accessibility hazards. The publication is screen-reader friendly."*
>
>
>
> ...and so, my final question is, does that summary look acceptable? Or am
> I overthinking this? While I am presuming NOT(*) to use structured data,
> should the URLS for EPUB Accessibility 1.1 and WCAG 2.1 specifications be
> provided in the summary?
>
> (* or am I wrong there? From a readability perspective, I believe the
> statement could be formatted to be *more* readable by using bullet-points:
>
>
>
>
> *accessibilitySummary "**This publication conforms to the EPUB
> Accessibility 1.1 specification at WCAG 2.1 Level AA*.
>
>
>    - *This publication contains mark-up to enable structural navigation
>    and compatibility with assistive technologies. *
>    - *Images in the publication are fully described. *
>    - *The publication supports text reflow and allows for reading systems
>    to apply options for foreground and background colors along with other
>    visual adjustments. *
>    - *Print page numbers are present to enable go-to-page functionality
>    in reading systems. *
>    - *There are no accessibility hazards. *
>    - *The publication is screen-reader friendly."*
>
> ...but may make it more verbose than necessary, or the formatting would be
> completely 'lost' by consuming systems. Thoughts? This bulleted list
> example *IS* more human readable...)
>
>
>
> TIA
>
>
>
> 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"
> ------------------------------
> The contents of this email and any attachments are confidential and
> intended only for the person or entity to whom it is addressed. If you are
> not the intended recipient, any use, review, distribution, reproduction or
> any action taken in reliance upon this message is strictly prohibited. If
> you received this message in error, please immediately notify the sender
> and permanently delete all copies of the email and any attachments.
> ------------------------------
>


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