Re: More metadata questions

Gregorio writes:

> My impression is that content producers don't have the skills, time and
desire to create an accessibility summary by hand.

I'll also add Gregorio that even if they *do* have those three items
(skill, time, and desire) the 'rules' and/or instructions on how to do so
remain vague and confusing to the uninitiated.

I understand from both Matt and Charles that the intention is for this
metadata field to be "free-form", but even "free-form" should have some
basic structure - I'll argue that the statement should hit on key points or
'indicators' and that this group should highlight what they are or should
be.

For example, should it specifically reference *which *WCAG version is it
conforming to? I've asked that specific and precise question on this
thread, not really received a definitive answer one-way or the other, and
the on-line examples provided in the Community Group document do not
resolve that question - they instead perpetuate it by offering 2 examples -
one that does and one that does not. (I also asked about presenting the
information as a collection of bullet points, and really do not know
whether that is "good" or not - if I did so it would still not be done
using <ul> 'mark-up', so it would be a faux list, but still... or maybe the
key points should be separated with semicolons for the benefit of screen
reader users... (?))

As well, via this thread, I've pretty much concluded that while it *IS*
possible to offer the *accessibilitySummary* as structured (x)html text, we
probably should not do that, as it may have a negative impact on reading
systems. I learned that little nugget of info via this thread, but where
else is that documented? (I'd suggest this is an important consideration to
be aware of.)

I appreciate that the Community Group is now (or at least has recently)
attempted to tackle some of these issues and bring more clarity forward,
and so again, please take my feedback as constructive criticism: fresh eyes
on what seems to be an old problem.

> On the other hand, generating the accessibility summary automatically
from the metadata is redundant to the data already present in
machine-readable format.

But why is that a problem? Given that the audience for machine-readable and
the accessibilitySummary are different, why *NOT* have seemingly redundant
yet important information offered in two 'flavors' (human-readable and
machine-readable)?  What (if any) negative impact would there be? (None
that I can think of... "more" code is about as far as I can get...)

And to your larger point Gregorio - I agree around the overall "it's too
hard" observation, and I have started to think about creating a
"conformance statement generator" of sorts: answer some basic questions,
press the button, get back a  "copy-and-paste" block of code [sic] to use
in your ePub book. To Gregorio and Tziya's points it *should *be as simple
and easy as that.

JF

On Thu, May 26, 2022 at 5:17 AM Gregorio Pellegrino - Fondazione LIA <
gregorio.pellegrino@fondazionelia.org> wrote:

> 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..
>


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