search

w3c / a11y-discov-vocab

Repository for the maintenance of the schema.org accessibility property values for discoverability.
https://www.w3.org/community/a11y-discov-vocab/
Other
15 stars 8 forks source link

Utility of the "onVisual" access modes #9

Open mattgarrish opened 2 years ago

mattgarrish commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

pinging @madeleinerothberg since this is a new setup

madeleinerothberg commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.