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

Michael[tm] Smith wrote:
> 
> 
> 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.

While this may be true, we also do not have any justification on why none of
the proposed solutions brought forward by the TF won't work, or cannot work.
Instead, we have repeated claims that this particular problem can only be
solved by injecting something into the code that effects the outcome of
validators first (or in the case of meta-generator, repurposing a billboard
into a sledge hammer), and not the end users who absolutely require some
form of accessible name (alt text or equiv) on key images.


> 
> 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.

I respect the fact that Ted worked on this in good faith, and under the
desire to make things better.


> 
> 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.

I attempted to open that dialog in my previous response. I continue to
welcome comment and feedback.


> 
> 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.

I concede (personally) that this is a problem, and that this 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.

Fair enough. 

As I listen to your problem statement, I cannot help but conclude that this
Proposal is a single use solution to a multi-facetted problem; a proposed
solution that targets only missing @alt, but one that does not address the
end user experience, only the developer experience. It does nothing to
address the multitude of other generated errors that may or may not be under
the control of the developer using that same validator.

The problem as I understand it is one of filtering error messages that a
particular developer cannot affect change upon. This is a worthwhile goal,
but I continue to assert that the solution is to not be injecting magic
beans into the code, but rather to provide a better, more robust filtering
system in the validators. Introducing @relaxed on <img> purportedly solves
but one of the problems you just noted: how does it address the repeated
error messages that <g:plusone> tags generate? What of non-standard values
for meta@names? Would we also be using @relaxed on <meta>? (<meta
name="ziggy" relaxed="">)


> 
> 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.

"...while having the ability to disable handle errors for the other errors
separately..." 

I would think that a more global approach to handling these error messages
would be a worthy goal to shoot for, rather than a shopping list of "if you
get this error, use this magic bean, if you get that error, do this instead,
and for this third type of error message, insert this different magic bean
here..."  It strikes me that instead of cleaning up their code, developers
would be spending all of their time finding the appropriate silencing bean
for any given problem, then having to go back and inject that solution into
the code. I fail to see how this is beneficial or appealing to developers,
and I remain completely lost on how this will benefit end users.


> 
> > 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.

I understand that you and others continue to see this as a problem. I think
there is some significant disagreement on what "harming accessibility"
means, as well as a general disagreement on the method we should be using to
solve the problem. For example, I will continue to suggest that better
filtering on the validator (perhaps using something like a
white-list/black-list mechanism) is the better way forward.  

As I continue to listen and try and hear the other perspective, the problem
really does seem to be focused not on the end user, but rather the engineer
or developer in the middle. I feel their pain, but I feel the pain of the
end user even more, and this proposal does nothing to address the end user
problems of missing alt text (or rather the accessible name for the image).
THAT to me is a greater problem than the repeated droning of an error
message that I cannot fix. My tool should be able to filter that 'noise'
out, rather than have to go in and add additional markup to the code base to
manage that problem. If my car tire has a continuous slow leak, the solution
is to not always park by an air-hose, but rather repair the leaky tire...


> 
> 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.

So I'm trying to have that discussion, with low flame and hopefully
high-value discussion. What I am not hearing however is a recognition of the
continued problem(s) a non-sighted user will experience once a developer
drops his magic bean on the problem. OK, so it silences the Validator, but
it still produces the "image: five six seven dee eff gee dot jay-peg"
problem for the end user. How does this proposed solution manage that
problem? Do you and others even see this as a remaining problem?


> 
> 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?

I have not seen or heard anything that makes me believe that the cost
benefit of doing this improves the end user experience. The question is, who
is more important here, the developer or the end user? This proposal
certainly seems to me to slant that answer in favor of the developer, at the
expense of the end non-sighted user.


> 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.

I personally can understand how the terms "bogus" and "red herring" can be
an irritant (lordy knows I can be adept at being irritating), but I will
also suggest that having engineers continually throwing out "harms
accessibility" to accessibility SMEs has an equally irritating tone to it. 

If we are to have that fruitful discussion you are seeking, there must be an
admittance that accessibility SMEs actually do know what they are talking
about, and vague, general, "it's all kinds of bad" hand-waving statements
such as "harming accessibility" have little traction: we (certainly I) make
it my business (and livelihood) to understand *exactly* what that actually
means and how it manifests to end users. I don't claim to have a perfect
understanding of that, but it is none-the-less deep, rich and well defined
over the past decade + that I've worked in this space.

I think it would also be useful if we all agree that the priority of
constituents that HTML5 is supposed to be founded upon is very much in play
here: Users first, Authors second, Implementers third and Code Purity last.
As a direct question to you Mike, do you agree with that statement?


> 
> 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).

Here we will have to disagree for now. It is replacing one repurposed bean
with another magic bean, and does not address the real problem at the root
of the problem: a tool that is too noisy for the user to use.

JF

Received on Wednesday, 1 August 2012 07:38:05 UTC