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.

[gregoriopellegrino]

Surely by removing the sound hazard warning we will receive many questions....

Another thing: It seems to me that starting each sentence with "The publication contains..." is a bit redundant. What if you put "The publication contains" at the beginning of the list and then the list?

[clapierre]

Although I see dilemma, I am not sure I totally agree with just putting in note stating we are not going to add the examples for Sound Hazards. Since we are not now giving any guidance on what a bookstore should do when they encounter them. I am fine for now with this approach but think we should circle back to what we should ultimately do.

[GeorgeKerscher]

Moving Avneesh's comment to the hazard, was in the navigation issue:
Avneesh writes:
Yes, we should avoid example that indicate presence of sound hazards.

George asks:

We have no hazards

Should we create another examplee that has no sound hazard, no motion hazard and a flashing hazard?

If we want to give an example of no sound hazard, it is ok because publication without any audio will not have sound hazard.

[gregoriopellegrino]

I only point out that in the metadata we have the metadata to declare a sound hazard and in the techniques we use it. So the risk is a mismatch between principles and techniques.

[GeorgeKerscher]

We could have all seven possibilities. Would that help?

[GeorgeKerscher]

I made the changes we discussed. The description of unknown and no metadata present should be reviewed by somebody. If it looks OK, please merge.