<AvneeshSingh> chair: AvneeshSingh
scribe+ zheng_xu
<CharlesL> https://github.com/w3c/epub-specs/issues/2116
<AvneeshSingh> https://github.com/w3c/epub-specs/issues/2116
AvneeshSingh: first item accessibilitySummary
matt: we have some duplication
... we don't know if publisher might want to expose
... our confirmance statement is not very clear
... so we turned to accessibilitySummary to have a bit more human readable information
... so that is some redundant information
<gpellegrino> +1 to Matt
<gpellegrino> same idea :)
matt: the accessibilitySummary can be machine processed but not as additional or extra information from conformance information
<mgarrish> I’m beginning to wonder how much value our machine-friendly conformance identifiers add. Since we control what you have to express, we could just make plain English descriptions. For example, instead of “EPUB-A11Y-11_WCAG-21-AA” we require “EPUB Accessibility 1.1 – WCAG 2.1 Level AA”. That would make the conformance string the basic text that libraries need. It’s just as easy
<mgarrish> to pattern a plain language string as the truncated ones we have right now, and since they’re patterned they’d be just as easy for machines to process or translate.
Naomi: how we can maintain the summary and how user will perceive it.
<mgarrish> The official definition in schema.org says this: "A human-readable summary of specific accessibility features or deficiencies, consistent with the other accessibility metadata but expressing subtleties such as "short descriptions are present but long descriptions will be needed for non-visual users" or "short descriptions are present and no long descriptions are needed."
Naomi: if the summary became something like we have to have all the a11y conformance item to be translated to summary then it could be a lot of work
... I wonder how we can put accessibilitySummary as practice
CharlesL: I have seen in some case the summary is just copy and paste so it's not what we are expecting how it works
... could the summary be a compromise from conformance item?
AvneeshSingh: I wonder how this could come into implementation
Naomi: there is absolutely a lot stuff we can clean up manually or automatically but the concern is if we would be conformable of making change.
... since some book can not be changed anymore according to a11y since we can not make editorial decision instead of book author
<CharlesL> An option as I mentioned would be to have the accessibilitySummary be a MUST if there is no conformsTo statement, otherwise it could be a "SHOULD" if there is a conformsTo statement included.
Naomi: it seems always need some manual process
... so, I am lean on accessibilitySummary is a bit complementary
gpellegrino: I agree with CharlesL. Some items can be automated by ACE
ChrisOliverOttawa_: the name accessibilitySummary might be a little confusing. When publisher wanted to advertise something like video does not have flashing but if the summary only tie to conformanceTo then it might be difficult to use
ccarr: I think I wouldn't rename accessibilitySummary. I think if it's a summary then it might need to be a summary of conformanceTo statement. If we need something complementary then we might need extra fields to let publisher to input
<CharlesL> • EPUB-A11Y-11_WCAG-20-AA
CharlesL: I agree we probably don't want to rename accessibilitySummary.
<CharlesL> • EPUB-A11Y-11_WCAG-21-AA
CharlesL: To the question to make it easier. in the 1.1 spec we have these type of data to specify version (EPUB-A11Y-11_WCAG-21-AA) and so on. I wonder if this is good enough or maybe we need something else.
mgarrish: we just expand it like "EPUB-A11Y-11_WCAG-21-AA" becomes "EPUB Accessibility 1.1 - WCAG 2.1 Level AA"
... it's still better than maching language and closer to human readable language
George: I like this idea then the defined strings needs to get into spec. Then ACE could check
... then do we have optimized specification
... then do we have concenses about if a11ySummary can be a requirement
ccarr: if we go with conformaceTo link I think we might need some general terms to explain what it conformance to in that link
Michelle_: in terms of aggregating contents how the accessibilitySummary could change content aggregation?
gpellegrino: we have machine readable meta data that can be produced by machine so you might be able to use
CharlesL: I agree accessibilitySummary is a comformance data in human readable way. We are defining some spec to let publisher to be able to tweak and use
... one concern from publisher is a11y also depends on reading system when putting accessibilitySummary
AvneeshSingh: we are expecting a11y v1.1 can move forward to recommendation in a few months
... so new suggestion might need to be moved to next version
... right now for the current version we will need some compromise
... we can add a note about where the accessibilitySummary should be put
<gpellegrino> +1 to Avneesh proposal
CharlesL: can it be a MUST or SHOULD
mgarrish: might hard to be a MUST to force people to add it
AvneeshSingh: for approach we will make issue tracker available to let WG comment
... we will make accessibilitySummary as recommended field that publisher can put it
... it's a recommendation from CG
<MURATA> +1
<CharlesL> To be clear accessibilitySummary we suggest changing from a *MUST* to a *SHOULD* be included from the CG
<Gautier> https://github.com/w3c/publ-a11y/pull/125/files
<Michelle_> Have to run to another call