WAI UA -- 22 Jan 2007

<JR> Scribe: JR

In Person attendees: Cathy Laws - IBM, Peter Parente - IBM, Al Gilman - PF Working group, Janina Sajka - PF WG, Linda Mao - Microsoft, Aaron Leventhal - IBM, Jan RIchards - ATRC, Becky Gibson - IBM

JA: 1.3 Provide text messages (P1)

1.3 Provide text messages (P1)

AG: Events need to be known by UA, but lack of alt in user interface is a WCAG problem

JA: What about "non-essential" alerts?

AL: We don't have such a thing.

AG: We have politeness

CL: This is about events

JA: Ex. stock ticker changes - should be up to user to decide if this is important

AL: Yes want allow config of notification of alerts - controlled by politness

BG: Where do you draw line between UA interface and content interface?
... Right building tree controls etc. instead of letting user agent build controls

<KFord> Perhaps this has already been discussed in a different PF meeting group or something but has there been a proposal for web content to register the various types of events it is creating?

JA: When can user agent step in?

<KFord> By register I mean assign some level of importance or other rating that a UA could tap into?

AL: Would like to always handle it and let user decide which alerts to have
... Very infrequently do authors actually to anything specific for users
... Politeness in "Adaptive Properties" in States spec.
... Concept is...
... Has a dozen ideas in a separate doc

JS: Likes idea of doing things page by page

<scribe> ACTION: JA to Send message to PF asking for help with CSS-generated content. [recorded in http://www.w3.org/2007/01/22-ua-minutes.html#action01]

JA: Related problem in DAISY

8.1 Implement accessibility features (P1)

JA: TABINDEX plus ACCESSKEYS
... TABINDEX=-1 is this a feature?

CL, AL: Getting there

AG: Many scripted widgets using TAB to move to widgets and arrow keys within
... TABINDEX-1 used for TABINDEX to leap over

JA: So up to author to provide UI to move to TABINDEX-1
... Should UA interven somehow if author does not give UI?

AG: Compound people also interested - they ahave prob with this - doing things by ref - sub document - need some kind of composite navigation

SMIL - has depth first TABINDEX nav - compound doc has step over nav

CL: When you have TABINDEX and other keys - how hard to nav using screen reader?

JS: Can be confusing...

CL: Going from top to bottom nav to TABINDEX nav confusing since first TABINDEX can be halway down

<KFord> It can get complicated and also depends on the AT in use and how they respond to tabindex.

<KFord> In many cases the default is for the screen reader to ignore tabindex. This does vary by product.

JR: Reads kelly

PP: They are just 2 diff kinds of nav

AG: You should always have document order nav option
... In addition to TABINDEX

CL: Can start anywhere on load.

AG: THat's good - eg. Google Search starts with focus in search text field

<scribe> ACTION: JA to New requirment a document order nav option [recorded in http://www.w3.org/2007/01/22-ua-minutes.html#action02]

AG: We are also formalizing what TABINDEX is supposed to mean

JA: ACCESSKEY...
... Let's hold off on this
... Going to stop here for now.

<scribe> ACTION: JA to New requirment a document order nav option [recorded in http://www.w3.org/2007/01/22-ua-minutes.html#action03]

Breaking for lunch

We're back.

<cklaws> JR: Why UAAG should care about ATAG. WCAG, UAAG, ATAG don't read like 3 chapters of one book.

<cklaws> JR: Could share more. ATAG close to last call - should UAAG sync with it?

<cklaws> JR: WCAG has looked at ATAG structure.

<cklaws> JR: ATAG didn't want to write a11y guidelines. Decided to do own. Looked at UAAG and ISO and then structured to WCAG but using UAAG requirements.

<cklaws> CL: Distinction of user interface vs rendering of content.

<cklaws> JR: Initial draft of a UAAG structure based on ATAG

<jallan> uaag from atag structuer http://lists.w3.org/Archives/Public/w3c-wai-ua/2006OctDec/0053.html

<parente> ATAG TOC: http://www.w3.org/TR/ATAG20/

<cklaws> JR: Part A - UI accessible, Part B - a11y of rendered content

<cklaws> JR: WCAG does perceivable, operable, understandable, robust..ATAG does access system friendly instead of robust

<jallan> CL: atag only talking about generated content, uaag talking about rendered content

<cklaws> JR: See ATAG glossary

<jallan> JR: discussing editing interface in http://www.w3.org/TR/2006/WD-ATAG20-20061207/#definitions

<cklaws> JR: UI models - editing interface - almost WYSIWYG

<cklaws> JR: Editing view and content display are other UIs

<cklaws> CL: So in FireFox in editing mode is it ATAG or UAAG?

<cklaws> JR: IN ATAG, could refer to UAAG for rendered content, in UAAG refer to ATAG for edit mode

<cklaws> JR: UA user interface is both chrome and presentation of rendered content

<jallan> cl: links list is part of the chrome not the content

<jallan> cl: maybe, still thinking. drawing from the semantics of the content to generate list

<jallan> ...but the actual dialog is part of the chrome (generated by the ua)

<jallan> cl: a lot of this is techniques (e.g. generating a list of links)

<jallan> cl: could have setting to say suppress all content in place except links

<cklaws> JA: Let's walk thru the ATAG guidelines to see if UAAG has something equivalent

<cklaws> JA: Identify any issues - will send to ATAG with suggestions

<cklaws> JR: A.0.1 Anything that has Web-content conforms to WCAG

<cklaws> JA: Go back to ATG definition

<jallan> need to define plug-in - any add-on, extension, etc. from the manufacturer or 3rd party that provide additional functionality not found in the base product.

<cklaws> BG: WCAG doesn't address plug-in, except as content has to be accessible

<cklaws> JR: WCAG has higher level success criteria and are normative but techniques are recommendations

<jallan> see http://www.w3.org/TR/2006/WD-ATAG20-20061207/#Conformance-Claim "content type-specific WCAG benchmarks"

<cklaws> JR: In ATAG, tools must put out document to tell the benchmarks for measuring accessibility and how their checkers test for a11y - like the rules the tool chooses for

<cklaws> JR: Anyone using the tool can choose the rules

<jallan> cl: who creates the rules

<jallan> scribe: cklaws

JR: Rules don't have to follow any specific spec - you just have to state what spec the rules follow
... Haven't written one of these documents yet

CL: A.1.2 Why doesn't help have to conform to WCAG?

<jallan> cl: but its the same thing.

<jallan> jr: seperating software and web accessibility

<jallan> cl: so we have a section on writing accessible software.

<jallan> jr: is there anyway wcag could write software accessibility guidelines

JR: Maybe WCAG needs to address this first to provide a guidelines for ATAG and UAAG
... 508 dealing with same issues of Web vs software

<jallan> cl: everything needs to provide information to the accessiblity api

Aaron, is the Firefox chrome in the DOM?

JR: A.1.3. No specific statement about inheriting platform settings like high contrast - need to add.

JA: Success critieria for A.1.4 Shouldn't affect final rendering of text
... That is changes to display settings
... In WYSWIG environment, how does this work?

CL: through tool settings or system settings?
... Consider word processing

JR: Maybe needs to be more clear - what affects view vs rendered content

JA: A.1.5 #3 - in DreamWeaver, code view - see all tags are blue - add comment tag - never finish comment, now I see some other other color because you never closed comment tag

JS: Need to support multiple modalities for showing syntax error

<jallan> bg: don't what to inform screen reader of "error" or unclosed tag when user inserts an open tag

JR: The AT should be able to query the tool to find out if the elements past the unclosed tag are "grayed out"

<KFord> With respect to A.2.1, I have some concerns about the success criteria.

<KFord> In particular, item 4 that lists out a set of features that the author should have single key or single-key with modifier.

JR: #4 is all about color, #3 is about using an AT

CL: #3 should address error information programmatically as well

<KFord> This assumes that there's a static list of important features for an authoring tool. What if a given tool has some other feature that's key to use and it takes 10 keys to use?

<jallan> jr: this is taken from UAAG

<jallan> ...these are important, but who decides?

<KFord> For example in blogging software inserting links might be key but there's no requirement here that it is easy to do with the keyboard.

<jallan> ...#4 is the base set.

<KFord> What about some language around a task-based approach?

<jallan> ja: yikes, so mode keys when cutting and pasting, another mode for navigating, etc.?

JR: keys that are unique/specific to a particular tool, like blogging-specific keys

<jallan> ...inserting links happens a lot in blogging so should be easy

<KFord> Not necessarily, you can look at at something around if a task can be accomplished with one action from some input method, say mouse click, then it can not take more than some factor, say 3, more inputs from another.

JR: Maybe further explain and sent it to ATAG group

<KFord> My point is in terms of how to measure success if you've met this guideline.

<JR> Kelly - good idea but needs fleshing out - could you send to ATAG group?

<KFord> We can move on and I can communicate this to that group if that's the process.

<jallan> JR: moving through A.2.2 and A.2.3

<jallan> ...A.2.3 don't interrupt the user while editing

<jallan> ... A.2.4

<jallan> ...process discussion...

<jallan> 2.5 no issues

<jallan> 2.6 no issues

JR: A.2.6 need to add search for alt text to UUAG

<jallan> action ja add search for conditional content in UAAG

A.2.7 don't need undo in UAAG

<jallan> ACTION: ja add search for conditional content in UAAG [recorded in http://www.w3.org/2007/01/22-ua-minutes.html#action04]

<jallan> 2.7 no issues

<jallan> 2.8 no issues

<jallan> 2.9 no reference to UAAG

A.2.9 Can ATAG just refer to UAAG - as an option?

<jallan> jr: perhaps form a joint activity with ATWG and UAWG to look at software accessibilty

<jallan> cl: back to 2.6

<jallan> ... if you have alt text, and you are in wysiwyg view and alt is not editable, can you still search for alt?

<jallan> jr: yes, tool would let you search, when item is found, could switch to "code view"

<jallan> ...to allow editing.

<jallan> jr: gives example in dreamweaver.

<jallan> onward to 3.1

<jallan> no issues

<KFord> Out of curiosity do we know why 3.1 is a P2?

JR: A.3.2 Does UAAG have a consistency checkpoint?
... WCAG 3.2 is a consistency one

<jallan> cl: if input convention is broken then tool will be unusable.

<jallan> JR: will take back to ATWG, and see about pushing to P1

<jallan> ACTION: jr send question to ATWG about priority of A.3.1 [recorded in http://www.w3.org/2007/01/22-ua-minutes.html#action05]

<jallan> A.3.3 no issues, very similar to UAAG

<jallan> onto A.4.1

<KFord> Minor editorial comment that the list of assistive technologies should be broadened in this example. This is obvious likely but more examples e.g. voice input should be given in this intro.

A.4.1 Does this mean that tools MUST implement IAccessible2 now in addition to MSAA for Windows?

CL: Or is this an option?

<jallan> js: other ways to talk about implementing other APIs on windows or other platforms

JR: Say "an" instead of "the"

<jallan> ...accessibility api

CL: UAAG doesn't require accessibility API necessarily, could be DOM API

<jallan> pp: on linux it is "the" accessibility api

JS: More than one API on Mac, too - Carbon, Cocoa

<jallan> jr: reading success criteria

<jallan> ...Success Criteria 2 (SC2) info published is in the conformance claim

<jallan> pp: what is "default support"

<jallan> ...in SC 2(a)

<jallan> pp: confused why 'a' and 'b' exist, should be combined?

<jallan> cl: perhaps, if 'custom widgets' then need 'a' and 'b'

<jallan> cl: SC 3, perhaps this is covering other APIs

<jallan> ja: so the burden is on the accessibility tools to meet the requirements of the chosen api

CL: Sometimes there are private APIs created by applications (IE, Adobe Reader) that are created for the ATs, and they say for security reasons

<KFord> Minor editorial comment that the list of assistive technologies should be broadened in this example. This is obvious likely but more examples e.g. voice input should be given in this intro.That is how I read this i.e. you either do the default accessibility API on your platform, built something equivlanet that supports it or role your own and then expect the AT to support it.

<jallan> but will the 'role your own' be published publicly

<jallan> cl: one issue in flash and other tools was 'where is the caret'

<KFord> According to this requirement, yes it would be made available publicly.

<jallan> ...couldn't use msaa, had to use other platform apis

<jallan> jr: review of part b, canned content accessible,

<jallan> managing of reusable content

<jallan> make accessible options the first options

<jallan> ...not bury accessiblity features

<jallan> cl: is there an attempt to synch WAI glossaries

JA: EO is trying to sync the glossaries

<jallan> ----15 min break

<JR> We're back

Structure/Role of UAAG discussion

<JR> JA: Talked about this at various times

<JR> JA: Current structure is quite confusing

<JR> JA: JR talked about using same type of structure as ATAG

<JR> JA: Let's do that till 4:30

<JR> JA: Then gray area of author responsibility vs UA responsibility

<JR> JA: First thought - making UAAG modular...

<JR> JA: Core features...rendered content...

<JR> JA: Now we have whole areas on volume etc that may not be our responsibility

<JR> JR: Attempt at modularity with "conformance detail"

<JR> JS: Maybe specify that we expect X, Y Z available from environment

<JR> JS: Modular is the way everything is going

<JR> JS: like idea

<JR> CL: So we won't cover volume?

<JR> JA: Maybe not.

<JR> JA: We don't cover user agent

<JR> correction: don't define user agenty

<JR> CL: Got confusing - since some tools wanted out, ATs didn't know if they were fully in

<JR> CL: Do we address at all what AT's do.

<JR> JA: No

<JR> JR: So broad

<JR> CL: Looking at roots before home page reader

<JR> CL: PWwebspeak...

<JR> CL: Not enough access in browser or AT so these "research projects" were developed

<JR> CL: How do we separate

<JR> JA: We have stuff about speech but not about voice recog etc.

<JR> CL: "Not appliciable" could be used in conformance profile

<JR> JA: Only IBM did a conformance report

<JR> JR: If fail maybe wouldn't publicize

<JR> CL: After failing and failing - maybe lose interest

<JR> All: Discussion of defintion of UA

<JR> JS: AT out of scope

<jallan> JA: what is a plug-in?

<jallan> CL: flash player chrome is a UA

<jallan> JR: have a module for only web browser. with conformance claim

<JR> JA: We need to change plugin to call it an embedded user agent

<jallan> CL: why do we need to distinguish between them?

<jallan> JR: to know that they are included,

<JR> CL: Some plugins are just UI

<JR> CL: Some are renderers

<jallan> PP: its recursive, doesn't matter what you call your self, UAAG see embedded players as agents

<JR> CL: List of links generated from content NOT by content

<jallan> pp: why seperated chrome from content, they are converging

<jallan> JR: radio buttons, in the interface they are one thing, in the content they are created by authors and comply with wcag

<JR> CL: Probs with navigational mechanism guidelines

<KFord> But you also have instances where the plug-in can extend a browser chrome using web content so separation is not an easy line to me.

<jallan> cl: right, links lists, and list of accesskeys are like that

<jallan> cl: some blind users didn't like Home page reader because the interface was different from screen reader functionality

<jallan> cl: also difficulty with JAWS, a mode issue

<JR> PP: Modes are always problematic

<JR> JS: Browsers will always work somewhat differently

<JR> JA: Jaws and IE hard to get started on but good for power users. HPR great for beginners.

<JR> JA: Now JAWS has more functionality.

<JR> JS, JA: Many none SR people would like list of links

<JR> JA: People say too much crud messing things up

<jallan> has implications for dexterity impaired folks.

<KFord> I would say that several populations could benefit from some of the powerful navigation schemes that ATs have for navigation. You see bits oand peices of these in different browsers.

<jallan> jr: as JS said, AT are out of scope.

<jallan> CL: thinks AT vendors don't want to be seen as user agents.

<jallan> JS: AT is out of scope, but when AT provide technology to assist users when navigation and reading content then it is funcitoning as a user agent.

<jallan> CL: there are extensions and plugins (firevox, jaws, UIUC) to help comply with guidelilnes for a particular set of users

<jallan> JR: need to have a strong section on AT.

<jallan> ...develop a list of things that are so important that it needs to be built in.

<jallan> CL: base user agent must porvide alll the information to a 3rd party to provide a feature, or do it themselves

<jallan> CL: navigation of content might be considered UI as oppoesed to a rendering comopliance

<jallan> CL: will be hard to think through things this way.

<jallan> PP: this is model view controller. IBM article is in the UAWG archives.

MVC article: http://researchweb.watson.ibm.com/journal/sj/443/brunet.html

<jallan> JR: navigation. allow an out. conformance claim on UA and JAWS. when we work together then we conform

<jallan> ...but there may be issues.

<JR> JA: But also issues for people not using assistive technology.

<JR> JA: What about IE users without JAWS

<jallan> pp: the UA needs to support the ability to do structured navigation. provide the information so extensions can provide the feature

<JR> CL: Firefox has lots of plugins...must state they must be compatible

<KFord> I would expand this to well more than just IE/FF Firefox users without JAWS? What about some system that doesn't have an AT but where someone's building a user agent?

<jallan> cl: if in a compliance claim you use 5 extensions with the UA, then all the extensions must be compatible

<JR> CL: Plugins may not all be compatible

<JR> JS: What about new apple phone

<jallan> CL: Kelly, these are just examples

<JR> JR: Yes

<jallan> CL: it is an issue for UA developers (mobile, etc.)

<JR> JS: At some point - make sure there are devices to serve the kind of content retreived

<JR> JR: We don't talk about devices

<JR> CL: In the past we have talked about persuasive issues and discovered we didn;t cover things super well

<JR> JA: So do we need in core area something about multimodal access.

<JR> JS: In persuasive, not that different than desktop

<JR> CL: But ex. they don't want keyboard

<jallan> jr: no requirement around hardware device, no screen, no keyboard, only voice reco

<jallan> cl: many systems you can't plug in other output modes

<jallan> js: backends for pervasive devices are missing the multimodal functionality

<JR> JS: Backend of some of the software are being developed with certain devices in mind.

<JR> JS: Just afraid that things being left out that are needed in the future (from protocols etc.)

<jallan> we will be taking this up in the future. with more structured discussion.

<jallan> \

<jallan> cl: to be effective we must have the UA developers onboard

<KFord> Thanks all, talk in the morning.

- DRAFT -

WAI UA

22 Jan 2007

Attendees

Contents

1.3 Provide text messages (P1)

8.1 Implement accessibility features (P1)

Structure/Role of UAAG discussion

Summary of Action Items

Scribe.perl diagnostic output