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"