Re: More metadata questions

+1 to Laurent.

On 2022-05-25 10:47, Laurent Le Meur wrote:
> Hi,
> 
> I totally agree with John about the need for consistency in metadata
> definition (and presentation of examples). Reading system must not
> have to guess what they have to do, and there are still some
> imprecisions to solve.
> 
> Re. structured (html) accessibility summaries, let's be careful: html
> metadata content is complex to handle: it can cause problems vs the
> reading system if the reading system is html based (structure, CSS ...
> in brief you end-up with an iframe), and it must be converted to
> non-html content if the reading system is not html based. Metadata is
> not semi-structured content; metadata should have simple types.
> 
> Because the machine readable metadata are converted to human readable
> information, the accessibility summary is not the only text presented
> to the user. Therefore redundancy or (the inverse =) lack of
> consistency are both problematic issues. The choice that this WG has
> to make is to recommend the presentation of the accessibility summary
> as the _main_ information the user will see (in which case it should
> be as complete as possible) or as _secondary_ information, _below_
> other metadata (in which case it should complement other metadata info
> and not try to repeat it). Reading systems will follow the
> recommendation. Everything else will be in the hands of publishers.
> 
> Best regards
> 
> Laurent
> 
>> Le 25 mai 2022 à 16:32, Bill Kasdorf <bill.kasdorf@w3.org> a écrit
>> :
>> My recollection of the original intention behind these metadata
>> properties was that except for accessibilitySummary, they were
>> designed for machine, not human, reading. For that reason,
>> accessibilitySummary was to be a simple human-readable statement,
>> expressing whatever the provider of that metadata wanted to express
>> about the accessibility, or lack thereof, of the resource.
>> Admittedly, that opens the gate wide open to complete lack of
>> consistency and structure. Unless I'm not remembering correctly,
>> though, that was precisely the intention, to balance the strict
>> consistency and structure of the other properties. So as John points
>> out, "pick one" on multiple-statements vs. comma-separated for
>> accessModeSufficient; but I think in the real world that we
>> currently occupy, we may need to take what we can get for
>> accessibilitySummary, though I am a BIG advocate of nice clear
>> examples to show people what we'd like to see in those summaries.
>> 
>> I'm doing a lot of work with DSOs in a Mellon-funded project about
>> sharing remediated files, and I can tell you that there is little or
>> no consistency about how the nature of the files or of the
>> remediations are expressed. So I convened all the DSOs and we came
>> up with a standard vocabulary which is what they said they would
>> want (plain-English things like "added image descriptions," "tagged
>> the tables," "added page break markers," etc.). That vocabulary is
>> about to be standardized by NISO but as for now it's just used in
>> our project, and it was specifically not about communication to end
>> users, it was communication from one DSO to another DSO about what
>> they did and what they didn't do to a given file.
>> 
>> On 2022-05-25 10:17, John Foliot wrote:
>> 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 [5]: "_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 [6] 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 [1] [1] (linked from EPUB Accessibility
>> 1.1
>> [2]) the example offered there is:
>> accessibilitySummary
>> "_Captions provided in English; short scenes in French have English
>> subtitles instead._"
>> However, at the Daisy [3] Accessible Publishing Knowledge Base [3]
>> 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 [4] 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"
> Links:
> ------
> [1]
> https://urldefense.com/v3/__https:/schema.org/accessibilitySummary__;!!N11eV2iwtfs!qad7OFsEY9Sm78_5YJSvo2XnGqGWPVHRkjyD0TYqfekUqiVR75yOio3qWjtGQ5FB6uqTYylQw5-c$
> [2]
> https://urldefense.com/v3/__https:/www.w3.org/TR/epub-a11y-11/__;!!N11eV2iwtfs!qad7OFsEY9Sm78_5YJSvo2XnGqGWPVHRkjyD0TYqfekUqiVR75yOio3qWjtGQ5FB6uqTYyr8Ie0_$
> [3]
> https://urldefense.com/v3/__http:/kb.daisy.org/publishing/docs/metadata/schema.org/accessibilitySummary.html__;!!N11eV2iwtfs!qad7OFsEY9Sm78_5YJSvo2XnGqGWPVHRkjyD0TYqfekUqiVR75yOio3qWjtGQ5FB6uqTYwnjJn3i$
> [4]
> https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc2119__;!!N11eV2iwtfs!qad7OFsEY9Sm78_5YJSvo2XnGqGWPVHRkjyD0TYqfekUqiVR75yOio3qWjtGQ5FB6uqTYzorRd57$
> [5] https://en.wikipedia.org/wiki/Robustness_principle
> [6]
> https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/#examples
> 
> --
> Bill Kasdorf
> Principal, Kasdorf & Associates, LLC
> Founding Partner, Publishing Technology Partners
> W3C Global Publishing Evangelist
> bill.kasdorf@w3.org
> 
> 
> Links:
> ------
> [1] http://schema.org/

-- 
Bill Kasdorf
Principal, Kasdorf & Associates, LLC
Founding Partner, Publishing Technology Partners
W3C Global Publishing Evangelist
bill.kasdorf@w3.org

Received on Wednesday, 25 May 2022 14:59:39 UTC