Re: More metadata questions

Just jump in a bit more from side track :)
I like "fresh eyes on what seems to be an old problem" and "constructive
criticism" and I do believe these are very important elements to a healthy
community group. I think version number and structured accessibilitySummary
are valued use cases which I will add as use cases in the CG issue list as
well.
Cheers,
Zheng

On Thu, May 26, 2022 at 7:54 AM John Foliot <john@foliot.ca> wrote:

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