Minutes of UAWG Teleconference of 30 August

Minutes <- http://www.w3.org/2012/08/30-ua-minutes.html

Text of minutes:
    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

     User Agent Accessibility Guidelines Working Group Teleconference

30 Aug 2012

    See also: [2]IRC log

       [2] http://www.w3.org/2012/08/30-ua-irc

Attendees

    Present
           [Microsoft], Greg_Lowney, Jeanne, Kim_Patch

    Regrets
           Simon, Jim

    Chair
           Kelly

    Scribe
           kford

Contents

      * [3]Topics
          1. [4]Conformance Use Cases
      * [5]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 30 August 2012

Conformance Use Cases

    <scribe> Scribe: kford

    JS: We have an issue how mobile phones and apps are going to be
    able to claim conformance to UAAG.

    <jeanne>
    [6]http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120827/MasterUAAG2
    0120827.html#conformance

       [6] 
http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120827/MasterUAAG20120827.html#conformance

    JS: This is a doc that Kim and I have been working on.
    ... We have two actions here that have to do with mobile
    conformance and how we are going to get them to apply.
    ... A bit ago JAN write a proposal for partial compliance.
    ... I can saythat there has been concern about partial
    comfomrance though because this removes a lot of insentive to
    improve for manufacturers.

    GL: Can you clarify what you mean by use cases in this context.

    JS: We have browsers and media players that run on the desktop.
    ... We have a browser that runs on a mobile phone that uses a
    hardware keyboard. We have a browser on a mobile phone that
    only has a touch interface.
    ... We had talked about situations where in mobile there were
    cases where the browser and aps were dependent on the platform
    more so than their own code to SC to function.

    GL: I see use cases like this used for a. for us validating our
    SC to make sure they are not broken.
    ... An example might be oh, keyboard only SC doesn't make sense
    on a touch device but we would have an answer for this based on
    things.

    B. We could publish a list of use cases as informative
    materials in order to let readers have higher confidence that
    all the SC make sense.

    GL: We are letting the readers know we have verified the SC
    make sense in the context of all the use caases.

    C. The activity of verifying of use cases with SC can drive new
    examples.

    JS reading action 704.

    JS Now reading action 648.

    GL goes over a case where a user agent could claim conformance
    but the end user wouoldn't know that things were missing and
    the device would end up being unusable.

    JS: L Opera runs on basic cell phones of various types. How
    would it claim conformance?

    GL: I think of this as a family of products and each one is
    separate.

    KP: I agree.

    GL: The more interesting question is you have one for Windows
    where the accessibility is different when run on various
    versionjs due to platform accessibility changes. How is a claim
    for that circumstance.
    ... A web based user agent queries for the underlying agent and
    adjusts UI match the underlying host user agent i.e. Safari, IE
    and such. How does it claim conformance there?
    ... Those adjustments might impact conformace and
    accessibility.

    rfrsagent, make minutes

    More discussion about various hardware platforms.

    GL: I'd suggest that we come up with a short list of use cases
    that we want to test our SC against.
    ... The small cases of use cases are not enough to verify that
    our SC are correct. It is the fringe cases that become
    interesting.
    ... You need to think about a tester and think about what can
    break this.
    ... The three/four use cases are good but not enough.

    KF: Do we have an idea of what theyse three to four use cases
    are?

    GL: The most obvious is a desktop computer with a keyboard,
    screen, mouse where the user agent is a stand alone app
    ru8nning on any full OS.
    ... A second case is a web browser that ships on a mobile phone
    that lacks a keyboard and has primarily touch input.
    ... A third use case is is a blind user on a desktop O

    <jeanne> KP: Better to say a keyboard user, which covers more
    cases.

    <jeanne> GL: A telephone based browser - audio out and numeric
    keypad input

    <jeanne> GL: Media Player plugin that needs to be hosted inside
    a browser.

    <jeanne> GL: A web-based user agent that runs on multiple
    platform

    <jeanne> JS: Like GMail

    <jeanne> KP: we have two different things here -- what's the
    technology? and how does the user communicate with it?

    <jeanne> ... and every single one doesn't work on every single
    one, but we can parse enough categories.

    <jeanne> KF: What do we think is a meaningful end goal?

    <jeanne> GL: We have think about these use cases to show that
    we have considered them and included them. A rigorous sanity
    check.

    <jeanne> KF: Due to platform, the user's ability to input
    information is restricted in some fashion, or the user's
    ability to perceive information is restricted in some fashion.

    <jeanne> JS: I'm afraid that doesn't solve the basic problem
    from Action-740 - that something that runs on multiple
    platforms and uses the platform to meet the UAAG standards.

    <jeanne> ... for example, my Nokia phone from several years
    ago, ran Opera, which ran on many different phone platforms.
    Opera is the most popular browser in the world, if mobile
    devices are included.

    <jeanne> GL: Like IE could claim conformance on all the Windows
    platforms, it would be one conformance claim, but it would need
    a separate conformance claim for the Mac.

    <jeanne> ... so if it passes all the success criteria for a
    platform, that is one conformance claim. If it fails on one
    platform, it needs to file separate claims.

    <jeanne> JS: What about a web app that runs on multiple
    browsers?

    <jeanne> GL: For any SC, they pass or fail. Or it alters its
    behaviors based on the browser it is on, so that it passes on
    one browser and fails on another.

    <jeanne> ... OR "we may pass or fail, depends on the browser
    that is hosting us, but that is not a decision we are making
    ourselves, then we cannot answer that question."

    <jeanne> ... Do we support High Contrast mode, well, we do if
    the browser tells us about it, but not if it doesn't.

    <jeanne> GL: Those are not only applicable to web user agents,
    it applies to any aspect of the application-platform
    relationship, like a desktop browser is dependent on the OS it
    is running on.

    <jeanne> GL: An example of that would be like in Windows, a
    global accessibility setting. We have an SC that says that
    users need to see accesskeys for shortcuts. The example could
    be that if the user has keyboard accessibility turned on, they
    pass.

    <jeanne> GL: A more common case is that of extensions and
    optional addons, so when the manufacturer says "we comply if
    you install this extension - like mouseless browsing
    extention."

    <jeanne> ... we expect the following answers: Yes, No, Yes with
    the following options, Yes with the following platform settings

    <jeanne> ... maybe to say "Yes on the following platforms"

    <jeanne> ... the one with the platform configuration would
    include browsers in the case of a web based user agent.

    <jeanne> JS: So we could allow anyone submitting a claim to
    pick the ideal platform and options for their claim.

    <jeanne> GL: Nothing is going to support every SC on every
    platform in every configuration.

    <jeanne> ... or at least it will be rare.

    <jeanne> ... as long as the conformance claim is upfront with
    the configuration information required to pass it.

    <jeanne> ... it would be most useful to the user to have that
    information up front - especially if it said how to turn on the
    feature needed for conformance, it would be awesome.

    <jeanne> ... otherwise, it might take the user a very long time
    to figure out how.

    <jeanne> KP: That would be very useful, but it changes

    <jeanne> GL: But not for each conformance claim. If you change
    the product, you file a new conformance claim.

    <jeanne> JS: But if the platform changes, the product isn't
    going to make a new conformancce claim.

    <jeanne> GL: we need a sample conformance claim document that
    demonstrated how to do it.

    <jeanne> Summary: Two different topics - (1) creating use cases
    for these 3 purposes, and (2) how do we see that fitting into a
    conformance document.

    <jeanne> 1) We think it is valuable to have a set of scenarios
    that serve the purposes of 1) validate the success criteria
    across scenarios, 2) publish the use cases to increase audience
    confidence in success criteria testing, 3) to generate examples
    that would be included in the Implementing document.

    <jeanne> The potential use cases discussed: the application run
    on traditional desktop with mainstream OS with keybaord, mouse
    and screen;

    <jeanne> ... an application included with a mobile phone with
    no keyboard and a touchscreen

    <jeanne> ... web-based user agent that is a media player that
    runs inside other web browsers

    <jeanne> ... audio-only user agent -- a browser designed for
    use over the telephone with audio output with speech or
    touchtone input.

    <jeanne> An open issue is how we should address configurations
    specific to people with disabilities - keyboard-only or speech
    users.

    <jeanne> KP: if you have keyboard-only, touch-only,
    speech-only, keyboard & mouse.

    <jeanne> JS: gesture & touch.

    <jeanne> GL: could be in-air gesture.

    <jeanne> GL: we have SC that assume overlapping windows. SOme
    platforms don't have that.

    <jeanne> KP: There is screen and audio for perceivable. There
    is haptic in the future.

    <jeanne> How should we address the array of input and output
    technology.

    <jeanne> GL: there are also partial issues.

    <jeanne> KP: Can you catch everything, and separate everything
    into the input types.

    <jeanne> GL: we need to separate: Are we breaking the SC? vs Do
    we need additional SC in order to meet the needs of users?

    <jeanne> 2) Conformance Claims:

    <jeanne> a) what should a conformance claim document look like?

    <jeanne> b) how should we instruct users how to complete them
    in our Implementing document?

    <jeanne> COnformance Claim document should include the user
    agent, and the list of platforms for which this set of answers
    complies.

    <jeanne> A set of global requirements would say "this assumes
    the user has turned on the following options in the operating
    system"

    <jeanne> ... and has not chosen to omit the following optional
    componsents of the web browser during setup"

    <jeanne> ... and has a summary of findings by level.

    <jeanne> ... possibly include required extensions or plugins
    required for conformance to individual SC.

    <jeanne> ... for each SC, it provides one of the following
    responses:

    <jeanne> a) Pass, or does not Pass

    <jeanne> b) Passes with the following cases (e.g. inclusion of
    an optional extension, platform option enabled, or implemented
    on user agents that implement a feature)

    <jeanne> Note there: that if there are special cases for
    different platforms, and that as a result that it will pass or
    fail this SC for different plat=forms, that will warrent a
    separate conformance claim for that platform.

    <jeanne> ... so there is less reliance on the host user agent
    for passing that SC.

Summary of Action Items

    [End of minutes]

Received on Thursday, 30 August 2012 18:54:42 UTC