Utility of the "onVisual" access modes

[mattgarrish]

We have a lot of access modes that appear to only exist to describe if certain types of content are represented visually, but is this the same thing as an access mode?

What does it mean to have to read "chemistry in a visual" from a sensory or perceptive sense as opposed to just having to read visually? Where do these "onVisual" terms end if we have to account for anything? How do you combine them with "visual" to enumerate the various sufficient access modes that could result?

Should we deprecate these terms? (We've never tried to make sense of them for epub.)

[clapierre]

I think Madeline Rothberg had some thoughts regarding these, but I agree I am not sure this is that useful as it would be covered by the broader "visual" accessMode.

[mattgarrish]

pinging @madeleinerothberg since this is a new setup

[madeleinerothberg]

The goal of the various "onVisual" modes is to serve as refinements of the visual access mode. The thought was that some users would want to know in more detail what kinds of barriers were in the visuals, to better determine if the resource would be useful to them. Of course that assumes that some providers, probably those providing accessible adaptations, might be willing to provide this level of detail.

They should roll up to a "visual" access mode if that isn't also provided.

They probably aren't relevant for accessModeSufficient, though.

[mattgarrish]

I keep thinking these should have been refinements using the original slash method:

visual/math
visual/diagrams
etc.

I wonder if we update the extension method if there's a way to refactor them back into subclassings.

(I also wonder if we should recommend setting plain old "visual" whenever using the "on visual" values as I expect these are probably less likely to be widely understood.)

[clapierre]

As I mentioned in #11 I think having a refinement of the main affordance makes sense here and we should recommend against "mathOnVisual", "chartOnVisual" and instead use

visual-math, visual-chart, etc.

We need to make things consistent and either use /'s or create single terms with the use of - between main value and the refinement. As for the refinement's naming convention of camelCase vs. the use of _'s I don't have a strong preference.

[madeleinerothberg]

Matt said:

(I also wonder if we should recommend setting plain old "visual" whenever using the "on visual" values as I expect these are probably less likely to be widely understood.)

The metadata should certainly be interpreted as having "visual" whenever it has visual-x. If it is useful in our guidance to suggest they both be explicitly set, that's fine with me.