- From: Zheng Xu <zxu@wysebee.com>
- Date: Wed, 25 May 2022 11:20:28 -0400
- To: John Foliot <john@foliot.ca>
- Cc: kerscher@montana.com, public-publishingcg@w3.org, W3C EPUB 3 Working Group <public-epub-wg@w3.org>
- Message-ID: <CANcx7nRYBpGLb8xsgkozpu9wQAu2=PSyCDz_rONeU6apT_oBkg@mail.gmail.com>
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" >
Received on Wednesday, 25 May 2022 15:27:37 UTC