Epub-specs: Reconsider the inclusion of accessibilityControl and accessibilityAPI

[mattgarrish]

Although the accessibilityControl and accessibilityAPI properties are optional in the accessibility specification, I don't find these are very relevant to content and only add confusion.

The properties are more relevant to the usability of reading systems, as users are more likely to want to know if a reading system is compatible with an operating system API or can be controlled by various input methods.

The accessibility of the content is already regulated by WCAG. If content is authored to meet the scripting requirements of the standard, making fine-detailed statements isn't necessary. If anything, it adds confusion as publications without any scripted content potentially have to list every control method even though listing them is largely irrelevant.

It might be helpful, therefore, to remove the two properties from the optional list and replace them with a note that explains why they are not needed.

/cc @GeorgeKerscher @avneeshsingh @clapierre

[clapierre]

+1 Matt, I agree we should consider removing these two metadata pieces from the Accessibility Specification.
GCA has seen a lot of publishers try to include them and for the most part was done incorrectly and we have recommending they remove them from their OPF files.

[rdeltour]

I've always found these properties more confusing than useful (see this old thread from 2016!), so you get my vote for removing them 😊.

[mattgarrish]

I've always found these properties more confusing than useful

Ya, we tried hard to rationalize them, but even for the first version we struggled to place them.

By only removing them, we also don't risk invalidating existing content, as any schema.org properties will always be valid. We can just chalk it up to a failed experiment and not promote their use anymore.

[murata2makoto]

Agreed, but I am just wondering if we should submit a defect report to SC34 about dropping them. Shouldn't be difficult.

[mattgarrish]

I am just wondering if we should submit a defect report to SC34 about dropping them.

Would that require changing the current document or is it more like adding an errata? The ISO doc is consistent with 1.0, so technically if we drop them it would be reflected in the next ISO version, too.

[murata2makoto]

@mattgarrish

Would that require changing the current document or is it more like adding an errata? The ISO doc is consistent with 1.0, so technically if we drop them it would be reflected in the next ISO version, too.

Create a draft errata (called Draft Technical Corrigenda in ISO) and start a DCOR ballot. This should require about 4 months. If the ballot is successful, there are two ways to publish the result. One is to publish Technical Corrigenda (basically as is). The other is to publish a consolidated new edition. We have to speak with ISO editors and choose.

[mattgarrish]

Proposed Solution

Remove reference to the two properties from the specification.