Re: More metadata questions

Hi, John--

I completely agree on refining (especially clarifying and 
disambiguating) the accessibilitySummary spec.

As for the vocabulary, it has been developed for a very specific purpose 
in a specific project, but yes, I do think it would be generally useful. 
That's why NISO is planning to create a working group to standardize it. 
That will involve getting various folks involved to refine it so it is 
generally useful to the broader community. That work should start soon 
so I think it would be premature to put the initial FRAME version out 
there.

--Bill

On 2022-05-25 11:04, John Foliot wrote:
> Hi Bill,
> 
>>> 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.
>  A huge +1 there. But it is more than just that: the structure of the
> statement itself is... (JF searches for the right term) ambiguous.
> 
> For example, I know that text furnished as "metadata" in HTML is
> generally processed as string text and not structured text (so, for
> example, you cannot apply the @lang attribute to a document <title>
> element).  In fact, as I recall, any metadata text found in an HTML
> <head> block is *always* processed as string-text only. [1] As you
> note, the intention of _accessibilitySummary _was to be able to accept
> whatever statement the author/publisher needs or wants to make, but
> the specification and attendant documentation never specifies whether
> 'marked-up' content is acceptable (or not - as noted I believe NOT,
> but the ePub spec is silent there). If the intention of
> _accessibilitySummary _is to provide a human-readable block of text,
> then some logic would suggest that structured content would facilitate
> that more (my 'can you put a list in the summary?' question) - but
> perhaps there is a technical reason to avoid marked-up content here.
> Either way, an explanation and confirmation on that nuanced point
> would be helpful.
> 
>>> 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.
>  That is both interesting and potentially quite valuable across a
> larger swath of content. Is that vocabulary publicly published
> somewhere, and Bill would you suggest or recommend that other
> publishing entities start to adopt those terms/phrases?
> 
> JF
> 
> On Wed, May 25, 2022 at 10:32 AM Bill Kasdorf <bill.kasdorf@w3.org>
> wrote:
> 
>> 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] (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
> 
> --
> 
> 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://www.w3.org/TR/2011/WD-html5-author-20110809/the-meta-element.html#standard-metadata-names

-- 
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 18:04:10 UTC