W3C home > Mailing lists > Public > public-html@w3.org > August 2012

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

From: Janina Sajka <janina@rednote.net>
Date: Wed, 1 Aug 2012 03:41:57 -0400
To: "Michael[tm] Smith" <mike@w3.org>
Cc: public-html@w3.org
Message-ID: <20120801074157.GH12889@concerto.rednote.net>
Mike:

I don't want to chop your obviously earnest email, but you make a statement in
the core of your argument I simply must challenge you on. So, let me
simply top post and quote you:

< Mike writes:
> 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."
>

What have I missed? You use the plural "markup errors," but I see only
one error as the target of this CP--and only one use case  purportedly
so aggregious as to warrant this exceptional remedy. 
Are there additional errors and use cases you have in mind, as Steve
suggested?
http://lists.w3.org/Archives/Public/public-html/2012Aug/0001.html


When there's only one use case and only one error being evaded, it's
dishonest to claim a generalized approach to multiple "errors." Now,
I've not found you to be dishonest, so I can only assume you've allowed
yourself to get sloppy in your reasoning. But, your statement is wrong
nevertheless.

Let me add that I do not assert "hapless victims." Nor would I expect
Ted to say that of himself in this CP. But, what other conclusion is
there to draw when the rationale is arguing that these smart developer
people need this remedy because they just can't do anything about those
pesky alt errors? Worst of all, the argument even goes to claim the
machine is at fault--the system, whatever you want to call it. OK, I can
retract the piteous haplessness, but this certainly sounds like an
assertion of victimhood to me when the prime rationale offered is "I
can't do anything about it, so don't bother me with the errors."

My point, of course, is the opposite. I agree these are smart people who
understand how to get things done. I don't accept the assertion of
victimhood, hapless or otherwise. So, pardon me for being an
inconvenient fact in their existence--but that's what the W3C a11y
standards are about, the end users and consumers of web content, not the
convenience of these smart developers.

Janina



Michael(tm) Smith (mike@w3.org) writes:
> 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

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

The Linux Foundation
Chair, Open Accessibility:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/
Received on Wednesday, 1 August 2012 07:42:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:25 UTC