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

Michael[tm] Smith wrote:
> 
> Some specific parts of the CP that lead me to express support for it:
> 
> 1. I agree with the statement in the CP which asserts that the general
> use
> case this CP is attempting to address is an important use case to
> address.
> The use case is valid, and I think we should all work together to try
> to
> find out a way to address it that we can all agree on.

The change proposal states:
"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 "harming accessibility" phrase has been repeatedly used by many - but
how exactly does this harm manifest?  We (at least *I*) would love some real
world examples. (I note with some irony that I've never heard a web
accessibility professional ever use that term, it is always other engineers
who state it - not out of malice or even ignorance, but simply because they
have been told this repeatedly and so they grow to accept it as a fact: Bad
is bad)

Here's what I know: if a "template" for an image is/was created for a
photo-sharing site that allowed for a dynamically inserted URI of the image
file (mikesmith.jpg) and a corresponding alternative text (Photo of Mike
Smith), then the markup would look something like this pseudo code:

  <img src="%photo%" alt="%alt-text%">

Now, if the database has an image, but not a related alt-text, then the
output of the template would be:
  
  <img src="mikesmith.jpg" alt="">

Yes, this is hardly *useful* to the non-sighted user, but harm? It harms the
photo-owner as much as the end user, and that "harm" is pretty benign to
start with.  However, at the very least the alt="" has the net effect of
also mapping to role="presentation" and thus silencing screen readers. 

However, depending on the screen reader and user-settings, the following
code sample *WOULD* cause harm:

  <img src="567dfg.jpg">

...as the screen reader will begin to apply some heuristics to try and
provide a useful, unique distinguisher for that image, and will end up
voicing "image: five six seven dee eff gee dot jay-peg". (This is default
behavior for JAWS today) This is why WCAG 2 continues to recommend that at a
minimum authors insert alt="" for all images (although it presumes that
images with a null alt string are decorative or have no value)
http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H67 

***

Here's Some Real Harm:

How does changing the above to <img src="567dfg.jpg" relaxed=""> improve the
end experience for the non-sighed user? 

It silences the Validator from advising that there is actually some real
harm being perpetrated, and leaves the non-sighted user at the short end of
the stick. Whatever happened to Users over Authors over Implementers over
Code Purity?

***

More than 3 years ago, the Accessibility Task force discussed this "problem"
and put forth a number of possible solutions to the perceived "problem" that
Flickr has: http://www.w3.org/2009/06/Text-Alternatives-in-HTML5.html

(And for what it's worth, it would be a better step forward to encourage
Flickr to allow users to supply @alt text when they so desire - which we
cannot do today - rather than seeking a "Get Out Of Jail Free" card).

What I fail to understand is why this: <img src="image.jpg" relaxed=""> is
somehow OK, whilst <img src="" alt="Photo of Mike Smith" relaxed=""> would
somehow still generate an error message? 

This to me is the crux of the discussion: for many users <img src=""> is
useless and results in a "broken" user experience, while for other users
<img src="image.png"> is also a broken user experience. Why-ever would a
Validator place one user over the other in importance? Because that is one
of the outcomes of this proposal, whether anyone else is ready to admit it
or not.


> This CP seems to
> me
> to be the most viable CP for this issue so far that we actually have a
> chance of getting agreement on.

Nope, not from me - I will be objecting to this at WBS Survey time.


> 
> 2. The observations in this CP about the need for "granular relaxation"
> for
> this use case are particularly important and need to be considered; I
> believe in particular the following statement makes an important point:
> 
>   "The markup of large Web applications is typically partly generated
> from
>   code and partly sourced from hand-authored HTML templates. With an
>   all-or-nothing mechanism, there's no way to relax the conformance
>   criteria for only the portions of the document corresponding to
>   user-generated content, while retaining strict requirements on the
>   portions of markup from the hand-authored HTML templates.

It matters not whether the code is hand authored in note-pad, or strung
together using nothing but #! and javascript, it is the responsibility of
the final output to meet conformance requirements, and one of those
conformance requirements - always - is to ensure that non-textual content
has at a minimum an accessible name and ideally an accessible description. 

There are multiple techniques to achieve these goals, and if *that* goal is
not met, then yes, a conformance error should be thrown.  It's really that
simple.  Looking for a magic bean to insert somewhere in the overall
production process misses the larger requirement - it defers the "Pain" from
the engineer to the author, or more likely to the end user. 

To the point, if Flickr does nothing to provide an accessible name for each
unique image, then Flickr *IS* failing, and no attribute or other magic
talisman will change that fact.


> 
> 3. Related to #2, I agree with the following assertion about the
> positive
> effects of this proposed change:
> 
>   "We enable engineers of large Web applications to catch markup errors
> that
>   they can do something about, without bothering them about markup
> errors
>   they can't do anything about."
> 
> That's something which is of real-world concern to validator
> developers.

Then the solution is to modify the Validator so that certain errors can be
silenced at the reporting level, not the code level. If the problem is "too
many errors being reported", then either a) fix the errors, or b) modify the
reporting tool to be less aggressive. But be perfectly clear: if you silence
the Validator from advising when an image has missing alt text, then you
will also miss out on errors that can be reported and resolved by the
'system' (be that generated code or hand authored content).

The last thing we need to do however is to shift the silencing mechanism to
the code-base of HTML - that is a very wrong solution IMHO.


> When users attempt to validate documents and end up getting a large
> amount
> of error messages about potential problems which they have no means to
> correct directly themselves, we risk having them just give up and quit
> using the validator altogether. This is of very practical concern for
> anybody maintaining a validator: You want users to keep using your
> validator
> and to have the validator match their real-world needs as much as
> possible.


In the Real World non-sighted users need to know something about visual
assets on a page. 

[pause and think on that]

Telling them that it is "image: five six seven dee eff gee dot jay-peg" is
not the solution, and if we fail to tell authors and engineers that they are
propagating a real problem, then we, and the Validators, are failing *their*
core constituents (which is clearly not end-users).


> 
> Anyway, in summary and as I mentioned in #1, I think this CP provides a
> resolution that we have a good chance of getting agreement on among the
> people in the group who so far have been unable to reach agreement on
> it.
> So I hope everybody involved can consider it very carefully, with an
> open
> mind.  It's not a perfect solution for the problem. We're not going to
> find
> a perfect solution. But this is the best solution I've seen so far.

Mike, I appreciate that this looks useful to you as a Validator developer,
but from the perspective of the blind end user, it does nothing for them
positively, and may in fact lead to a degradation of usable web content over
time: one thing we have no control over is *HOW* this new magic bean would
be used, and I fear the over-use and abuse of @relaxed could become a
problem down the road.

(As a random observation to Ted of this proposal: it is also unclear exactly
how the Boolean @relaxed="" selector would work: are the values True/False,
something else, or does it follow the Boolean pattern of other HTML5
attributes like @hidden, where its presence constitutes true, while its
absence implies false?)

JF

Received on Wednesday, 1 August 2012 02:45:47 UTC