W3C

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

30 Aug 2012

See also: IRC log

Attendees

Present
[Microsoft], Greg_Lowney, Jeanne, Kim_Patch
Regrets
Simon, Jim
Chair
Kelly
Scribe
kford

Contents


<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> 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]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/08/30 18:52:35 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: kford
Inferring ScribeNick: kford
Default Present: [Microsoft], Greg_Lowney, Jeanne, Kim_Patch
Present: [Microsoft] Greg_Lowney Jeanne Kim_Patch
Regrets: Simon Jim
Found Date: 30 Aug 2012
Guessing minutes URL: http://www.w3.org/2012/08/30-ua-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]