W3C home > Mailing lists > Public > public-usable-authentication@w3.org > September 2008

Re: [WSC-UI LC] approve with comments

From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Tue, 23 Sep 2008 14:00:11 -0400
To: Al Gilman <Alfred.S.Gilman@ieee.org>
Cc: public-usable-authentication@w3.org, wai-liaison@w3.org, Janina Sajka <janina@rednote.net>, Kenny Johar <kennyjohar@gmail.com>
Message-ID: <tslljxizqs4.fsf@mit.edu>

>>>>> "Al" == Al Gilman <Alfred.S.Gilman@ieee.org> writes:
    Al> You asked us to help you respond to a comment you received
    Al> from Sam Hartmans, with accessibility reasoning.

    Al> http://lists.w3.org/Archives/Public/public-usable-authentication/
    Al> 2008Aug/0003.html

    Al> Kenny Johar looked at this and wants clarification from Sam
    Al> before responding.

What do you want clarification on?

    Al> Janina Sajka made the following good point:

    Al> The sonicon for change in "security sensitivity" needs to be

I'm not familiar with sonicon as a term used by any real world products, but I can get the idea.

    Al> timely.  But what defines timely is not the visual display but
    Al> the change in the severity or sensitivity of potential system
    Al> responses to potentially-erroneous user input.  

I strongly disagree with your characterization of the security
situation in terms of user input.  User input is one factor.  However,
how much the user should trust the contents of the page is as critical
to what the WSC user interface guidelines are doing as input.

The comment about input aside, I agree with this.  Note that
accessibility products targeted at the blind typically have a well
defined procedure they go through for each new web page:

* They voice some introductory information including the title
* Several of them include some detail about navigation information
* Often they start reading the page

It's before they start reading the page that I'd expect the
accessibility product to describe security indicators.  Currently,
none of the products for major OSes seem to do this.

There is also the case where some web page change (Javascript or the
like) causes the security state to change by incorporating new
resources etc.  Typically this would involve introducing new risks,
redirecting the page, etc.  I agree that when that increased exposure
happens you would expect accessibility software to indicate the change
promptly.

    Al> So what you
    Al> should do is define (in abstract terms) the event as the
    Al> change in input exposure to risk or hazard.  Then tie prompt
    Al> announcement of this in visual and auditory media directly to
    Al> that state change, not daisy-chain the timing of one off the
    Al> other. 

I agree.

    Al> Both the auditory and visual displays need to be prompt
    Al> in announcing elevated-risk states.  Not that they need to be
    Al> strictly aligned in start time.  Where possible the start-time
    Al> alignment should be achieved as well.

I disagree with the last sentence.  I think that it is far more
important for an interface to be self-consistent and trying to get
start-time alignment will increase implementation cost of the auditory
interface in the accessibility case and will decrease its utility to
its target market.
Received on Tuesday, 23 September 2008 18:00:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:15 GMT