Re: [a11y-metadata-project] accessHazard

I have updated the issue tracker to note that I updated the specification/ proposal to refer to WCAG 2.3 AND I updated the spec.

On Oct 2, 2013, at 3:19 AM, Charles Myers <charlesm@benetech.org<mailto:charlesm@benetech.org>>
 wrote:

Replying to the accessHazard part of this mail...

The intent of accessHazard was to describe hazard that matched to section 2.3 of WCAG http://www.w3.org/TR/UNDERSTANDING-WCAG20/seizure.html .  It was not intended to get to 2.2, where the issues are more one of poor design and utility rather than seizure hazards. I think that we should constrain our definition to WCAG 2.3, and recommend that WCAG2.3 look to expand their definition to audio and video as well, so that it's the larger set of hazards that AfA recognizes.

I'd just like to point out that we have two competing aspects here... Precision and adoption. And then an understanding of who the audience is for these tags.

Precision: Yes, specifying the exact three hazards that we know and specifying them is the most correct way to specifiy the information

Adoption: If we tell every video producer (e.g., Khan Academy) that they should be adding
<meta accesshazard="noflashing">
<meta accesshazard="nomotionsimulation">
<meta accesshazard="nosound">

I'd settle for making it easy for them, if they know there are no hazards (which, I am sure is true for 99.99+% of their content)

Audience: The people who will be adding these tags are ones who are accessibility advocates. If a new accessibility hazard that prompts seizures is discovered and they have done the work to tag their content already, they would be the most likely group to do this.

Our greatest challenge with this specification is not going to be one of getting accessibility advocates to do the right things. It's going to be getting the regular web masters and the like to add accessibility tagging at all. And we can help to achieve this by making this as simple as possible, while not compromising information content.

This challenge on precision vs. adoption runs through the specification.  If we ask people to do too much, they'll throw up their hands and not do anything at all, or do it wrong.  We've tried to error towards adoptable.


On Oct 1, 2013, at 5:39 PM, Andy Heath <andyheath@axelrod.plus.com<mailto:andyheath@axelrod.plus.com>> wrote:

I agree with Chaals (McN) on this - to say "none" doesn't allow for other kinds of hazards to be thought of later (though Chaals - re-indexing must I guess be something you do sometimes).

For example, one area we didn't do (yet) is cognitive - many resources are already labelled (in the informal content description) with stuff like "may contain upsetting material" - these kinds of terms might be beyond the scope of accessibility Metadata but I would not personally want to set that in concrete yet.

What this discussion does illustrate is that when new terms come along there will be a need to re-index (or re-interpret) what we know about a resource - also as technology advances and we are just able to determine more about particular resources and do more with them we may need to do that. For that reason, I'm not sure how I feel about the proposed

AccessMode=X+Y

(e.g. AccessMode=Visual+Auditory)

model because *any* structure like this in the Metadata expressed as associated with the resource may constrain what we can "know" about it as the kinds of transformations and the kinds of inference we can make increase.  It also bothers me that some of this information may be inferred from the context at the time. For example it might be in the case above that the auditory modality is only an equivalent for the visual in some environments where say particular supports are available, maybe particular AT - or it may be that at a later stage as technology improves we might augment that auditory with extra information discovered by an automated analysis of that resource and related resources used by others, or from feedback from other users. So information available only at delivery time might change that relationship. If its coded in the explicit Metadata we are stuck. Similarly there may be information that is available only at search-engine indexing time (i.e. not available at authoring time).

Surely there is scope here for search engines to compete in the market place on the indexing algorithms and the way the matching to user preferences and specific contexts is done ?

andy
On Wed, 02 Oct 2013 00:10:42 +0200, Charles Myers
<charlesm@benetech.org<mailto:charlesm@benetech.org>> wrote:

Charles McN had a great idea when he brought this up.  But it may
actually be a bit simpler to specify.
Rather than sav


 *   noFlashing
 *   noMotionSimulation
 *   noSound

in addition to the three properties we have today

 *   flashing
 *   motionSimulation
 *   sound

we might just want to have a state of "none" (saying that you checked
and that there are no hazards that you are aware of).

That would change the spec to

 *   flashing
 *   motionSimulation
 *   sound
 *   none (or noHazard)

which makes it cleaner.  I think that saying the negative to each of
the three properties would be a bit tedious.  And, of course, not
having the property means that it has not been checked.

Yeah, but we would want to be pretty sure that "none" really means none,
and nobody will identify a new hazard in the future that we didn't
notice. While I suspect we are "close enough" in practice, I prefer to
be really really conservative in this case.

I am thinking of the case where we discover that flashing at 3-7Hz is a
problem, but certain colour changes in a given frequency that don't
actually come across as flashing also turn out to cause problems. If we
can figure out what they are and define them in 2023 I'd hate to have a
million resources that say they have no hazards, when in fact we could
get a few thousand of them properly marked with the particular hazard
they do contain.

We need to be aware that this is messy. "Invisible metadata" will have a
certain rate of error that can increase over time - 1/3 might not be an
unreasonable guess although I hope it is much lower than that. As I
argued earlier, this is still better than 80%, if we only get 20% of
active hazards marked under the current approach. But it still implies a
real level of risk to real people. "No risk" is a 'brave' statement, and
I am not sure that I believe we know enough to make it reasonably
accurately.

Adding the noFlashing, noSound, etc seems to me a reasonable thing to do.

cheers

Chaals

On Oct 1, 2013, at 1:38 PM, Madeleine Rothberg
<madeleine_rothberg@wgbh.org<mailto:madeleine_rothberg@wgbh.org><mailto:madeleine_rothberg@wgbh.org>>
wrote:

Chuck has updated the issues list to include the discussion of whether
accessHazard should state positive or negative information. See that post
and my comments, which are also below, at:
[http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker#accessHazar

d_-_Ok_as_is.2C_or_should_it_be_negated_in_sense.3F]

I believe we need both accessHazard=flashing and accessHazard=noFlashing,
etc.. This is because there are three cases we'd like to distinguish:

1. checked and it's fine
2. checked and it is NOT fine
3. didn't check

"Didn't check" can be signified by no metadata -- this will be most of
the
content on the Web. In cases where someone has checked, let's record both
positive and negative states.

-Madeleine

--
You received this message because you are subscribed to the Google
Groups "Accessibility Metadata Project" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to
a11y-metadata-project+unsubscribe@googlegroups.com<mailto:a11y-metadata-project+unsubscribe@googlegroups.com><mailto:a11y-metadata-project+unsubscribe@googlegroups.com>.

To post to this group, send email to
a11y-metadata-project@googlegroups.com<mailto:a11y-metadata-project@googlegroups.com><mailto:a11y-metadata-project@googlegroups.com>.

For more options, visit https://groups.google.com/groups/opt_out.







andy
andyheath@axelrod.plus.com<mailto:andyheath@axelrod.plus.com>
--
__________________
Andy Heath
http://axelafa.com