Re: Audience Based Validator User Interface (ISSUE-206)

Hi Chaals,

> This really boils down to social engineering - we're trying to trick people
> into doing the right thing, and failing that the least harmful thing we an
> get them to do.

Trickery should not be our aim. The validator has historically been a
tool to help find and fix errors. Reversing that and dumbing it down
to by default hide errors would have repercussions.

Dmitry Fadeyev had an interesting post today [1]. In it he said, "What
the audience wants is not necessarily the same thing that they should
be given. Today's businesses don't seem to realize this, or, more
likely, choose to ignore this for their own benefit...your choice
whether that judgement be based on your experience, your knowledge,
and your reason, or on the instinct of the masses. What? You think
your judgement is to raise conversion rates for your own ends? So be
it, but that judgement will also be reflected back at you, being the
measure of you as a designer or as a journalist, and in turn through
the world that you help create. It's like saving money by buying cheap
materials to build a house with, not realizing that you're the one who
will be living in that house."

Best Regards,
Laura

[1] http://fadeyev.net/2012/08/06/judge/

On Mon, Aug 6, 2012 at 6:48 AM, Chaals McCathieNevile <w3b@chaals.com> wrote:
> On Mon, 06 Aug 2012 13:44:49 +0500, Steve Faulkner
> <faulkner.steve@gmail.com> wrote:
>
>> Hi Ben,this would make more sense to me as it reflects reality,
>>
>> but as one tool vendor has commented, this would appear to entail all
>> HTML5 authoring tools including some form of built in >conformance checking.
>
> Yep. Conformance was an accessibility requirement when ATAG 1.0 was
> produced. It is not the highest one - since it may be that better
> accessibility can be provided by breaking it. Nonetheless, that meant that
> there was an effective requirement to provide conformance checking in
> authoring tools if they were going to be truly good at producing accessible
> content.
>
> http://www.w3.org/TR/2000/REC-ATAG10-20000203/atag10.html#check-ensure-published-DTD
> (Ensure the tool produces conformant markup). Priority 1 - the tools should
> get this right by default. HTML5 makes this easier in some important cases
> mentioned in this thread.
>
> http://www.w3.org/TR/2000/REC-ATAG10-20000203/atag10.html#check-no-default-alt
> (do not auto-add e.g. alt=""). Priority 1. So Adobe is doing the right thing
> here. According to Steve's testing, so is Microsoft. Given that this stuff
> is over a decade old, that's not so surprising.
>
> http://www.w3.org/TR/2000/REC-ATAG10-20000203/atag10.html#check-notify-changes
> (allow the author to preserve unrecognised (e.g. invalid) markup). Priority
> 2 - you really should do this...
>
> There are multiple libraries available for checking XML-based formats (e.g.
> XHTML which was the expected main format at the time), and there are
> libraries for HTML5. Henri is very smart, but presumably he isn't the sole
> person in the universe capable of writing tests for the machine-checkable
> aspects of HTML5 conformance...
>
> Nothing forces tools to be perfect, but if they want to do so, surely they
> should actually provide the best possible service. As I understand it,
> Henri's objection to the meta generator stuff is because it stops him from
> doing so. The issue we seem to be dealing with here is that it is possible
> to create a 'pathological' test and thereby show that a tool is bad.
>
> Maybe it is true that we should cope with this case. Interested parties I
> can see:
>  + validator producers (who want to make their users happy)
>  + authoring tool producers (who are worried by this test - apparently
> neither Microsoft nor Adobe are in practise)
>  + authors (who will do anything, even break conformance with HTML, to look
> like they are conforming).
>
> I'm unconvinced. Henri asked if people disbelieved the scenario posited as a
> problem. I by and large (there is an 80/20 split here because there are a
> lot of tools) disbelieve the scenario that tools are worried about
> validation of content they produce. The scenario of authors tweaking their
> content is less clear - and there are more authors so more scope for
> variation. But again I think it isn't so hard to get the majority of authors
> who care about validation to do The Right Thing™. And that is to leave out
> alt if they don't put a *valid* value - i.e. one relevant to the image in
> question.
>
> This really boils down to social engineering - we're trying to trick people
> into doing the right thing, and failing that the least harmful thing we an
> get them to do. Which probably explains why smart people disagree on the
> best approach (it is not even entirely clear that we agree on how to order
> things that are not perfect in terms of relative badness).
>
> In terms of finding consensus, I could probably live with the proposal for
> some kind of marker. I would object to it being a magic value for alt, which
> effectively leaves it as an attribute. (But what happens in the compound
> image case?) I also don't think there is much point in adding a huge long
> attribute name just to punish people who do a bad job. We already know they
> do a bad job, and making it hard for them to get anything right seems
> unlikely to encourage them to at least choose the "right" path.
>
> Cheers
>
> Chaals


-- 
Laura L. Carlson

Received on Tuesday, 7 August 2012 15:54:26 UTC