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

Review use of use slash syntax for extensions #11

Closed mattgarrish closed 2 years ago

mattgarrish commented 2 years ago

When the vocabulary was first created, using slashes was the way to extend things. This method was retired a number of years ago now in schema.org, but we still mention it as a means of extending values.

We should see if there's a better practice we can follow, like what I mentioned in https://github.com/w3c/a11y-discov-vocab/issues/3#issuecomment-803294824

mattgarrish commented 2 years ago

We probably should put some urgency into resolving this, even if I don't expect there's a lot of use of extension values.

Does it make sense to use the approach I mentioned in the linked comment of using a dash to separate the value from its extension and disallowing any dashes in the extension values. We'd be following the precedent already set by the GS1 vocabulary, which is always a good thing.

It's not that complicated a change. For example:

displayTransformability/font-size would become displayTransformability-fontSize

One benefit would be consistent camelcasing of values and extensions.

(It would also be possible to use underscores -- displayTransformability-font_size -- but I like the consistency of one naming convention for values and extensions.)

Does that work for everyone?

clapierre commented 2 years ago

I don't have a strong preference myself to use camelCase vs the use of _ however for this particular refinement in the case of displayTransformability we have been recommending publishers not to specify all of the various options of fontSize, fontFamily, etc. as 99.99% of the time if they use CSS properly without hardcoded styling all of these are always valid.

Now in the case of accessModes "mathOnVisual", "chartOnVisual" etc. I can see a use case for that as those will be infrequently used. as accessMode="visual-math", "visual-chart".

mattgarrish commented 2 years ago

we have been recommending publishers not to specify all of the various options

Right, I was only showing that as an example as it was the only current one I could think of off the top of my head. We should also review what extensions we're recommending and why.

madeleinerothberg commented 2 years ago

I don't have an opinion on what the extension mechanism is, as long as it it accepted by the relevant communities and clearly expresses the notion that this is an extension or refinement mechanism.

mattgarrish commented 2 years ago

I still wonder if we should do away with extensions entirely. When I look at the history, slashes for extending enumerated values disappeared in 2014 and has never been mentioned again. I guess that's in keeping with schema.org not wanting to be arbiter of accepted values.

The GS1 approach isn't a perfect precedent as the syntax is defining URLs for the vocabulary values. They aren't really extensions. For example:

https://www.gs1.org/voc/ConsumerLifestageCode-ADULT

Defines the ADULT value for the ConsumerLifestageCode value type. It's not extending a value called ConsumerLifestageCode.

While it's an interesting concept to apply all kinds of refining statements onto a value, doesn't that mean our value maybe wasn't well spec'ed out, or maybe we're trying to say more than is needed? The "on visual" values, for example, might be better stated in the accessibility summary.

Part of me wants to trim down the complexity until there's a proven need for an extension that can't be satisfied in any other way. The properties themselves are extensible -- we can't, and don't want to, stop people from creating new values they need. Maybe that's better than extending values with new values?

clapierre commented 2 years ago

I am fine for simplification for now and these are rare enough that added that information to the accessibilitySummary works for me.

mattgarrish commented 2 years ago

The braille extensions are a good case for how this mechanism can fall apart quickly. There are so many statements you can make about the type of braille and no consistent way to string them all together. You're better off writing out the nuances in human-readable prose.

Maybe it's time for an inaugural call? This is a pretty big issue to get right.

madeleinerothberg commented 2 years ago

Matt's suggestions are fine with me. We can encourage metadata authors to list issues like charts, chemistry and other complex formats in the accessibiltySummary.

clapierre commented 2 years ago

I think a call would be a good idea. Does anyone have a list of those interested / should be on this call? @GeorgeKerscher ?

mattgarrish commented 2 years ago

I don't know if anyone's implemented the extensions. I know I haven't done anything to promote their use (or the "on visuals") in epub because I was worried they were too complex for authoring and processing. I was waiting to see if anyone asked about them.

It's probably sufficient to announce it on the mailing list, but it might be better to take the planning offline.