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

[Grouping Accessibility Metadata] accessibilityFeature = none? #150

Closed
gregoriopellegrino opened this issue Jan 31, 2023 · 7 comments
Closed

Comments

@gregoriopellegrino
Copy link
Collaborator

This issue is part of the wider work presented in the issue #144 Proposal for Grouping Accessibility Metadata into Categories.

Working on a system for grouping accessibility metadata into distinct categories the editors had this question that we repost in this issue so that it can be discussed by the community.

The question is about metadata accessibilityFeature = none: in what situations does the metadata accessibilityFeature = none make sense? Do we group it in Conformance?

@clapierre
Copy link
Collaborator

I think this was added for completeness sake and would never be used in reality. I am not sure how an EPUB would even exist without at least one accessibilityFeature. I would think "unknown" would be more common as a publisher with no accessibility experience wouldn't have any idea what to include.

I am fine putting this in conformance and would be shocked to see it ever appear.

@madeleinerothberg
Copy link
Collaborator

This term was added to support the ability to make accessibiltyFeature mandatory. If a book is not accessible, we might still have hazard or accessMode info available. accessibilityFeature needed to be able to have a value for those cases.

These terms are not only for use with EPUBs, so the fact that all EPUBs are likely to have some accessibility features doesn't mean there is no use for the term, though if our guide is aimed at EPUB it could be that it doesn't belong in the guide.

If we keep it in the guide, the conformance group feels like a good place for that -- or the General Information section at the top since it suggests a serious lack of accessibility.

@ManfredMuchenberger
Copy link

This term was added to support the ability to make accessibiltyFeature mandatory.

In my opinion this is a very good explanation and reason to not drop it.

@avneeshsingh
Copy link
Collaborator

avneeshsingh commented Feb 21, 2023

The issue was discussed in Feb 9, 2023 meeting.
After very logical discussion, we decided to start from explaining the use case for European accessibility act where a publishers want to declare that publication is not accessible.

The relevant part of the minutes of meeting are:

gpellegrino: does this makes sense to include? do we group it in conformance section. From Madeleine - This term was added to support the ability to make accessibility Feature mandatory. If a book is not accessible, we might still have hazard or accessMode info available. accessibilityFeature needed to be able to have a value for those cases. … , does it make sense to have in conformance section even though there wouldn't be any conformance statement

AvneeshSingh: Yes we should keep it.

gpellegrino: do we group it in conformance or some other place.

Madeleine: I think conformance is a good spot. people looking a features wouldn't be looking there for none

MiiaK: I was going to say what Madeleine said.

gpellegrino: maybe when there is no conformance and a11y feature of none then we can say that it does not conform, not that we don't know if conformance is missing.

Madeleine: I am comfortable leaving this under Conformance. we could recommend where there a conflicts based on the metadata present if we get to that.

wendyreid: looking at case : person who did the metadata that accessibility features are "unknown" odd book with 0 features could even exist.

Charles: there is a11y feature of "unknown"

gpellegrino: we should mention how to handle conflicting metadata. what happens if we have differences in schema / ONIX section on conflicts.

MiiaK: from EU Act smaller countries will be publishers who don't have to follow these regulations they won't know if they conform or not.

AvneeshSingh: Wendy would it harm keeping this "none" under conformance.

wendyreid: could be confusing "Features = none"

AvneeshSingh: ONIX has a code for inaccessible

Charles: isn't inaccessible for ONIX same as "none" and no conformance statement

wendyreid: I wonder if on schema side there won't be a case with "none" or there is some bigger issue here. … , if anything is missing it become inaccessible.

AvneeshSingh: We should take this issue to GitHub and start from explaining the use case for European accessibility act where a publishers want to declare that publication is not accessible.

@chrisONIX
Copy link

For ONIX code list 196 - code 09 - Inaccessible (Known to lack significant features required for broad accessibility.) - This was added at the request of multiple large publishers who have been producing digital books for a long time, have extensive backlists available but may not have the resources to update all their old titles to current accessibility standards and want to be able clearly indicate in their ONIX message that they are aware that this ISBN may not meet accessibility requirements. It is something that should be visible to anyone considering acquiring this title - but it may not be exactly the same notion as ’none’

@avneeshsingh
Copy link
Collaborator

The issue was resolved in February 23, 2023 meeting. The minutes follow:

Gpellegrino: #150

AvneeshSingh: accessibilityFeature: None ; we need a way to indicate a publication is inaccessible. It's clear in ONIX (196-09), not so clear in schema.org

gpellegrino: in Europe we will need more metadata to indicate why it is not accessible (microenterprise ; burden or other exemptions cases). But it is a separate discussion.

CharlesL3: it's unlikely an EPUB has zero accessibility feature. The interest is to be able to indicate that something is missing clearly, not to say that we just don't know.

gpellegrino: I agree, it's strange to say there is no accessibility feature at all.

AvneeshSingh: so we can't use accessibility feature none to say it is non accessible.

GeorgeK: something else in conformance statement may be needed. You still get basics EPUB accessibility for free.

wendyreid: reflowable will always have display transformability. I agree we will never have no accessibility feature in an EPUB. We don't want to say there is nothing. I don't have the good answer but we need a way to express partial accessibility.

AvneeshSingh: My proposal is move this to feature group from the conformance group and get back to schema CG for exploring metadata for saying that publication is not accessible.

CharlesL: I like the idea of having a way to express partial accessibility (instead of presuming there is no accessibility at all).

Hadrien: it's possible to have an EPUB with no accessibility, reflowable with bad CSS blocks display transformability. There are also fxl with only images. I think one can produce non accessible epub unfortunately. With those epubs we also won't see any accessibility metadata inside.

GeorgeK: the need is something to alert a school that a document don't meet minimum requirements.

gpellegrino: it is a rare case where we express thing in a negative way.

Hadrien: general principles is if anything is not present it is unknown. We need in some context to be able to express negatives (no pagination for school use is an issue). I don't expect publisher's to include this info but a platform selling to schools I need to be able to express that. This missing is an issue.

proposed: move accessibilityFeature=none to book features from conformance

gpellegrino: +1

Miiak:_ +1

Wendyreid: +1

Jonas: +1

CharlesL3: +1

resolved

@gregoriopellegrino
Copy link
Collaborator Author

As decided in the February 23 call I moved accessibilityFeature = none to section Book features.

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

6 participants