Re: several messages about alt

I think I understand this, but not sure.

There is a difference between checking one's HTML syntax is valid, vs
evaluating its accessibility (or any other value-based quality
measure). You're advocating keeping these separate. I can see the gulf
between the two.

Where does "conformance" fit in on the scale?


On Sun, Apr 13, 2008 at 6:55 PM, Henri Sivonen <hsivonen@iki.fi> wrote:
>
>  First, why do I even care to touch this rathole topic? It affects directly
> how the product I develop is expected to behave, and that affects its
> relationship with its users.
>
>  Here's how I see this discussion:
>
>  There is no law of physics or a fundamental result of computer science that
> prevented computers from pushing pixels around without pushing around a
> string at the same time. One group of people (the html4all folks) makes a
> value judgement that people using computers should make computers push
> around a string when they push around pixels in order to benefit a second
> group of people (the blind). A third group of people will make a value
> judgement that pushing pixels around without a string is valuable as such
> and they don't provide the string as having to provide a string as well
> would effectively make their use case infeasible (for example, people with
> camera phones with one-button photo taking and immediate uploading to a
> photo hosting service). A fourth group of people (developers of photo
> hosting services) will write software that the third group of people will
> use.
>
>  This fourth group--not the third group--are potential users of software I
> develop: an HTML5 validator. A part of this fourth group consists of
> software engineers who will
>   1) write software that is primarily meant for pushing pixels onto the Web
> (no matter how you try to spin it, in the real world, pushing the pixels to
> the Web is the primary function--getting the alt text out there is not the
> primary function)
>   2) want (either directly themselves or as a client requirement) the output
> of their software to be valid HTML (whatever that means)
>   3) realize that there's no fundamental computer science barrier to pushing
> around pixels without an accompanying string (hence the string can be faked
> to accomplish #1 and #2 simultaneously)
>
>  The first group of people wants, based on their value judgment, to
> establish a social norm onto the third group of people against the value
> judgment of this third group. This is a social problem. The norm is supposed
> to benefit the second group of people: the blind. Thus, any rational measure
> of the goodness of the policy should involve measuring the actual benefit to
> this second group.
>
>  Now, does the first group take their social norm directly to the people
> whose behavior they want to modify? No.
>
>  Instead, they want to masquerade the social norm as a technical norm, to
> use the PFWG as a proxy that tells the HTML WG what to do, so that the HTML
> WG may use the HTML 5 spec as a proxy for influencing the behavior HTML5
> validators, so that HTML5 validators are turned into vehicles of advocacy
> against the fourth group (developers) in the hope that they turn their
> products into vehicles of advocacy that finally reach the people that the
> first group wants to impose their social norm on.
>
>  I think that in this process, the relationship between the product I
> develop and its users is harmed, because the product  then is no longer a
> tool working for its users but a vehicle of advocacy for someone else. This
> is one reason why I care. Furthermore, I think complaining about missing alt
> to developers whose software *simply doesn't have that data* because the
> third group of people didn't provide it causes developers to either ignore
> the validator (not what I want) or faking the data they don't have (bad for
> the supposed beneficiaries of the policy).
>
>  I even agree that it would be nice if all photos had alternative text. But
> I don't think it is realistic, and I don't want to internalize the fallout
> that the first group externalizes by making the product I develop part of a
> long proxy chain instead of taking their issue directly to the people they
> want to influence (the people with camera phones in this example).
>
>  Now, does the policy benefit the intended beneficiaries? It is clear that
> the policy will lead to information loss or bogus information in a
> non-trivial proportion of cases. This means that user agents have less
> information to work with to benefit users. The harm part is obvious on the
> surface given what we know about the consequences of faking data when it is
> missing instead of signaling that it is missing. (Consider the examples
> Julian gave:
>  http://lists.w3.org/Archives/Public/public-html/2008Apr/0314.html ) If the
> harm in this case defies the obvious, I think the obvious needs to be proven
> wrong by research. Furthermore, the alleged benefits of the policy are
> speculative--that the policy of requiring alt syntactically would make more
> people supply useful alt text than telling people that a good alt text is
> needed for accessibility. With the harm side obvious and the benefit side
> speculative, I think the policy shouldn't be adopted without empirical
> research showing that the benefit exceeds the harm as perceived by the
> supposed beneficiaries. If research shows that there indeed would be a net
> benefit for the blind, then we can weigh if that net benefit is so great
> that it justifies collateral damage (e.g. turning some potential users away
> from validators).
>
>  As for "sending a strong message" while actually not benefitting the
> supposed beneficiaries, I have no interest in becoming (through the product
> I develop) a stooge for such a policy. This is another reason I care.
> Sending a strong message doesn't necessarily translate into better
> accessibility. Consider:
>
> http://www.nytimes.com/2008/01/20/magazine/20wwln-freak-t.html?_r=1&ex=1358485200&en=0d05099c03c97375&ei=5090&partner=rssuserland&emc=rss&pagewanted=all&oref=slogin
>
>  On Apr 11, 2008, at 13:08, Charles McCathieNevile wrote:
>
> > On Fri, 11 Apr 2008 11:29:20 +0200, Henri Sivonen <hsivonen@iki.fi> wrote:
> >
> > > Saying that such products should be
> > > programmed to output invalid HTML isn't a viable answer, either.
> > >
> >
> > Why not? Almost *every* tool I know of that produces HTML produces invalid
> > HTML, so I am not sure how you determine that there is some existential
> > reason why this cannot happen.
> >
>
>  We are talking about defining what's valid. The validity definition doesn't
> matter for people who don't even want the tools they write to output valid
> HTML. Therefore, it is only relevant to consider people who might care about
> the validity of the output of their products.
>
>  On Apr 11, 2008, at 15:05, Steven Faulkner wrote:
>
> > Two images without explicitly associated text alternatives.
> > 1 is an image is decorative that the author has accidently left off
> > the alt, the other is "critical content" that the author could not
> > provide an alt for whatever reason
> > 1 can be safely ignored, the other should be brought to the attention
> > of the user.
> >
> > <img src="abc.jpg">
> >
> > <img src="xyz.jpg">
> >
> > How is Assistive Technology  supposed to reliably determine this?
> > Given that these two images could be the same, but their meaning
> > differ widely depending on the intent of the author in regards to
> > their use.
> >
>
>  That question is a red herring. The right question is: What do you expect a
> content management system to do when its user uploaded an image but did not
> provide alternative text? And the follow-up: How is your answer better that
> letting the CMS signal to the UA that it doesn't have alternative text? (The
> simplest definition for such signaling is the omission of the alt
> attribute.)
>
>  On Apr 11, 2008, at 20:34, Dave Singer wrote:
>
> > I gave an anecdote before about an installer program that insisted on text
> strings to describe optional installs.  Many, many packages came configured
> offering, say "the frotz option" and if I asked for the "alt" I would get
> the text "this installs the frotz option".  If the installer *knew* that
> there was no explanation, it might be able to say "this installs a
> background process with root privilege, and a plug-in to the mail program"
> and I might be a little more informed.
> >
>
>  Indeed. A software developer with an output spec and insufficient input
> where the input can satisfy the main objective of his/her software *will*
> fake the missing data to match the output spec as far a computer can tell.
> That's how software developers behave.
>
>  Here's my earlier example:
>  "For example, if you are a kernel developer and you are copying files
>  from a file system that doesn't record the creation dates of files to
>  another file system that insists that every file *must* have a
>  creation date, you don't tell your boss/customers/whatever that you
>  can't copy the files. Instead, you fake the creation date (the
>  current time from the clock, the start of the epoch, whatever)."
>
>
> > Similarly, a web agent given an image with no alt might be able to
> indicate the size of the picture, and there is plenty of evidence to suggest
> that in time it could do image analysis and work out that there is a person,
> it's a landscape, and so on.  If the alt text is provided but worthless, it
> would obscure this capability.
> >
>
>
>  Indeed.
>
>  On Apr 11, 2008, at 23:07, Matt Morgan-May wrote:
>
> > We know from over 10 years of experience that authors are going to lie.
> >
>
>  Does inducing authors to lie benefit the stated beneficiaries of your
> policy?
>
>
> > You cannot turn one of the most common validity and accessibility failures
> > on its head simply because an empty alt attribute is unattractive.
> >
>
>  The empty string as the value and the absence of the attribute signal
> different things. Making both cases the same is information loss.
>
>  On Apr 11, 2008, at 23:15, John Foliot wrote:
>
> > I need
> > only quote one of the HTML5 Working Groups' personal blogs to illustrate
> > this fear:
> >
> >        "I am currently following HTML5 (omitting alt) as it wasn't really
> > clear to me what would be a better solution given the single constrain I
> > have: not finding it necessary to provide replacement text for all those
> > images." (http://annevankesteren.nl/2007/09/alt) - Here Anne did not "find
> > it necessary" - not that he could not, nor that the image was an Ink blot
> > test that providing alternative text to would invalidate (the two
> scenarios
> > suggested in the draft spec), but simply that he did not find it
> necessary.
> > The fear is very real!
> >
>
>  Suppose Anne hadn't written his CMS himself and I'm selling Anne a CMS that
> I develop. What should I program the system to do when Anne doesn't supply
> alternative text? (Also suppose that I still want to extract a licensing or
> consulting fee from him.)
>
>
> > Henri Sivonen wrote:
> >
> > > A piece of software gets images from somewhere and puts them
> > > automatically out on the Web. What should the developer of that piece
> > > of software program it to do when an image arrives from whatever pipe
> > > they arrive from without alternative text? How do you require a
> > > program to emit something it simply doesn't have without faking it
> > > with junk?
> > >
> >
> > If sewage passes through a conduit, should the conduit do nothing, or at
> the
> > very least attempt to filter out the larger pieces of sewage?
> >
>
>  What incentive does the developer of the conduit have to block what you
> call sewage? Is that incentive stronger than whatever incentive there is to
> let the "sewage" pass through?
>
>
> > Henri S. used the word "fake", but that is undefined.  This once again
> > points to the need (IMHO) for one or more reserved values that user agents
> > can "standardize" on (remember, this *IS* about standards) that address
> > possible scenarios when content authors fail to, or cannot, provide
> > appropriate alternative text.  "_notsupplied"
> >
>
>  How is alt='_notsupplied' better than defining the absence of the attribute
> to mean exactly what you would define alt='_notsupplied' to mean?
>
>
> > and "_decorative" are two that
> > instantly come to mind.
> >
>
>  How is alt='_decorative' better than defining alt='' to mean exactly what
> you would define alt='_decorative' to mean?
>
>
> > "_notsupplied" has the added benefit
> > (IMHO) of also applying a subtle but real social pressure on content
> > contributors to do something, but if they choose to ignore that pressure,
> > then the default of "_notsupplied" still allows compliancy, whilst still
> > retaining the mandated need for alt values for all non-textual content.
> >
>
>  Ah. This is how it is supposed to be better.
>
>  Thus you want someone other than you to apply the pressure to someone other
> than whom you seek to apply the pressure to. And you want to do it by making
> the syntax cruftier.
>
>  Frankly, I think you are now at the point where you are vehemently clinging
> onto a bad policy and amending it with worse and worse additional rules in
> order to avoid re-examining whether the need of the amendments should be
> taken as an indication that the base policy needs adjustment. I don't know a
> name for this phenomenon, but others shouldn't play along to save you from
> re-examining the policy.
>
>  On Apr 11, 2008, at 23:18, Bonner, Matt (IPG) wrote:
>
> > Are there any usability studies or tests done by screen
> > reader software companies that could help resolve this
> > debate?
> >
>
>  Excellent point!
>
>  On Apr 11, 2008, at 23:54, Katie Haritos-Shea wrote:
>
> > People will continue to commit crimes and break the law........but it that
> a reason not to have them?
> >
>
>
>  First, HTML 5 is not law, and I don't want an HTML5 validator to have
> anything to do with legal proceedings.
>
>  As for making laws that people break, it is corrosive (to use Lessig's
> vocabulary) to society to have laws that normal people are in violation of
> in their daily lives. This is why prohibition and laws like the DMCA/EUCD
> are bad as they turn normal people into law-breakers and makes them really
> cynical about law in general thereby devaluing laws in general.
>
>  Likewise, a validity rule that normal Web developers would game in their
> daily development activities devalues validator messages.
>
>  On Apr 12, 2008, at 01:24, Matt Morgan-May wrote:
>
> > If you allow alt to become optional in order to satisfy user-uploaded
> > content requirements, then accessibility evaluation and repair tools have
> no
> > way of knowing whether you omitted it purposely, or out of ignorance.
> >
>
>  We are talking about what HTML5 validators are to say. We aren't talking
> about accessibility evaluation tools. WCAG is free to be normative about
> those.
>
>  However, I think accessibility evaluation tools make people write for the
> tools instead writing for accessibility. That's why accessibility should be
> evaluated by people.
>
>  An HTML5 validator isn't an accessibility evaluation tool--or at least I
> think it shouldn't be. An HTML5 validator is just a spell checker for the
> benefit of markup writers so that they can identify typos and typo-like
> mistakes instead of having to figure out why a counter-intuitive error
> handling mechanism kicks in when they test in browsers. A spell checker
> doesn't tell you if your fiction writing is entertaining or non-fiction
> actually factual. Those are different evaluation axes.
>
>
> > You can define the exception case that warrants a missing alt attribute as
> > narrowly as you like in the spec, but you know as well as I do that people
> > aren't going to read the spec for guidance at that level, if they read it
> at
> > all.
> >
>
>  FWIW, Validator.nu doesn't flag PUA characters as errors even though they
> are prohibited most of the time, since there's also a narrow legitimate use.
> It does give a one-time warning, though.
>
>
> > Further, I think that while user-generated content is a popular category
> of
> > web content, it's just one such category, and since there are any number
> of
> > other kinds of content for which no such exception should exist, there's
> no
> > justification to turn the rules around on alt solely for the benefit of
> > those sites.
> >
>
>  The syntax rules need to be lax enough for all kinds of sites to be able to
> comply. If all sites can't be accessible, too, then accessibility and
> syntactic correctness are different evaluation axes.
>
>  On Apr 13, 2008, at 03:35, Leif Halvard Silli wrote:
>
> > In this regard, I proposed [1] - as an replacement for the current
> "WYSIWYG made" stamp - a new "unready" stamp, which all authors - couples,
> and blind - and all editing tools - could use, when they need to offer HTML
> which they consider technically unready.
> >
>
>  Alternatively, we could call "unready" valid HTML5 and "better than
> unready" valid HTML5 with WCAG compliance. We don't have to conflate
> accessibility evaluation with the syntactic correctness.
>
>  --
>  Henri Sivonen
>  hsivonen@iki.fi
>  http://hsivonen.iki.fi/
>
>
>
>
>

Received on Sunday, 13 April 2008 11:26:01 UTC