Re: img@relaxed CP [was: CfC: Close ISSUE-206: meta-generator by Amicable Resolution]

Janina Sajka <janina@rednote.net>, 2012-07-31 21:36 -0400:

> Michael(tm) Smith (mike@w3.org) writes:
> Quoting from Ted's CP:
> 
> "The spec currently allows conformance checkers to waive alt=""
> conformance requirements on pages with <meta name=generator> present.
> This feature is intended to allow sites like Flickr (which accept bulk
> photo uploads from their users and can't reasonably require their users
> to provide alternative text) to check the conformance of their Web
> applications without being inundated with warnings or errors that the
> site developers can't do anything about. If we don't allow such sites to
> do this, they have and will add bogus alt="" text to their pages simply
> to pass in popular conformance checkers, thus harming the accessibility
> of their pages."
> 
> This paragraph contains three false assertions:
> 
> 1.)	The 2009 guidance document from the WAI Ad Hoc provided a solution that
> that site developers could adopt which would satisfy alt concerns when
> individual authors failed to provide individualized alt text.
> http://www.w3.org/2009/06/Text-Alternatives-in-HTML5.html

Yet we do not have agreement in the HTML WG on that solution being the
right one. If we did, we clearly would not have an open issue for this.

What we've been asked to do is can work together to see if we can get
agreement about how to resolve the issue. This CP is an attempt at that.

> The assertion that large site developers are hapless victims is false.
> Repeating this false assertion will not make it true.

Somebody else might say that "the assertion that large-site developers are
hapless victims is false" is false. And that repeating that false assertion
does not make it true.

So I really hope we can move away from that kind of discussion, which
pushes us even further away from agreement with each other instead of
bringing us closer to agreement -- and that we try to see if we can find a
way to actually get closer to agreement instead; for example, by discussing
the particulars of this CP and the proposed solution instead.

So as far as the particulars of this CP: This CP itself never asserts
anything about developers being "hapless victims". It instead describes
"large Web applications partly generated from code and partly sourced from
hand-authored HTML templates", and talks about the need to help developers
in those environments "catch markup errors that they can do something about,
without bothering them about markup errors they can't do anything about."

We know that there are developers who work with systems that produce
content in such a way that they have very direct control over some of the
markup but not all of it, and that some other markup in the content
produced by the system is automatically generated or injected by the system
itself, and that the mechanisms that produce that other markup are under
the control of other parts in their organizations, or even partners.

I would hope that the existence of such systems is an undisputed point.

So there are developers who are authoring HTML content in such environments
and trying to get it validate, and they run into validation problems with
"other" markup from the parts of the system that they do not directly control.

Note that the problems that have been reported from developers working in
such environments have not just been problems related to making images
accessible but also problems with such systems producing markup that's
invalid in a variety of other ways; for example, the system injects things
such as <g:plusone> tags, non-standard values for meta@name, etc.

As far as I can see nobody here is claiming that the developers who run
into those problems are "hapless victims". In fact quite the opposite.
I think we're assuming they're smart developers -- smart enough to
recognize the value of using a validator.

I want those smart developers to continue using the validator I work on --
instead of being frustrated with the experience of trying to use the
validator, giving up on it and not bothering to do validation any more --
and I want them to see greater net value from using the validator; e.g.,
finding it valuable that it gives them the ability to catch errors in the
markup for the parts of the content that they control, while having the
ability to disable handle errors for the other errors separately. And I
believe it's possible that the proposed solution might help do that.

> This use case is a bogus, red herring.

Clearly there are a significant number of other people in the group who
sincerely believe it is not a bogus red herring. I'm one of them. I believe
the use case is worth discussing and that it's worth making an attempt to
address it if we can, and to see if we can get agreement about it.

But continuing to dismiss that the use case itself is a "bogus, red
herring" --even though others believe it has merit -- gets us nowhere
closer to agreement.  All it does is further polarize the discussion.

We have discussions about issues in order to try to reach agreement about
them. Ted wrote this CP in a good-faith attempt at trying to find something
that we might be able to get closer to agreement about. I am supporting it
-- only with my hat on as a conformance-checker developer -- in a good-faith
attempt at trying to see if we can all maybe get closer to agreement, and
to help make sure that the behavior of the validator I work on meets the
real-world needs of developers working in a variety of environments who
value validation enough to take the time to use a tool I help maintain.

But that doesn't mean I absolutely believe we have to address this use
case. It may be we can't get agreement that the benefits of adding
something to address it outweigh the costs. But I would suggest please
let's have a discussion about it within that frame: Do the benefits of
making it possible to flag some images as "relaxed" outweigh the costs? It
may be we will not be able to get agreement that they do. But I think it's
worth trying, and having a discussion about it within that frame.

But claiming that the use case that's been put forward is "bogus" makes
it completely impossible to have any kind of productive mutual discussion
about it, and completely impossible to reach agreement about this issue.

There are use cases for all kinds of things that have been put forward over
the years but that the spec intentionally does not address, for a variety
of reasons -- among them that we could not get agreement that it was
necessary or beneficial, on balance, for the spec to address that use case,
or no agreement emerged about how to address.

This may eventually turn out to be one of those use cases. Or it may not.
But at the very least I think this CP is progress in the discussion, in
that I believe it's clearly a better solution than the solution it's
intended to replace (the meta@name=generator exception). 

  --Mike

-- 
Michael[tm] Smith http://people.w3.org/mike

Received on Wednesday, 1 August 2012 06:03:21 UTC