Meeting minutes
How to group the DPUB ARIA roles for presenting them to ARIA WG?
Plannning for next revision of User experience guide for displaying accessibility metadata.
avneeshsingh: first version of the user experience guide was released last year as we needed feedback and we've received our first from Gautier at EDRLab, also waiting on US and Italy
avneeshsingh: we planned to start a new revision in this timeframe as the new EPUB Accessibility specification is going to CR so we need to update the guide to this new version
Gautier: avneeshsingh has sent the feedback to the group email so I won't provide full review - we translated the guide into French and held four workshops with 40 persons
… we're looking to find out if the information is useful to users and also if it is easy to implement
<avneeshsingh> User experience guide 1.0: https://
Gautier: we were not asking the general public for feedback but were asking users with specific needs - AT users and users of libraries for blind
… the feedback we had was not very good, we synthesized the reactions to six items
… felt the wording was overspecialized, but may not be in scope of the work we have to do now - potentially a localized problem with the translation
GeorgeK: we use the term screenreader friendly but if that term is not used in French then the localization could be the names of the AT (Jaws, etc.). Would that kind of localization help?
Gautier: what we see is using more generic terms
avneeshsingh: we can discuss the wordy details later on
Gautier: we will have seven workshops about wording that we can share but we think it is a local problem
… also found that some information is missing, some users are interested in the format and whether there is DRM
… we have strategies to handle this, but came from all users
… this information is useful to all readers, too, not just for accessibility
… look at broadening the meaning of accessibility as applicable for all
… also had difficult with mapping to onix and marc, need more work on this
… after this feedback we made a proposal to the participants to reorganize the information
avneeshsingh: there are several pieces of the feedback that we need to think about how to make localizable
… a lot of DAISY board members for example think we should not use terms like print disabled
… we are interested in extending the schema.org/onix crosswalk to add marc
… but first we need to figure out scope issues
… the design of the guide was specifically for accessibility metadata - this feedback includes fixed layout, format, drm, but it is confusing where these lie
… the information is generally useful to users - more generic properties
… drm is another example of what all users would like to know - helps accessibility but not specific to it
… should all these items be part of the guide?
Gautier: there is a lot of importance in knowing if a book is reflowable or fixed, example for readers with dyslexia who do not use screen readers and need to know if content can be controlled
GeorgeK: some of these things are not accessibility-specific. I see on VitalSource that they say fixed or reflowable but what they mean is it is PDF or EPUB, but an EPUB can be either fixed or reflowable
… I would see adding a section that is geared toward more general information about the book
… can discuss the higher-level items that are broadly useful to know
… drm is added after the publisher distributes the book so it is the reponsibility of the ditributor, but we could recommend that they include information about the impact of the drm on accessibility like whether you can copy and paste
… adding page numbers in the section would also really help
<avneeshsingh> next madel
MadeleineRothberg: the proposal for grouping the properties is a useful idea and perhaps that will be a way to approach the general information
… we worked only on the accessibility metadata itself but we can expand to metadata that isn't in these specifications
… so if you have information from other sources here is how you can integrate it
gpellegrino: perhaps we can add an appendix to handle this information since it is not directly accessibility related but important for the product page
… it is not a specification so we don't have to mandate what to include
CharlesL: we started this with just the accessibility metadata so pointing out the other information is useful
… we could also provide a glossary of terms that explain what we mean to help with understanding and translation
<Zakim> tzviya, you wanted to comment on DRM
<vince> how do I get on the speaker queue?
tzviya: a comment about drm and whether it gets in the way of accessibility - publishers cannot provide this information
Gautier: the user is sometimes able to pick the drm at the time of download - the bookseller can let them know the issues
… I believe a set of definitions would be really useful, too
vince: there are problems with the platform and reader that can cause problems - like mathml support
avneeshsingh: the accessibilityFeature property helps list these
GeorgeK: we need to bring any changes to the larger group before implementing because there are implications beyond this group
… we need to get feedback about the scope from as many groups as possible and incorporate their concerns so that we meet their needs
… we need to ensure the principles and guidance that is universal and can be translated so that we don't get different implementations
CharlesL: we lacked expertise for marc harmonization when we did the first version - need help to build out the mappings
<Bill_Kasdorf> I could recruit a MARC expert who might be able to help.
Gautier: I work with two people on unimarc but that's not marc21
avneeshsingh: from the discussions so far the scope on accessibility metadata looks fine, but it looks like we'll also elaborate to include the more universal metadata
… it is okay to have this kind of section where we can mention drm, fixed layouts, etc.
avneeshsingh: another question is the timeline issue - we have the French feedback but not yet from Italy or the US
… I expect this work will continue throughout the year as we'll need to harmonize all feedback
… let's start with the French feedback but also look to integrate the additional feedback we expect
GeorgeK: I'm not sure who in the US is planning to provide feedback - I don't know of an organized effort
<MURATA_> JP is not at all ready.
GeorgeK: once we start the marc discussion we'll bring in a wider group of people but not sure where that sits in timeline
MURATA_: we have requirements specific to Japanese community - we haven't gotten into exactly how this will be done
avneeshsingh: we don't have to rush the feedback if iterations are needed
CharlesL: would extra spacing and vertical issues require new features?
MURATA_: different opinions on this but you will have to embed some information in an EPUB
avneeshsingh: can you recruit some marc21 people before the next call Bill_Kasdorf?
Bill_Kasdorf: yes, I should be able to get someone within the next week?
… I'm on a NISO working group where we have some librarians that use marc routinely
… marc is impenetrable to people who don't use it routinely
avneeshsingh: we can discuss unimarc and marc21 in the next call
GeorgeK: do we want to reach out to any other groups? I can ping some people from Canada
avneeshsingh: accessiblity summary comes up a lot - we were assuming publishers would provide details in this field but it doesn't look like it's being used
Gautier: I'm not sure how to integrate the feedback with the github tracker
MadeleineRothberg: summary versus a list of features depends on which are available - the people reading this guide don't have control over what is provided so we can only suggest how it be used
… perhaps we need to say if the summary is available you need to make sure readers can access it
… sounds like we should elevate some accessibility features into another interface rather than grouping everything else
<Zakim> tzviya, you wanted to ask if the way that publishers use a11y summary is at all helpful
tzviya: in the epub specification there is a delineation between the requirements of the epub and the reading system - I can put a lot of things into the metadata that may not get used
<MURATA_> +1
tzviya: not sure if the summary is useful to users - we add it but would like feedback on how it's used
avneeshsingh: we have a plan to write a guide on how to author summaries but it keeps getting delayed by this guide
… could you provide feedback on it Gautier?
Gautier: from the user's perspective it was not seen as helpful because it may not be written well - but if we have guidelines on how to write a good summary that would be helpful
GeorgeK: the accessilbity summary was introduced to provide an easy to read description - now that we have a guide that explains how to translate the metadata into something that is easier to read the importance of the summary is reduced
… publishers are looking for a boilerplate summary that isn't customized for each title so it further becomes less useful
… there is also a 500 character limit imposed by some vendors so the future of summaries is uncertain
CharlesL: adding a summary is required by the accessibility specification and all GCA publishers are adding it with detailed information - also meant to have specific information about issues that aren't covered by the general metadata
Naomi: we are putting summaries into all our titles but it is formulaic based on the hazards - we may add more information in the future - the summary explains the other metadata; it does not repeat it
MadeleineRothberg: summary was also meant for niche cases that are not easy to explain through the regular accessibility metadata
<CharlesL> +1 to what MadeleineRothberg said exactly!