Missing AccessMode less used values

[clapierre]

Issue on the “EPUB Accessibility Techniques 1.1” WG Note

3.1 Identify primary access modes

Only the main access modes are provided, not the complete list as defined
https://www.w3.org/community/reports/a11y-discov-vocab/CG-FINAL-vocabulary-20240906/#accessMode-vocabulary

Missing are the following values:

chartOnVisual
chemOnVisual
colorDependent
diagramOnVisual
mathOnVisual
musicOnVisual
textOnVisual

[mattgarrish]

I still have a pet peeve with these. 😉

They aren't truly access modes. They're trying to explain what kind of content is encoded in a visual access mode, so "visual" also needs to be present when these are used.

Maybe there's a way of lumping them together and explaining them as additional descriptors to visual, but I still kind of wish we could go back and vote them off the island. They really belong in a separate property.

[madeleinerothberg]

They were meant to be refinements, with the automated assumption that if these were present visual could be inferred. But we don’t have a mechanism for refinements so they are just hanging around looking strange.

[mattgarrish]

Ya, and I'm worried if we start considering these primary access modes then it's going to require all epub producers to list all the applicable ones. That wasn't ever the intention. This is additional information about what is encoded visually.

[clapierre]

Great points.
We do have the power to "vote them off the island" if we want since we control the vocabulary.
If we think this is important to have this additional "refinements" on visual elements within the publication, where would it go?
They are not really accessibilityFeatures so doesn't make sense there. It probably begs for an accessibilityRefinements or accessibilityConsiderations new properties but I really don't want to go there as that would require a new addition to Schema.org which I don't this it is worth the effort.

This has only recently come up from one publisher, and I know there have been charts, and math as images which have never been included in the accessMode metadata before.

We could hold a meeting to discuss the deprecation of these accessMode values.

[mattgarrish]

We do have the power to "vote them off the island" if we want since we control the vocabulary.

Ya, but we should try and do that sparingly as we can never really know who has used them. (Does Ace report them as invalid now or does it not care what you list as an access mode?)

They are not really accessibilityFeatures so doesn't make sense there.

Right, it's sort of like reverse features. Here is a list of the visual content that may pose challenges, so you should be aware you're going to have to deal with the accommodations/features for them.

Something like visuallyEncodedContent might be more in the spirit (but even that doesn't fully fit with color dependency one).

But I agree with not trying to get this into schema.org. I think it would be a real challenge to explain to them why this is needed and get them to agree to it.

End of the day, they're not harmful, just a bit of an awkward fit. If we keep them, we should group and explain them better as supplementing the visual access mode.