Re: More metadata questions

Having created a summary <https://github.com/w3c/publ-a11y/issues/110>for a
Japanese EPUB publication,
I agree with Gregorio.  My summary mentions possible
accessibility mechanisms, but I am afraid that most of them
are *not* supported by existing reading systems.  (JDC will do
its best to make a difference.)

If I were an implementor of an e-bookstore user interface,
I would never show accessibility summaries to users.
I do not want to be sued by users or blamed by the
Consumer Affairs Agency of Japan.  I would generate
end-user-friendly descriptions from machine-readable
metadata depending on which accessibility features the
reading system support.

Regards,
Makoto


2022年5月26日(木) 18:18 Gregorio Pellegrino - Fondazione LIA <
gregorio.pellegrino@fondazionelia.org>:

> Thank you for all this discussion. I personally don't have much confidence
> with respect to the accessibility summary. My impression is that content
> producers don't have the skills, time and desire to create an accessibility
> summary by hand.
>
> On the other hand, generating the accessibility summary automatically from
> the metadata is redundant to the data already present in machine-readable
> format.
>
> Furthermore, if the rules for creating an accessibility summary from
> metadata are clear and shared and the text can be created automatically,
> who has to create it? Who publishes the EPUB file or who shows the metadata
> to users?
>
> I know we are returning to issues that have already been addressed, but
> the misunderstanding about these starting points seems to me to be the
> basis of all the misunderstandings that have been expressed.
>
> Gregorio
>
>
> ---
> Gregorio Pellegrino
> *Chief Accessibility Officer*
>
> [image: Logo di Fondazione LIA]
>
>
>
> Corso di Porta Romana 108, 20122 Milano
>
> Tel. +39 02 89280822
>
> www.fondazionelia.org - www.libriitalianiaccessibili.org
>
> [image: Icona Facebook]
> <https://www.facebook.com/Fondazione-LIA-Libri-Italiani-Accessibili-410025432878589>
>       Segui @fondazionelia
>
> ------------------------------
> *From:* Matt Garrish <matt.garrish@gmail.com>
> *Sent:* Thursday, May 26, 2022 01:11
> *To:* 'John Foliot' <john@foliot.ca>; kerscher@montana.com <
> kerscher@montana.com>; public-publishingcg@w3.org <
> public-publishingcg@w3.org>; 'W3C EPUB 3 Working Group' <
> public-epub-wg@w3.org>
> *Subject:* RE: More metadata questions
>
>
> > We can’t put the horse ahead of the cart here, either
>
>
>
> Lol, I shouldn’t write when I’m in a rush. Hit me about an hour later
> while driving that I thoroughly messed that metaphor up… :)
>
>
>
> Matt
>
>
>
> *From:* Matt Garrish <matt.garrish@gmail.com>
> *Sent:* May 25, 2022 4:17 PM
> *To:* 'John Foliot' <john@foliot.ca>; kerscher@montana.com;
> public-publishingcg@w3.org; 'W3C EPUB 3 Working Group' <
> public-epub-wg@w3.org>
> *Subject:* RE: More metadata questions
>
>
>
> Looks like I’ve missed out on the back-and-forth today, but going back to
> the original questions:
>
>
>
> > 1) Should the accessibilitySummary reference the *version* of WCAG
> being used?
>
>
>
> I would say yes, but this is subjective and a topic for the task force to
> delve into. The dcterms:conformsTo statement provides the
> machine-processable information about what version of the EPUB standard and
> WCAG have been met, so no matter what is written in the summary I wouldn’t
> rely on it for machine processing purposes. It boils down to whether users
> need this information in a more readable form or whether reading systems
> should be expected to translate the conformance strings into something more
> readable.
>
>
>
> > 2) "Structured" summaries - in my initial email I posed the question,
> 'could the summary be formatted as structured content?'
>
>
>
> Sure, if you weren’t writing them in the EPUB package document. The
> schema.org metadata wasn’t created for EPUB. It was created in
> conjunction with the LRMI metadata for describing resources on the web.
> We’ve had to adapt it to the limitations of EPUB, as I mentioned in an
> earlier thread about sufficient access modes.
>
>
>
> If you were to write the summary in HTML using RDFa or microdata, you
> could use whatever markup HTML allows, but the only way to make that
> available in an EPUB would be to reference the HTML as a linked record. We
> talked about moving to an approach like that back around the time of the
> 3.1 revision as part of developing a “browser friendly format”, but that
> fizzled out with IDPF. At this point in EPUB 3’s life, expecting reading
> systems to parse linked records for information is more fantasy than
> fiction. So the more realistic answer is, no, you can’t do it.
>
>
>
> (Note that while you can technically write RDFa and microdata in meta
> tags, it’s generally discouraged. The language of the text should be
> available from the language of the HTML page when you’re writing the
> summary in the body.)
>
>
>
> In any case, the history of the schema.org property development is why
> you won’t find commonality between the schema.org examples and EPUB.
> Aside from the package document being a unique case, there wasn’t an EPUB
> accessibility standard when the properties were developed. And as memory
> serves, when we created the summary property we weren’t considering listing
> conformance statements because it wasn’t clear then whether that would be
> how they were expressed. The definition was meant to be flexible as it’s a
> free-form field. No matter how helpful this new document proves, nothing we
> write in it will stop people from writing bad summaries. That’s the curse
> of human language.
>
>
>
> We can’t put the horse ahead of the cart here, either, so while I’d be
> happy to update the KB or the techniques document, short of consensus on
> what we’re updating the guidance to we’ll have to live with the
> discrepancies. The differences generally reflect where we’ve been on
> summaries at various points in time. That’s a big part of why this task
> force is looking at developing a recommended set of guidelines for
> authoring.
>
>
>
> Hope this helps,
>
>
>
> Matt
>
>
>
> *From:* John Foliot <john@foliot.ca>
> *Sent:* May 25, 2022 10: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
>
>
>
> 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://schema.org/accessibilitySummary> (linked
> from EPUB Accessibility 1.1 <https://www.w3.org/TR/epub-a11y-11/>) the
> example offered there is:
>
> *accessibilitySummary*
>
> "*Captions provided in English; short scenes in French have English
> subtitles instead.*"
>
>
>
> However, at the Daisy
> <http://kb.daisy.org/publishing/docs/metadata/schema.org/accessibilitySummary.html> Accessible
> Publishing Knowledge Base
> <http://kb.daisy.org/publishing/docs/metadata/schema.org/accessibilitySummary.html> 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://datatracker.ietf.org/doc/html/rfc2119> *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"
> ------------------------------
>
> *Network Confidentiality Notice*
>
> Il presente messaggio, e ogni eventuale documento a questo allegato,
> potrebbe contenere informazioni da considerarsi strettamente riservate ad
> esclusivo utilizzo del destinatario in indirizzo. Chiunque ricevesse questo
> messaggio per errore o comunque lo leggesse senza esserne legittimato è
> avvertito che trattenerlo, copiarlo, divulgarlo, distribuirlo a persone
> diverse dal destinatario è severamente proibito ed è pregato di darne
> notizia immediatamente al mittente oltre che cancellare il messaggio e i
> suoi eventuali allegati dal proprio sistema.
> Ai sensi del Regolamento UE 2016/679, il Titolare del trattamento
> garantisce la massima riservatezza ed il pieno rispetto degli obblighi
> previsti dalla normativa nazionale e comunitaria in merito alla protezione
> dei dati personali.
>
> This message, and any attached file transmitted with it, contains
> information that may be confidential or privileged for the sole use of the
> intended recipient. If you are not the intended recipient of this e-mail or
> read it without entitlement be advised that keeping, copying, disseminating
> or distributing this message to persons other than the intended recipient
> is strictly forbidden. You are to notify immediately to the sender and to
> delete this message and any file attached from your system.
> In accordance with EU Reg. 2016/679 (GDPR), the Data Controller guarantees
> the maximum level of confidentiality and full respect of all obligations
> provided for by the national and the EU legislation currently in force with
> regard to protection of personal data..
>


-- 
 --
慶應義塾大学政策・メディア研究科特任教授
村田 真