Re: More metadata questions

Hi Zheng,

> In terms of wcag version it is covered here
https://www.w3.org/TR/epub-a11y-11/#example-a-basic-conformance-statement


Sure, but that is for dcterms:conformsTo - however I am asking about
*accssibilitySummary
*which is a different metadata value string. In the 2 existing examples
<https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/#examples> in
the draft Community Group document, one references the version number, the
other does not.

My concern is over the inconsistency in the examples in that draft
document, as well as the lack of clarity around the topic in general -
specifically should the *accessibilitySummary* explicitly reference which
version of WCAG the book is striving to conform to? That *should* be a
yes-or-no question, but today the current answer is that the spec doesn't
say, and even within this email thread nobody has yet provided a definitive
response.

I am aware of the effort that George and the Community Group have applied
here, and my comments are not "complaints", they are candid observations
hopefully provided as constructive feedback for that document, and ePub
documentation in general.

> The spec on github is here
https://github.com/w3c/epub-specs/blob/main/epub33/a11y/index.html so we
can file issue under that github repo (
https://github.com/w3c/epub-specs/issues/).

Happy to file a github issue (or issues) as required, however the current
comments are related to
https://w3c.github.io/publ-a11y/drafts/schema-a11y-summary/ and not
https://github.com/w3c/epub-specs/blob/main/epub33/a11y/index.html . This
is also another of my lower-level concerns: information scatter. Between
the Working Group, the Community Group, Daisy Consortium,
IDPF/Schema.org... finding the single source of truth has become
increasingly complicated, and when all of those different sources are all
saying slightly different things, what is the uninitiated to do?

(For example, the 'examples' at Schema.org
<https://schema.org/accessibilitySummary> for *accessibilitySummary* have
no indication or suggestion of referencing WCAG - with or without a version
number. Is that the 'answer' then? To not reference WCAG in the
*accessibilitySummary* statement? Or should I look at the examples from the
latest draft from the Community Group - the two examples that do not even
support each other? I hope you can appreciate the confusion here.)

JF

On Wed, May 25, 2022 at 11:20 AM Zheng Xu <zxu@wysebee.com> wrote:

> Hi John
>
> I think we can also file issue regarding the questions then we will not
> forget document it. The spec on github is here
> https://github.com/w3c/epub-specs/blob/main/epub33/a11y/index.html so we
> can file issue under that github repo (
> https://github.com/w3c/epub-specs/issues/). Please let us know if need
> help creating github issue.
>
> George and some of PCG members are also working on accessibilitySummary as
> a sub-taskforce I think this could be very useful input. In terms of wcag
> version it is covered here
> https://www.w3.org/TR/epub-a11y-11/#example-a-basic-conformance-statement
> but I also feel how to describe it as human readable format in
> accessibilitySummary could be a bit more clear. I look forward to further
> discussion in tmr meeting or the accessibilitySummary sub-TF meetings.
>
> Cheers,
> Zheng
>
>
> On Wed, May 25, 2022 at 9:17 AM John Foliot <john@foliot.ca> wrote:
>
>> 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"
>>
>

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