Meeting minutes
<GeorgeK_> Date 18 August 2022
Accessibility Summary is SHOULD not MUST
GK: decision was made last week\
GK: Matt noted the official definition of the a11y-summary. Is consistent, but highlights subtleties and nuance
GK: Are we in agreement that this is one of our guiding principles for writing guidelines?
(No comments)
GK: will move forward with that assumptiong
the way we describe conformance has changed
it is now quite human readable - that helps us a lot
now if the conformance statement is displayed to user, we don't need to put that conformance summary into the accessibility summary
Naomi: it is hard to make a definitive statement
but in scenarios where there is little input from publishers... make a note "we are striving to..." - but publishers cannot make definitive statements
GK: agree with this. In terms of guidance from a11y summary - if it provides nuance...
whatever term you want to use: "we believe..." or "we strive to..."
Naomi: issue around number of languages authors invent
GK: Make sure we capture that in examples
and other verbage we create
Naomi: suggestion or recommendation
Gregoriao
Gregorio: this looks good - we should avoid duplication of data
if this is intended to display on the interface, we should not re-write this
CharlesL: Agree with gregorio. Also notes that Matt pointed out that we should NOT provide ally statements in multiple languagges
ONLy have the one langauge
CharlesL: may want to look at that more\
GK: In there now, and one of the things we want to retain
GK: a11y summary is only language of published content
GK: want to reference user-experience guide, with an expectation that the a11y metadata will be available to the end user
and that we do not "double up" the data
CL: agree. the older version of the spec ... URL. But it was not that readable, so we added it to the summary
but now that it is human readable, we can output that, and do not need to repeat in the summary
GK: we also need to revisit user experience guide
all things there related to conformance and the URL approach... we need to go back and address that. (i.e. there is not language changed needed)
ACTION: revisit user experience guide to align with recent changes to Accessibility 1.1 Spec - assign to Community Group
CL: make it an agenda item for next meeting
GK: IN the outline there are some principles identified
pointer to definition in Schema.org (guiding principle)
re-statement of things we expect to have been already expressed, not necessary to repeat in Summary
GK: example - if somebody has metadata "No accessibility hazards" the UX guide suggests that it be presented as No accessibility hazards
if accessibility mode 'textual' is present, it is announced as 'screen reader abled' [sic]
so no need to repeat in summary
so those are the principles - all the current stuff and then we look at what else is needed
Keep the things that remain valuable, remove the rest. Also the high-level considerations
GP: simpler if we call this "Accessibility Note" (conceptual) - the goal is to add human-readable information that augments the metadata
GK: in github repro now - the title is "Accessibility Summary guideline for ePub..."
and it is accessibility summary in Schema - it gets translated when it goes to Onix
Q: is it still call ed that there?
Yes
GK: so works there too - no need to change title
GP: the proposal was to only use that "name" as internal shorthand for this group/discussion
concern that "Summary" is misleading
JF: Understand the unfortunate concern - is this "fully baked"
GK: yes, took years to get into Schema.org
In abstract we could emphasize this is an augmentation
JF: echoes back understanding - suggests we DO speak to this in the abstract
GK: write in the 'template' that this is augmentation data
JF: sounds reasonable to me, but others?
Naomi: may be redundant and possibly overwhelming
but this may not JUST be augmentation, it may also include 'new' stuff that lacks definition @ Schema today
so that new stuff would need to be exposed somewhere (lacks controled vocab) - then this would be the right place too
GK: absolutely!
CL: not sure if we want to provide examples. have seen publishers who have added additional items to their ePub that went above and beyond
example: publisher had morse code, and added audio clip of the dots and dashes (above and beyond)
Naomi: working on crossword... there is a file format that can be downloaded into multiple crossword apps
(.puz) file extension
so making that file format available, and noting such in Accessibility Summary would be great
discussion around accessibility versus usability - do we want to expand the Accessibility Summary to capture 'usability' isses
Naomi: there is a gray line there
GK: we've discussed this in the past. ePub by its very nature is more accessible than other formats
not sure if everyone is aware that ePub *IS* more accessible than, say, PDF, so making these statements are beneficial
i.e. transformability (font resize and reflow) benefits all
GP: have concerns, but may want to defer to next call - example in file may be an issue
having examples that could be "copied and psted" may not be a good idea
VL: re no capability for multiple languages has been dropped - there may be a need if a book features multiple languages
CL: it would be difficult to tag that properly - there is usually a "primary language" even in multi-lang books
so publishers may 'reprint' if there is a need for books targeted to multiple languages
Q: to ask about multi-language
Namoi: notes that OPF file does not support multiple languages
may also be onerous on retailers - so decided that it is not ideal, but use-cases seem very small
GP: believes this problem with languages has already been resolved
GK: need to wrap this up now. Believes Avneesh plans on a call for next week.
But George and Charles will not be there. Suggests that this discussion wait until they return
GK: but would like to update the existing repro with what we agreed to here, and get the PR out for review
will mainly 'remove' things that are inappropriate, and then add some new draft text for review
+1 to Georges proposal
GK: next call to discuss this will be in 2 weeks (Sept.1)