Re: Comments/questions about checkpoint 9.3 (configuration of eventnotification)

Charles McCathieNevile wrote:
> 
> Tis is not quite true - we can rewquire that the windows be left unlocked if
> that is a requirement. For an AT that builds an off-screen model, that may be
> an issue, as I noted recently with my emacspeak example. Or if it is not a
> requirement then we should make it clear that we are going down a particular
> path, and why.

I believe we have clearly chosen to move away from the offscreen
model world, and our DOM and other standard API requirements state
so clearly. Do we need to say more?

In the 7 July Guidelines (and other versions) we say at the end of 1.2: 

<BLOCKQUOTE>
So that desktop browsers can make information available 
to assistive technologies, they must communicate through
standard interfaces. An architecture that makes possible 
programmatic access to content and the user interface will
benefit assistive technologies, scripting tools, and 
automated test engines. It will also promote software 
modularity and reuse.
</BLOCKQUOTE>

Furthermore, we say in section 1.7 (Conformance:

<BLOCKQUOTE>
Note: These guidelines aim to make conforming user agents
accessible. This includes the accessibility of the user 
agent's user interface in addition to the accessibility 
of Web content. When used in conjunction with assistive 
technology, conforming user agents are expected to be
accessible to most users with disabilities; in some cases,
accessibility is "completed" by the use of an assistive technology.
Some user agents may not conform to these guidelines but still be
accessible to some users with disabilities.
By following the principles of this document,
developers of all user agents (not just conforming user
agents) should improve the accessibility of their products.
</BLOCKQUOTE>

Should we state that we expect ATs to implement the
standard interfaces required by the document?

In Guideline 5, we state:

<BLOCKQUOTE>
Using interoperable APIs and following system c
onventions increases predictability for users
and for developers of assistive technologies.
</BLOCKQUOTE>

We might also say something there.

I don't think we need to add anything to the document,
but we could make an additional statement if the WG
wishes.

 _ Ian
 
> Charles
> 
> On Wed, 26 Jul 2000, Denis Anson wrote:
> 
>   I don't think we can make any "requirements" to the AT vendors.  That's
>   beyond our scope.  We have to make sure that the UA has an accessible path
>   that meets the needs of the person with a disability, but we can't say that
>   that is the only way to gain access.
> 
>   We can require a ramp to the door, but we can't keep people from climbing in
>   the windows.
> 
>   Denis Anson
> 
>   -----Original Message-----
>   From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
>   Behalf Of Charles McCathieNevile
>   Sent: Wednesday, July 26, 2000 2:14 AM
>   To: Ian Jacobs
>   Cc: w3c-wai-ua@w3.org
>   Subject: Re: Comments/questions about checkpoint 9.3 (configuration of
>   event notification)
> 
> 
>   I guess there is still an important issue of whether we require AT to access
>   through an API. (Rich, I'm fishing for comment here <grin/>). If not, then
>   producing the content through the UI is how the user is going to find out
>   what happened. I thought we had a seperate checkpoint that required taht,
>   adn
>   the configuration was to allow the user to turn that off.
> 
>   Charles MCN
> 
>   On Tue, 25 Jul 2000, Ian Jacobs wrote:
> 
>     Hello,
> 
>     In the 7 July Guidelines [1], checkpoint 9.3 (Priority 3) reads:
> 
>        Allow the user to configure notification preferences for
>        common types of content and viewport changes.
>           Note: For example, allow the user to choose to be notified
>           (or not) that a script has been executed, that
>           a new viewport has been opened, that a pulldown menu has
>           been opened, that a new frame has received focus, etc.
> 
>     1) Since this checkpoint does not specify that it is about notification
>        through an API (which is covered by checkpoint 5.5), our document
>        says that this checkpoint refers to notification through the
>        user interface.
> 
>     2) Looking back at the history of the checkpoint
>        (checkpoint 10.2 was introduced in the 9 July 1999 draft [3]), I
>        believe that originally this requirement was supposed to apply to
>        notification through an API and notification through the UI.
>        Refer to 30 June 1999 discussion [4]. We dropped filters
>        on the API notification at some point since applications can
>        filter out whatever they wish.
> 
>     3) If notification is to be provided through the UI, then by
>        default all events would have to be indicated to the user.
>        How would that work in practice? We have to address that
>        question before we discuss how filtering will work.
> 
>     4) If we try to identify a minimal set of events that are
>        "common types of content and viewport changes", what
>        would be in that set? We could use the information
>        in the Note after the checkpoint, but that list is
>        short and two of them are covered by other checkpoints:
> 
>        a) a script has been executed
>        b) a viewport has been opened (but control over viewport opening
>           is covered by checkpoint 4.16).
>        c) a pulldown menu has been opened.
>        d) a new frame has received focus (but control of focus
>           change is covered by checkpoint 4.15).
> 
>        I would note that checkpoint 1.5 already requires that messages
>        from the UA have text equivalents in the UI.
> 
>     5) The techniques document [2] talks about frame techniques but mostly
>        disabling notification of changes (on an element basis, for css
>     properties,
>        and for changing animations. In short, we don't have many techniques
>        explaining what events should trigger notifications, nor how that
>        information could be communicated to the user (e.g., through the
>        status bar).
> 
>     6) Who does notification through the UI benefit? For users with
>        assistive technologies, we already require that all changes
>        be sent through an API. What users using the UA's native
>        UI benefit from notification of changes?
> 
>     I'm looking for answers to these questions to figure out what
>     the minimal requirements for 9.3 are or whether we should delete it.
>     I realize that notification is very important, but we should flesh
>     this checkpoint out before we continue with it.
> 
>      - Ian
> 
>     [1] http://www.w3.org/WAI/UA/WD-UAAG10-20000707/
>     [2]
> 
>   http://www.w3.org/WAI/UA/WD-UAAG10-TECHS-20000707/#tech-configure-change-not
>   ification
>     [3] http://www.w3.org/WAI/UA/WAI-USERAGENT-19990709/
>     [4] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0265.html
>     --
>     Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>     Tel:                         +1 831 457-2842
>     Cell:                        +1 917 450-8783
> 
> 
>   --
>   Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134
>   136
>   W3C Web Accessibility Initiative                      http://www.w3.org/WAI
>   Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
>   Postal: GPO Box 2476V, Melbourne 3001,  Australia
> 
> 
> 
> --
> Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
> W3C Web Accessibility Initiative                      http://www.w3.org/WAI
> Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
> Postal: GPO Box 2476V, Melbourne 3001,  Australia

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Wednesday, 26 July 2000 13:04:22 UTC