RE: Working Group Decision on ISSUE-31 / ISSUE-80 validation survey

Aryeh,

Thank you for the honest if somewhat troubling and disappointing response. I 
would like to explore these points a bit further if I may:

(Note: this is a TL;DR response, but worth the read I hope)

Aryeh Gregor wrote:
>
> > Do content owners and developers
> > think that meeting an arbitrary validation check-point results in the
> best
> > user experience for their users?
>
> In many cases, yes.
>
> > If yes, why[?]
>
> Because some customers and users of web software judge it partly based
> on whether it validates.

Not wanting to be confrontational, is this statement based upon any kind of 
formal measurement or assessment, or rather via anecdotal comments and 
observations? I admit to personally being something of a 'validation 
hardliner' in the past (although softened my stance considerably when using 
valid HTML 4.01 + ARIA produced validation errors, but improved user 
outcomes - at that point I put "Users over > over > over Code Purity").

I also ask, because just recently Jonas Sicking stated:

 "A terrifyingly small percentage of the pages on the web pass a validator. 
The far vast majority of pages doesn't even nest their tags correctly. The 
sad truth is that while we can do what you suggest, it's not going to have a 
big effect because people simply doesn't consult validators to a large 
degree."
http://lists.w3.org/Archives/Public/public-html/2011Mar/0627.html


As an invested participant, I am now hearing conflicting commentaries from 
others involved in the discussion, so it would be useful if we all knew what 
the real status is/was: validation *does* matter, or *doesn't* matter. I 
pose this question to the larger Working Group as well.


> If software's HTML output doesn't validate,
> some percentage of users will hold that against it, and assume that it
> reflects some deficiency in the software (whether or not they actually
> understand the errors).  At least in the open-source world, there also
> tends to be social pressure among developers to conform to standards.

I am happy to see you pluralize "standards", as this is indeed an important 
point to consider.  Within the W3C, we currently have a Standard, WCAG 2.0 
(W3C Recommendation 11 December 2008) that specifically states:

 "1.1.1 Non-text Content: All non-text content that is presented to the user 
has a text alternative that serves the equivalent purpose, except for the 
situations listed below. (Level A)" - 
http://www.w3.org/TR/WCAG20/#text-equiv

Equally important, the US Federal Standard "Section 508" states:

 "§ 1194.22 Web-based intranet and internet information and applications.
  (a) A text equivalent for every non-text element shall be provided (e.g., 
via "alt", "longdesc", or in element content)."

Would it not then be fair to say that using a mechanism that seeks to defeat 
or obscure conformance to these Standards could also result in "... some 
percentage of users hold(ing) that against it, and assume that it reflects 
some deficiency in the software (whether or not they actually understand the 
errors)"?


>
> > Simply put, what is more important, a validation green-light badge,
> or an
> > inclusive user experience?
>
> In my experience as a web developer, only a tiny percentage of users
> of typical web applications use anything other than conventional
> browsers (desktop or mobile).  For typical commercial products,
> there's essentially no incentive to include disabled users in testing,
> planning, or QA, because the expense of accommodating them exceeds any
> likely RoI.

I wonder aloud if representatives of companies such as Microsoft, Apple, 
IBM, Oracle, etc. would concur with that statement. I wonder too how Google 
feels about this position today with regard to their already significant 
investment into Googledocs, and the recent problems they are facing there?

As some-one who has worked in the web-accessibility field for over a decade, 
I have often heard these types of claims. For sure, this was a claim that 
Target.com made early on in their legal woes, and yet, once the dust settled 
(and Target settled out of court) the final tally for that adventure was a 
settlement that made changes to their Web site (cost undisclosed, but 
generously I will suggest $1 million dollars - that surely must buy a lot of 
changes!) and further set aside *$6 million* for plaintiffs to share. 
Target's failure to include disabled users in testing, planning, or QA here 
surely must have had a significant impact on their ROI after the fact.

I have no doubt (having run into it more than once) that the concept of 
"risk management versus cost" is a very real business decision, but given 
that many of us already know that building web content/tools/applications 
that include accessibility from the get-go has significantly less financial 
impact than having to reverse engineer to an earlier code-point - loosing 
countless hours of invested work effort - to simply to fix what was at the 
time a minor problem; it would seem that the business case for getting it 
right the first time exists. And those after-the-fact costs can also be 
further inflated if/when further sums are applied to address plaintiffs.


> For non-commercial products like MediaWiki, developers
> are often volunteers who are mostly interested in their personal use
> of the software, or use by the users they come into contact with (who
> are overwhelmingly not disabled), and again they have little incentive
> to make more than the most basic accommodations.

Aryeh, again in my personal experience, when explaining what it is I do, 
even the most naïve and uninformed person instantly understands that images 
that cannot be seen (by blind users - and we don't need to discuss all the 
other scenarios, blind users here suffice) require textual alternatives - it 
cannot get more basic than that.


> In all cases,
> developers would probably be willing to make simple changes if they
> thought it would help disabled users, but only if they didn't require
> a lot of resources or effort.

