Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add information on displayTransformability. Add where? Could be part of Screen Reader Friendly calculation. #10

Closed
gregoriopellegrino opened this issue Feb 20, 2020 · 4 comments

Comments

@gregoriopellegrino
Copy link
Collaborator

From Madeleine's email: https://lists.w3.org/Archives/Public/public-epub3/2020Feb/0004.html

EPUB accessibility metadata includes the important property displayTransformability, which is sometimes called reflow capability. Text that can be transformed into different kinds of displays can meet the needs of a wide range of readers by providing the text in synthesized speech, large print, alternate colors, braille, or any other presentation. Nearly all ebooks provide displayTransformability. Exceptions include picture books or other visually-presented text, where the text is part of an image, and fixed-format large print books, which are intended to meet the need for large print but do not have transformable text. Audio books, which have no true text, would also lack displayTransformability. Any ebook that offers displayTransformability is largely accessible to many users and would qualify as Screen Reader Friendly.

@mattgarrish
Copy link
Member

One comment I wanted to make yesterday about the idea that reflowable can be inferred from whether or not epub metadata is set, while true, misses that this negatively affects the ability to discover this information in other ways.

For example, given the natural use of schema.org metadata for search discovery, how would you present on a page describing the accessibility of a publication that the content is reflowable? You can write it out in plain text but without accessibilityFeature=reflowable there isn't a way to machine tag it.

It also complicates harvesting the information from any future implementations of the web manifest, as it moves from reading a common set of properties to inferring information.

In other words, I agree there is a redundancy aspect to adding the term, but at the same time I think it might be better to be explicit and express the information all in a common form.

@laudrain
Copy link
Collaborator

@mattgarrish

given the natural use of schema.org metadata for search discovery

sorry but I have to insist that for books, schema.org isn't used by search engines, at least Google's one, to index information in their knowledge base. Google's database is fed by ONIX for books feeds from aggregators.

how would you present on a page describing the accessibility of a publication that the content is reflowable?

And web pages presenting e-books on any vendor/library web site finds the format and 'reflowable' information from the ONIX feed.

That said, this leads me to ask if schema.org doesn't have already values to describe an ebook format. It has !
But it is rather short: https://schema.org/BookFormatType

Instances of BookFormatType may appear as values for the following properties

Property	On Types	Description
bookFormat	Book 	The format of the book.

Enumeration members
AudiobookFormat
EBook
GraphicNovel
Hardcover
Paperback

In any case, I'm not really in favor to add a new accessibilityFeature for something that doesn' belong to the accessibility domain: "accessibilityFeature=reflowable".

@mattgarrish
Copy link
Member

Google's database is fed by ONIX for books feeds from aggregators.

@laudrain that's fine for books with onix feeds but what about everything else that is published? How is this relevant? schema.org metadata isn't just for professionally published books. It's about discovery of any content. My point is exactly this, that we're not finding a solution that works generally for anyone in any situation.

But it is rather short: https://schema.org/BookFormatType

And it doesn't make sense to me to layer in properties of the content into the format of the book. You could record that it is an EPUB in that field, but not whether it is fixed, reflowable, or some combination of the two. That's mixing concerns. All that does is complicate the field for any program needing to make sense of the value.

In any case, I'm not really in favor to add a new accessibilityFeature for something that doesn' belong to the accessibility domain

Sorry, I don't follow this point. How is knowing whether a book is reflowable not beneficial for users looking for content they can consume? That's specifically information that users with low-vision would be looking for, as we discussed yesterday.

@laudrain
Copy link
Collaborator

@mattgarrish it was tentative ;)
I agree that:

  • not all EPUB are accompanied by an ONIX feed.
  • BookFormatType isn't enough (but maybe enhanced), and is mixing with other EPUB information
  • knowing that an EPUB is reflowable is a must know for users

But reflowable information is already in any EPUB. It's the default.
Do we really need to add this redundancy ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants