<scribe> Scribe: JR

<parente> http://www.w3.org/TR/wcag2-req/

<cklaws> This document provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities (visual, hearing, physical, cognitive, and neurological).

All: Editing Requirements Intro - using WCAG 2.0 Req document as a model

<jallan> http://cita.rehab.uiuc.edu/wai-eval/index.php?option=Test%20Suites

All: Introduction edits: hilighting info from test suites.

<KFord> Yes, I do have Skype.

<KFord> Yes, trying to add as a contact now.

<KFord> I'm told this contact isn't found, can you phone kellford1967 on skype?

<jallan> Introduction

<jallan> User Agent Accessibility Guidelines 1.0 (UAAG 1.0) provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities (visual, hearing, physical, cognitive, and neurological).

<jallan> Since the release of UAAG 1.0 as a W3C Recommendation in December 2002, the UA WG has received feedback about the usability, understandability, and applicability of the suite of documents.[changes in the techniques used in web pages (extensive scripting, changes in the use of technology used for the web, udates in the functionality of assistive technology, changes in accessibilty APIs, changes in platforms (pervasive, mobile devices, etc.) These changes in additio

<jallan> The primary goal of UAAG 2.0 is the same as 1.0: to lower barriers to accessibility of user agents. Additional goals discussed in this document are:

<jallan> Ensure that requirements may be applied across technologies

<jallan> Ensure that the conformance requirements are clear

<jallan> Design deliverables with ease of use in mind

<jallan> shift focus back to base browser (make user agent base provide the accessibility model )

<jallan> explain how to demonstrate compliance through an accessible view using the appropriate UIs (browsesr and extenstions, assistive technology

<jallan> Clearly identify who benefits from accessible user agents

<jallan> Ensure that the revision is "backwards and forward compatible"

CL: CL's ideas for the requirements doc:
... 1. Encourage adoption of ARIA techniques by all UA's
... 2. More clearly define UAs as browsers but distinguish testing of compliance to distinguish plugins and ATs
... 3. Restructure to align more closely with TAG and WCAG
... 4. Audience - must attract all browser developers to participate as well as accessibility architects for APIs and accessibility markup architects
... As well as consumers of accessibility APIs (AT developers) and end-users of user agents.

KF: Plus Plugin developers

UA: Wants to remove "plugin" and use "embedded UA"

PP: Plugin to VIW - plugin to chrome

VIW=VIEW

PP: Use Case: FLASH in a doc has own model and view
... FLASH implements accessibility API

<jallan> plug-in vs extension vs model

<jallan> flash - own ui, implements accessibilty api (part of infrastructure), provides content

MODEL: Programmatic access

VIEW: Is the UI (the chrome, AT, etc.)

<jallan> model is the base that everything is built from or overlayed upon

<jallan> view is the gui (chrome, AT, content view, etc.)

<jallan> jr: might also split the view into chrome (UI) and content

CL: Other views: Firevox, UIUC accessibility extension

<jallan> use case: UIUC accessibility extension - extension to view (using api to get information), consumer of existing model, extents the browser ui to provide information to end user.

JA: Brings up compound docs - where navigation and other things are made more uniform

All: Discussion of model-view controller split as related to multimedia

<jallan> flash/media-player/PDF - own ui, implements accessibilty api (part of infrastructure), provides content , both a model and the view, not part of the HTML DOM , embedded object (in HTML), may have own DOM/API, may expose public API so others can get at the information

KF: Good use case - what would plugin developer do - ie Quicktime doesn't expose

CL: Other use case - Web applications

KF: Ex. tree view controls

CL: ARIA doesn't handle keyboard nav at the moment.
... Becky etc. writes style guides for widget sets specifying how to do keyboard nav

<jallan> web application - own ui (provided by the author, not the model), repurposes functioning of standard controls and creates custom controls [author must use WEB-ARIA to be accessible], doesn't implement native/platform API.

<jallan> jr: can have a web application that is an editor

<jallan> cl: try to get the browser to understand what is going on and provide the information to the APIs

JR: Can have web content that is a user agent

<jallan> cl: may be trouble with ARIA because of implementing its own keyboard navigation

CL: It's a SMOP=Simple Matter of Programming

<jallan> ...not part of chrome, the browser can not interact and allow the user to modify the web-application's key bindings

<jallan> cl: want to avoid off screen models, heuristics,

All: Don't want things to be done site by site

<jallan> all: problems with javascript, outside of the model, doesn't provide a model of what its doing, not part of the dom

<jallan> ..can assign keybindings,

CL: Not people in accessibility creating this technology - access is reacting.

<jallan> UAAG is trying to provide direction for developers to make access easier

<jallan> CL: AT is not a model (may have its own model), it provides a view - consumes the controller model and provides output

<jallan> Ensure that requirements may be applied across and interoperable with technologies (compound documents, scripting languages, operating systems, platforms (mobile, etc.), APIs, accessibilty architectures

<jallan> Ensure that the conformance requirements are clear

<jallan> Design deliverables with ease of use in mind

<jallan> shift focus back to base browser (make user agent base provide the accessibility model)

<jallan> explain how to demonstrate compliance through an accessible view using the appropriate UIs (browsesr and extenstions, assistive technology

<jallan> Clearly identify who benefits from accessible user agents

<jallan> Ensure that the revision is "backwards and forward compatible"

<jallan> restructure to more closely align with ATAG and WCAG

<jallan> http://www.tsbvi.edu/technology/uawg/issues-jan11.htm

CL: Also should add note on "reducing redundancy"

JR,PP: Should keep stop bliking etc. for known things - "AL's 80-20 rule"

JA,CL: Discuss customization - customization can be overload

KF: Depends on implementation
... One button - may do multiple things - plus profiles help

JA: Yeah but may still be daunting

CL: How do you make customization easier

JA: ScrReader have many modes
... Form in table runs into Form mode/Table mode interaction problems
... Gives example of checkbox in form cell

CL: Yeah but where do you want info pulled from?'

JA: Other example - Form with prompts
... Forms mode make instructions difficult
... Finds himself on a "bunny trail".

<jallan> CL: what about flashing things. what is the issue

<jallan> jr: photo sensitive

<jallan> JA: there are things that UA doesn't know about,

<jallan> KF: push back to content develpers to create things that the UA can determine and make accessible control

<jallan> JR: WCAG role for content developers

<jallan> CL: UA need to address non-W3 technologies

CL: Idea for MathML person - Neal Soiffer - Design Science

KF: Let's move on

JA: Going through issues doc...

<jallan> goal 7 restructure to more closely align with ATAG and WCAG simplify but combining similar checkpoints, reducing redundancy

<jallan> balance roles Author content and UA functionality (repair and control functions)

JR: Once again we should be less absolute about compensating for author actions - since these can't always be predicted

CL: CSS is a nother thing that author may use in ways that need to be fixed

KF: Hard to do - UA has to look in CSS directly and use heuristics

PP: In Linux it's easier because this info goes into the Linux access API

PP, CL: Discuss bullets - are they content? In FF they are handled as content.

JA: Skins...

PP: FF uses CSS for XUL.

KF: IE does not do this

CL: Also access-aiding CSS like magnication style, high contrast style
... Can cause prob - ex. author says "no scrollbars" but user stylesheet makes content too big too fit

JA: Brings up voice settings

JR, KF: This should be modular, applying to voice browsers but not to all UAs

All: Discuss where to put chrome in the reqs

JA: IE does extensions?

KF: IE has had extensions for a long time
... What burden on underlying technology to make extension experience accesible?

PP: Right what to do in model...

JA: Right - seen extensions in menu bars, other just change functionality, or something in status bar.

JR: How much customization do extensions allow?

KF: Suppose allow things to be added to areas that are not keyboard accessible.

<jallan> pp: bad browser

<jallan> JA: bad developer

KF: ex. Toolbars hard to make keyboard accessibler

JA: Same way in FF

CL: Browser should enable the extension of the environment to be accessible

PP: Right - mixed responsibility

mixed=shared

JA: 4.4...
... 4.14...

PP: User Javascript

KF: Customizing the content view

CL: Similar to Web Applications

JR: Right but should it be a requirement?

KF: So does user have to be able to change content?
... If you enable someone to say linearize a table does this have to be accesible?

JA: Yes

CL: Right we're trying to figure out the divisions

KF: THis goes into good ideas for more accessible views

JA: Guideline 6...

CL: We want to promote engineered APIs - "usa AN accessibility API"
... DOM is incomplete - no javascript, no CSS< etc
... That's why platform API's becoming so important

PP: Hard to specify what is meant by "Complete API"

CL: We want to promote platform API's over DOM since its also compatible with other desktop applications.
... But of course Javascript needs to go to the DOM not the platform specific API.

<jallan> CL: history of accessility

<jallan> APIs, and work on cross platform accessibility apis

<jallan> goal(?) promote a platform accessibility API's and the HTML DOM [incomplete because DOM doesn't do extensions, CSS, scripting] since the platform accessibility API is also compatible with other desktop applications.

CL: Want to promote implementation of engineered APIs by UAs and embedded UAs PLUS chrome extensions
... for use by ATs and implementation of HTML-DOM for in process components

KF: Active-x controls are in process but should still implement MSAA.

JA: We're back
... We need to spend some time on our charter
... till 215
... on our requirements - then we'll get to the charter
... 6.6...

CL: Covered already

JA: 6.7...

CL: How do we address shifting of controller...

PP: Who manages, what constitutes

JA: Keyboard conflict stuff should go under goal 1

KF: Other issue - conflict with access keys

CL: We don't address this in UAAG

JA: Actually this comes later...
... 7.1...
... Browsers need this functionality even if done by extension

KF: ctrl-A enough?

JA: Probably more granular better

KF: Not disagreeing

CL: Maybe controller is something to talk about separeatly

<parente> MVC reference: http://en.wikipedia.org/wiki/Model-view-controller

PP: Keyboard handling at the core

CL: Core would also include strcutured nav etc

JA: 8.1...

<parente> wikipedia MVC page has decent definitions of model, view, and controller

JR: Handled

JA: 9.1...
... What is the author/UA responsivility split.

KF: Interesting...ex. ATs pretty good at dealing with onclick etc.

JA: Yes because of people not using mouse but not ScrRead (actually its onMouseOver)
... 9.2...

CL: Covered.

JA: 9.3...
... Consider combining
... 9.4...
... Covered.
... 4.12...
... 4.13...
... 6.10...
... Coverd in API stuff
... 7.3...

KF: Other issues - should browser even do that (inform of these things) - ex. if I'm running browser with SR is that anyone else's business.
... Personal info.

<jallan> jr: continue to view user configuration as private information not to go back to the server/net

JR, CL: Discussion of types of info involved - platform preference, browser prefs...

<jallan> added ?how should inprocess javascript etc. be provided platform specific information (high contrast mode), AT settings (yikes!), and user preferences?

<jallan> as a second item to goal 1

<jallan> pp: note, javascript may be used to do malicious things with the preference information.

8.2..

CL, KF: Remove

9.5...

JA: Covered

9.8...

JA: Covered

<jallan> CL: is the requirement that you can search for conditional content for any view.

<jallan> ...is tooltip part of the view.

<jallan> pp: should search the view

CL: prob browsers only searching visual view

<jallan> cl: some screenreaders don't allow you to search for all words you have heard, because it only allow search of rendered content

KF: Not so straightforward...
... Let's say SR doesn't show title tags

<jallan> cl: search the model that was rendered (view) based on user preferences

<jallan> ...so if titles turned off by user, then can't search for title

CL: Searched what is shown

KF: SR's allow you to find alt text for images
... Base requirement would be just to search things that are displayed

9.9...

11.2...

JA: Finished review

<scribe> ACTION: JA, JR to Cleanup the goals list. [recorded in http://www.w3.org/2007/01/23-ua-minutes.html#action01]

<scribe> ACTION: JA, JR Cleanup the goals list [recorded in http://www.w3.org/2007/01/23-ua-minutes.html#action02]

<scribe> ACTION: JR to Test [recorded in http://www.w3.org/2007/01/23-ua-minutes.html#action03]

Charter Update

<KFord> http://www.tsbvi.edu/technology/uawg/draft_of_UA_charter.html

JA: Date stuff will be hanfled later
... IMportant stuff is scope

JR: likely to be 2.0 not 1.1

JA: Calling it "new version of WCAG"

WCAG=UAAG

KF: track implementation of UAAG PERIOD
... Should we scope #4
... Should we also have implementation report

<jallan> 1st quarter 2007

<jallan> Publish Requirements document for UAAG 2.0

<jallan> 2nd quarter 2007

<jallan> recruit appropriate members and invited experts for developing

<jallan> 4th quarter 2007

<jallan> Publish Rough Draft of UAAG 2.0

<jallan> 3rd quarter 2008

<jallan> Publish Last Call

<jallan> Produce revised AUAG 1.X Techniques Note.

JA: Dependencies...
... Should we discuss XML...

<jallan> ACTION: ja bring up XML accessibility in UA to WAI coordinating group [recorded in http://www.w3.org/2007/01/23-ua-minutes.html#action04]

New people etc.

KF: whats problem?

JA: Many ATs very specific...
... No one from cognitives...
... Just a few from dexterity, SRs. keyboards
... few meetings...

CL: Except IBM + blind user input - which led to SR focus

JA: Had David P., Earl Johnson, David Clark...
... WGBH folks, some I people

KF: What about Adobe?

JR: Bob Regan?

CL: Andrew Kirkpatrick
... New someone from Apple (Safari), Opera

KF: Target Doug Geoffey

JA: What about someone from ATIA who could then farm it out

CL: Need some ARIA people...
... Maybe someone from Google

JA: Maybe also draw from other WG's that we identified in CHarter

JR: How many do we want?

JA: Call for participation goes out widely.
... There needs to be a core
... of 6-8 people
... Also extension developers

CL: People on UVIP mailing list?

JA: What about standardista people?
... Real?
... What about someone from MS MediaPlayer?

KF: Will look into it.

What about access API architects.

CL: Opera - they also do some multimodal stuff
... Really need someone from SUN - they own accessibility API on SUN
... IBM Research?

big UAAG concverns about ARIA

PP: KEYBOARD: UA doesn't know what scripting is catching
... STYLING: CSS doesn't get into the DOM
... USER PREFERENCES: Platform and UA prefs (eg high contrast ) can't be accessed by scripting.
... FREEZING: UA can't freeze interaction with script execution the way it could with rendering
... PARTIAL CHANGE: Live regions being updated without UA knowing extent

<Al> are you still going or are you enroute?

<Al> G531

<Al> Gates Tower, i.e. the other one.

<Al> Find elevators, come to 5th floor, head for W3C

<Al> We're in the W3C conference room.

This is scribe.perl Revision: 1.127  of Date: 2005/08/16 15:12:03  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: JR
Inferring ScribeNick: JR

WARNING: No "Present: ... " found!
Possibly Present: Al All CL JA KF KFord MODEL PP UA VIEW cklaws jallan jr judy parente
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: http://lists.w3.org/Archives/Public/w3c-wai-ua/2007JanMar/0009.html
Got date from IRC log name: 23 Jan 2007
Guessing minutes URL: http://www.w3.org/2007/01/23-ua-minutes.html
People with action items: ja jr

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