accessibilityHazards naming inconsistencies

[clapierre]

We should be consistent here in the pro/con values for hazards, as this is a common issue for publishers.

Currently we have:

• flashing
• noFlashingHazard
• motionSimulation
• noMotionSimulationHazard
• sound
• noSoundHazard

We either should have "Hazard" added to all of them or none of them.
Since the property is "accessibilityHazard". I don't think we also need to include "Hazard" in the value's name.

[mattgarrish]

You can't remove hazard from the negated ones as then they become confusing to understand relative to the property name, which implies any value is a hazard. For example, if you include that there is an "accessibility hazard" of "no flashing", does that mean some people require the content to flash or are at risk?

In an ideal world, there would be binary properties for each, like flashingHazard="true/false", but we can't proliferate properties like that.

As to adding "hazard" to the end, we'll need to consider how problematic this is relative to the cost of changing, as the more properties we add to say the same thing the greater we burden implementations to deal with the variations. (I'd hope there isn't much actual content out there with hazards, but we can't drop terms and should avoid deprecating terms.)

[mattgarrish]

Can we agree to leave this alone, @clapierre?

I agree it's problematic but we've had these values in use for some time now and a name change now will just cause headaches for people without improving the situation a lot.

[clapierre]

ya fine for now.