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

Hi Mike,

On Tue, Aug 7, 2012 at 11:18 AM, Michael[tm] Smith <mike@w3.org> wrote:
> I completely agree with Chaals that what we are trying to do here amounts
> to social engineering.

Some social engineering definitions:

 "The practice of deceiving someone, either in person, over the phone,
or using a computer, with the express intent of breaching some level
of security either personal or professional. Social engineering
techniques are considered con games which are performed by con
artists. The targets of social engineering may never realize they have
been victimized."
http://idtheft.about.com/od/glossary/g/Social_Engineer.htm

The only deception in this case is hiding errors from authors. They
may never realize they have been victimized.

"What really is social engineering? We define  it as the act of
manipulating a person to accomplish goals that may or may not be in
the “target’s” best interest. This may include obtaining information,
gaining access, or getting the target to take certain action."
http://www.social-engineer.org/

I don't think that this definition is applicable except perhaps in the
sense that the img@relaxed proposal could provide a way to for
irresponsible vendors to manipulate  potential generator customers
into believing that an inferior product passes validation.

"What is social engineering? Social engineering is essentially the art
of gaining access to buildings, systems or data by exploiting human
psychology, rather than by breaking in or using technical hacking
techniques."
http://www.csoonline.com/article/514063/social-engineering-the-basics

I don't think that this definition is applicable.

> I think using a markup solution to try address do a social engineering
> problem is not always (or not usually, even) a good idea.

I totally agree, Mike.

> Basing decisions on what the validator has historically been is not a
> goal for me personally at least.

Backwards compatibility is fundamental to HTML5. Like it or not,
changing validator behavior that good authors and teachers have
depended on for years to pinpoint missing alt is a problem. I added a
use case section to the change proposal:
http://www.w3.org/html/wg/wiki/User:Lcarlson/ImgElement#Good_Authoring_Use_Cases

> The W3C validator has historically been in
> part a simple(minded) way for users to ultimately get a validation "pass"
> that they can advertise, and get a badge for. I don't want to encourage
> anybody to use the validator with the goal of getting a pass.

To me, that seems to be the aim of the img@relaxed proposal.

> I want it to
> be the best tool possible for helping them catch errors they actually want
> to be informed about, for things that they can actually fix themselves.

I do too, Mike.

> I
> don't want for the default behavior to be that is forces error messages on
> them for things that they can't fix, especially if the end result ends up
> being that somebody solves the problem by having a tool just generate
> alt="" or alt="image" for images that should have alt text but don't.

My proposal would provide for that scenario as wall as the senates I outlined.

>> Reversing that and dumbing it down to by default hide errors would have
>> repercussions.
>
> It's not a simple matter of "dumbing it down". Nobody is suggesting that's
> what we should do.

>From my perspective that would be the result of the img@relaxed proposal.

> I think everybody is in good faith trying to find a
> solution that ensures that machine-generated documents end up being more
> usable instead of less usable.

I think so too, Mike. We all have different perspectives on how to do
that. I agree that a hook that could be used by AT could be a useful
thing.

Best Regards,
Laura

-- 
Laura L. Carlson



On Tue, Aug 7, 2012 at 11:18 AM, Michael[tm] Smith <mike@w3.org> wrote:
> Laura Carlson <laura.lee.carlson@gmail.com>, 2012-08-07 10:53 -0500:
>
>> 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.
>
> I completely agree with Chaals that what we are trying to do here amounts
> to social engineering. Maybe "trick" is the wrong word, but I certainly
> understand what he meant by that.
>
> I think using a markup solution to try address do a social engineering
> problem is not always (or not usually, even) a good idea.
>
>> The validator has historically been a tool to help find and fix errors.
>
> Basing decisions on what the validator has historically been is not a
> goal for me personally at least. The W3C validator has historically been in
> part a simple(minded) way for users to ultimately get a validation "pass"
> that they can advertise, and get a badge for. I don't want to encourage
> anybody to use the validator with the goal of getting a pass. I want it to
> be the best tool possible for helping them catch errors they actually want
> to be informed about, for things that they can actually fix themselves. I
> don't want for the default behavior to be that is forces error messages on
> them for things that they can't fix, especially if the end result ends up
> being that somebody solves the problem by having a tool just generate
> alt="" or alt="image" for images that should have alt text but don't.
>
>> Reversing that and dumbing it down to by default hide errors would have
>> repercussions.
>
> It's not a simple matter of "dumbing it down". Nobody is suggesting that's
> what we should do. I think everybody is in good faith trying to find a
> solution that ensures that machine-generated documents end up being more
> usable instead of less usable.
>
>   --Mike
>
> --
> Michael[tm] Smith http://people.w3.org/mike

-- 
Laura L. Carlson

Received on Wednesday, 8 August 2012 17:30:38 UTC