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

John Foliot <john@foliot.ca>, 2012-08-01 00:37 -0700:

> 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

I'm not saying this is the only way it can be solved. I'm not sure anybody
else is either. I think we all (you included) are trying to find the best
solution we can all agree on, even if it's imperfect. I don't think there
is any single perfect solution to this problem. There are a variety of ways
to to try do deal with, and this is one of the ways. And it does not
exclude the use of other solutions.

[...]
> 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;

I would describe it as instead as one approach to trying to help solve a
complicated problem -- and an approach which can potentially be used in
conjunction with other approaches.

> a proposed solution that targets only missing @alt, but one that does not
> address the end user experience, only the developer experience.

I don't think the solution proposed in this CP addresses only the developer
experience. As we discussed when we chatted, I think in fact it might help
address the AT end-user experience in that it explicitly flags broken
images as such -- as images that should have alternative text but that don't.

You obviously know much more than me about AT, but I would think it would be
useful for that information to be available to AT so that it can also be
exposed to end users in some way. That is, so that the end users actually
know there are images in the document that are not decorative but that do
not have alternative text that they should have. Users encountering such
documents and others reviewing such documents for accessibility compliance
could then, among other things, be able to alert the owners of those
documents that they have images that should be made accessible.

Also, this should go without saying, but improving the developer experience
can indirectly help end users as well. What I mean is, if you provide a
means for developers to separately find and fix instances of missing alt
text in markup they directly control, they are more likely to do that than
if they had no such means.

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

That's intentional I think. It's meant as a solution for this specific
issue. It may be that there are other elements with cases like this but so
far nobody has raised an issue for any of them. So the CP focuses on trying
to fix the issue at hand.

> The problem as I understand it is one of filtering error messages that a
> particular developer cannot affect change upon.

The problem is also the default behavior. As I understand the rationale
behind the use case: If developers are immediately presented with a large
number of errors for the same markup problem, they are less likely to go
through all those errors to find and fix the ones that they can. And they
will not necessarily take the time to go to the second step of using
whatever post-validation filtering mechanism a validator might provide.

If on the other hand the default behavior is to not show all the errors,
but to provide validator users with a clearly marked option to opt-in to
seeing all the errors, they may find that a lot more useful.

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

Some thought has been put into that and I think it's very likely the
validator.nu UI will eventually provide some user options for that. But
that still doesn't fix the problem of users getting more errors than they
want/expect by default.

> 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="">)

It doesn't. It's not intended to solve those problems. In hindsight maybe I
should not mention those at all. I brought them in just as examples to
contrast the current problem with. Maybe it's not helpful to have that
contrast here now in this discussion, if it distracts from the immediate
problem we're trying to solve.

> I would think that a more global approach to handling these error messages
> would be a worthy goal to shoot for,

I'm not sure such a global approach could be developed that did not
introduce more costs and additional problems. For one thing, I think a
global approach could end up being open to more wide abuse.

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

I'm not suggesting any such shopping list. I'm just suggesting we focus on
discussing the on specific case we've been discussing so far, and not deal
with whatever other similar problems may or may not exist with other elements.

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

This CP does not propose anything other than one additional new attribute
on the img element. It does not propose attributes for other elements, so
it would not cause the problem you describe.

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

See my comments above and what I tried to articulate when we talked earlier.

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

Yes, agreed.

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

OK but I hope you will also continue to hear me out (and others) when we
try to explain why this proposed new attribute is also worth considering.

> 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 don't agree about that. Yeah, it is in part focused on the developers,
because they are the ones using validator, and ad I validator developer, I
want to help them so that they can better help their users. I cannot help
their users directly myself. I can only do what I can to try to make my
application better for them so that they continue to use it and so that it
helps the find and fix the errors that are trying to find and fix.

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

I think it does do something to address the end-user problems of missing
alt text, for the reasons I've explained earlier. Among other things, it
makes it so that if an alt-less image has been placed in a document even
though it's known it may need alternative text, that image can be flagged
to make it clear that it's a broken image. I think it's useful to end users
to know they are viewing a document which is known to contain images for
which a generator was unable to provide required alternative text, as
opposed to images that may accidentally be lacking alternative text.

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

It's not an either-or situation. We can do both.

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

No it does not necessarily do that, as far as I can see. AT can deal with
these generator-unable-to-provide-required-alt images in a smarter way.

> How does this proposed solution manage that problem? Do you and others
> even see this as a remaining problem?

I think everybody who is following this issue agrees that's a problem.

> I have not seen or heard anything that makes me believe that the cost
> benefit of doing this improves the end user experience.

In this message I've tried outline how I think it can improve the end-user
experience.

> The question is, who is more important here, the developer or the end
> user?

That's not the question actually. They're both important and we need to
consider the needs of both. It's not a matter of deciding who is more
important and then going with just the simplest solution possible. There
are a complex set of benefits and costs that need to be evaluated. Reducing
it to just a simple decision about who's more important just discounts that.

> This proposal certainly seems to me to slant that answer in favor of the
> developer, at the expense of the end non-sighted user.

I don't think it's intended to do that and I don't think that necessarily
would be the net end result of it on aggregate. That's why it might be
beneficial to do an actual implementation of it the validator, give it a
try for a year or so, collect as much data as we can about whether it's
being used as expected and is helping or hurting, and then at the end of
the year re-evaluate it if needed.

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

Yeah, I hear you

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

I can't speak for others but I admit that the accessibility SMEs know what
you are talking about. For me personally, people like Steve Faulkner and
you who have spent time helping me understand the problems and understand
about how AT works and how browsers interact with it -- believe me, I
understand you know what you're talking about.

But I would hope that you understand that some of the rest of us have also
spent a lot of time thinking about some of these specific problems, and we
might also know a bit too. We're not dilettantes who strolled in from the
street yesterday with poorly considered ideas.

> and vague, general, "it's all kinds of bad" hand-waving statements
> such as "harming accessibility" have little traction:

I don't think I have resorted to that in this discussion or in others.

> 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 you already know I have great respect for that.

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

I agree with the Priority of Constituencies principle as stated in our
Design Principles document; the full text of which is:

  http://dev.w3.org/html5/html-design-principles/#priority-of-constituencies
  In case of conflict, consider users over authors over implementors over
  specifiers over theoretical purity. In other words costs or difficulties
  to the user should be given more weight than costs to authors; which in
  turn should be given more weight than costs to implementors; which should
  be given more weight than costs to authors of the spec itself, which
  should be given more weight than those proposing changes for theoretical
  reasons alone. Of course, it is preferred to make things better for
  multiple constituencies at once.

Notice that is talks about "giving more weight"; it doesn't say the needs
of users should absolutely always trump the needs of all other
constituencies. The word "weight" implies trying to find some balance among
the needs multiple constituencies. See the final sentence.

  --Mike

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

Received on Wednesday, 1 August 2012 12:44:27 UTC