Hazard section revised to show as a list

[GeorgeKerscher]

I made the changes we discussed.

While I was at it, I made a change from unknown to the publication was not checked for hazards.

This should clarify if there is no hazard metadata or if the hazard metadata is marked as unknown by the publisher.

I did not include full stops anywhere. I thought that showing in a list made it a bit cleaner.

[mattgarrish]

We don't have an accepted definition of when to set a sound hazard and warn about that in the accessibility techniques, so should we be asserting here that it means there are loud sounds?

[mattgarrish]

I'm not sure the focus on light is the best description. It sounds like we're only concerned with strobe and other lighting effects, for example, when any flashing or blinking content (animated gifs, css animations, etc.) can be hazardous.

It might be better to generalize this to: "The publication contains flashing content which can cause photosensitive seizures" (Similarly for the compact statement.)

[GeorgeKerscher]

The audio hazard is a real dilemma. We have no definition and as far as I know there is no way to check an audio or video file for extreme sounds. Also, anybody could turn up the volume to a level that could cause hearing loss. So, what to do in our guidelines?

If we remove it, will we be getting a ton of questions? Should we put a note somewhere that audio hazards are not agreed upon and until there is consensus it should be left out? If we put it in, will people be thinking that they are missing something?

I am going to remove it and put in a note. We can see how that goes over.

[mattgarrish]

I think we need to get producers to state what audio hazard they are reporting in the summary and the display metadata could say to refer to it for more information. It's not ideal, but absent an agreed upon definition of a sound hazard, or possibly creating more specific hazards for audio (like a loudness hazard), there's not much else we can do.

I'd be surprised if anyone is reporting audio hazards since we don't define what they are, so if we get pushback on this it'll probably be on fixing the reporting issue first.

[GeorgeKerscher]

In the latest commit, I added a note and suggested the accessability summary as an option. I removed sound hazard from both examples.

I simply commented out the sound hazard from the example, so I would hope that Gregorio's script picks that up to include in the JSON file of strings.