I agree. It clearly is primarily an educational effort, as you likely know 
that providing a means to associate alternative text to images inside of 
MediWiki's data base would be rather trivial to implement. It's not the 
software where the problem lies, it's the authors, who through unwillingness 
or lack-of-awareness produce incomplete content when they omit textual 
alternatives with their images.

>
> For instance, as a MediaWiki developer, I could change the default alt
> text produced for user-provided images from the empty string to the
> filename or something else anytime I felt like it in about five
> minutes, and the change would most likely take effect on Wikipedia
> within a few months.

As some-one who struggles with the 'educational' piece almost daily (the 
largest part of my day-to-day job at Stanford is focused on author training 
and awareness), I have come to very much appreciate that getting good 
outcomes is closely tied to good work-flow processes. If, (for example), I 
could not upload an image to MediWiki without providing a textual 
alternative to that image, then what I would have would be a work-flow that 
makes doing the right thing easier, and the wrong thing harder.  Will it be 
gamed and ignored? Sometimes, yes. But would it also help authors do the 
right thing without stressing too much - I believe so, and I think it is 
fair to say so would many others who do what I do - we've seen these types 
of processes achieve positive outcomes in the past.

And while I have to admit that creating this type of work-flow inside of 
MediaWiki is likely significantly harder than adding a "generator" string to 
the tool and walking away secure in the knowledge that pages will now 
validate, it just feels and appears oh-so-wrong to do. It kind of reminds me 
of drivers with diplomatic license plates parking in handicap spots with 
disregard, because they are exempt from parking tickets.

Is that really what the collective *we* want from the web? Please say no.

> But I simply have not been approached by actual
> blind users who have requested such a change, to the best of my
> recollection.  So I don't know if making a change would actually be
> useful, or if so, what change I should make.

If you really wanted emails from blind users, I could probably manage to 
have your inbox explode with those requests - I am pretty good at shaking 
the trees when I need to. I won't do that however, as spamming you would be 
counter-productive, and I really want to not be counter-productive here.

However your statement is reminiscent of arguments made in the days before 
ADA, when libraries argued that no wheelchair users had ever requested wider 
bookshelf aisles, so why widen the aisles? The response however was, had the 
Libraries ever asked? Had they ever considered whether this was a priority 
or not?

For the most part MediaWiki is a pretty good tool. But have you ever asked 
end users, including users with disabilities, how you could make it better? 
I appreciate that it is an open-source tool, and that it is mostly volunteer 
developed, but surely you have goals and road-maps outlining where you want 
to improve things. I have had some experience with other larger-scale, 
community-developed OS Tools (Drupal) and there they had a process and 
commitment to address accessibility issues.

As to what kind of change to make? I offered one suggestion, but why not ask 
blind users what they think? Or mainstream, "I just want it to work" users? 
I would be happy to help you conduct a managed survey of those kinds of 
questions, if you and the MediaWiki team were truly interested in knowing 
those answers - I can access a decent pool of either type of user. Ping me 
off-line, and I will make that happen for you - that's a promise you can 
take to the bank!

>
> The current HTML5 spec says we should either use an empty string or
> just omit the alt attribute, but I have no reason to believe that was
> based on actual analysis of screenreaders in practice rather than
> theoretical principles.

In practice today, images with null alt values are effectively silenced. 
(Actually, the screen reader essentially "reads" *null*, thus nothing is 
announced). In the absence of alt text (and the alt attribute) screen 
readers attempt to do something, and so announce the file name, reading 
aloud such gems as "one seven nine zero five five four seven one dot 
jay-peg" - so when the 'current HTML spec" says to just omit the alt 
attribute you are causing real grief and pain to screen reader users. Don't 
do it!


> I took a brief look at WCAG 2.0 just now, but
> it seems to just completely ignore my use-case (user-uploaded image,
> no idea how it's being used).  I looked at "HTML5: Techniques for
> providing useful text alternatives", but it just says I have to
> provide a caption instead, again ignoring my use-case.

So looking at this situation and responding would almost double the size of 
this already too-long response. I would be happy to explore it further with 
you off-list, but in short it would likely require a 2-step solution: step 1 
when images are upload, and step 2 when existing images in the db are used 
in other host pages.

>
> So I'm left with only one standard that even addresses my (extremely
> common) situation, and we appear to currently follow it.  If I really
> cared, I could go out of my way to track down blind MediaWiki users
> and ask them what the best behavior would be, maybe providing them
> with mockup pages.  But I have lots of other things to do, and I've
> received no actual user complaints, so I'm not going to.  It just is
> not worth the effort for me.

So I won't read malice into that last statement, as I am sure that you did 
not mean it that way; it would be "worth the effort" if you had better data 
and understanding of the requirements, and non-sighted users assisting in 
perhaps both code development and feedback. If I have perhaps better 
characterized the situation, then I would be happy to try and match those 
needs with bodies - I cannot promise that I will succeed, but I would try 
very hard to make it happen.

Meanwhile, we currently have in the recent decision, a 'cheat' mechanism, a 
'diplomatic license plate' as it were (the generator string) to deliberately 
avoid making our web content better, by placing the (questionable) value of 
'validation' over better tools. I think we need to really ask ourselves if 
this is truly what we want?

JF

Received on Friday, 22 April 2011 02:00:21 UTC