Re: More metadata questions

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 <mailto: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 <mailto:tsiegman@wiley.com>
>>> From: John Foliot <john@foliot.ca <mailto:john@foliot.ca>>
>>> Sent: Wednesday, May 25, 2022 9:17 AM
>>> To: kerscher@montana.com <mailto:kerscher@montana.com>; public-publishingcg@w3.org <mailto:public-publishingcg@w3.org>; W3C EPUB 3
>>> Working Group <public-epub-wg@w3.org <mailto: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 <mailto: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 <mailto:john@foliot.ca>>
>>> Sent: Tuesday, May 24, 2022 8:41 AM
>>> To: W3C EPUB 3 Working Group <public-epub-wg@w3.org <mailto: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 <http://schema.org/> [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$ <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_$ <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$ <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$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc2119__;!!N11eV2iwtfs!qad7OFsEY9Sm78_5YJSvo2XnGqGWPVHRkjyD0TYqfekUqiVR75yOio3qWjtGQ5FB6uqTYzorRd57$>
>> [5] https://en.wikipedia.org/wiki/Robustness_principle <https://en.wikipedia.org/wiki/Robustness_principle>
>> [6] https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/#examples <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 <mailto:bill.kasdorf@w3.org>