RE: More metadata questions

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>  <http://kb.daisy.org/publishing/docs/metadata/schema.org/accessibilitySummary.html>  Accessible Publishing Knowledge Base 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"