WAI UA -- 6 Nov 2007

<JR> Scribe: JR

JA: PF thoughts?

CL: We really do need a Charles or Aaron type person

JA: JR and I talking about service-themselves stuff...
... If they don't want to do it maybe we can put it in as P3

irc.w3.org, port: 6665, channel: #ua

test

<jallan> CL discussing 6.7 - order of key execution.

<jallan> CL: adding 2. Establish and document how the user agent resolves key binding conflicts between the user agent user interface, user agent extensions (e.g plug-ins), HTML elements (i.e. accesskeys), and ?JavaScript functions (i.e. keypress events). If a keystroke is not defined by the user agent user interface,the user agent should pass it on to the user agent extensions, HTML elements, then...

<jallan> ...?JavaScript functions, in that order.

<jallan> CL: do we really need to be this prescriptive.

<jallan> JA: I agree

<jallan> JR: +1

CL: APIs for keyaborad just took you to a defn of APIs

JR: CLs peice should be broken into two

<chaals> [There should be one requirement to document how this happens - i.e. in what order different things get the keys.

<chaals> ...and another that the browser use them before handing them to the page]

<chaals> [There should be a seperate one that the browser ensure, for standard mechanisms (html:@accesskey, ARIA??) that there is an activation mechanism for anything that has a shortcut assigned]

<chaals> [oops. And a discovery mechanism]

<oedipus> +1 to chaals' 2 part proposal

<jallan> split CL proposal into 2 sections. Documentation proposal to be added to GL 12 Documentation, keybinding to be placed in GL6

"Provide a discovery mechanism for all author defined keyboard navigation."

<jallan> previous JR comment added to CP 1.1

<jallan> CL: provide a feature or function to allow the user to display author defined keyboard bindings that are known to the UA

Provide a feature that displays author-defined keyboard bindings that are known to the user agent.

<jallan> JR: not 1.1 put in 11.3

<jallan> JA: can see a regrouping in all of UAAG 1.1 6.7 11.3 etc. are all related to keyboard/device independence

<jallan> CL: where is "resolve the keyboard conflicts"

<jallan> JR: 6.7

<jallan> CL: should be in 1.1

JA: Really impressed by idea of using AccessKeys for navigation in mobile phones
... Then there is line-21 on tv broadcasts on mobile phones

<jallan> JR: discussion of UA serving itself (getting keybindings first, then passing off to application)

<jallan> JA: users get confused when UI doesn't function as normal

<jallan> CL: Windows OS grabs ALT keys first, so ALT-F, it is the OS that opens the menu

<oedipus> but on W3C list archive pages, alt plus a moves focus to the "sort by author" link, even though alt plus a is reserved for "Favorites"

<oedipus> no consistency in implementation or cascade -- that's what we need to define...

JR: Plus we just tested alt-f and it was grabbed by access key

<oedipus> JR: with or without an AT?

without

<oedipus> ok, good -- wanted to eliminate AT awareness of accesskey as culprit

It did not go to File menu (test in IE)

<jallan> Cl: in FF if ALT-A with page with accesskey=a, the Favorites list opens

<oedipus> that's because FF uses shift plus alt as modifier

<jallan> CL: what is the order of presedence

<oedipus> GJR: should be up to user - think of it as a "politness level" for accesskeys etc.

<oedipus> that's politeness (obviously i don't have much experience with that word!)

ah yes

<jallan> ... of keybindings. very inconsistent between OS, application, content

<jallan> JA: good concept GJR

JA: Maybe we have configuration - binary choice between UA user interface grabs first and doc grabs first

doc=content

<jallan> add to 1.1

http://www.w3.org/WAI/UA/2007/WD-UAAG20-20071106/WD-UAAG20-20071106.html

fyi: here's the draft so far today.

<jallan> discussing CSS writing to the DOM

<jallan> JR: abstract: technologies may write to the screen, these technologies should also write to the DOM

<jallan> CL: the UA knows about the other technologies, and writes to the DOM

<jallan> CL: with javascript is there anything that ensures that information about an element is written to the DOM

<jallan> JR: content generation by CSS should be written back to the DOM

<jallan> CL: when you translate info from other technologies to the DOM - it is not written to the DOM as HTML syntax and elements only as content

<jallan> when you look at the DOM there is no way to tell if a checkbox was created in HTML or in JS

<jallan> ... ARIA roles and states helps

<oedipus> any content generated from embedded operands?

JR, CL: Discussing DOMs produced by MathML, SVG, etc.

CL: Gets into DOM but source based so ATs can't understand it

<jallan> CL: when using MATHML is used in a page, it used a different DOM so the UA is unaware, but if the UA converts MATHML properly and writes to the a11yAPI then AT gets the information

<jallan> CL: UA uses roles to convert JS or whatever into 'recognizable' elements for dom and AT

JA: Let's break

<oedipus> i'm joining at the top of the hour, unless instructed otherwise

Back from break.

<oedipus> ok, will call in

Section 9

JA: We've been making reasonable progress.

http://www.w3.org/WAI/UA/wiki/NavMechanisms

PP: Most sections in GL9 had issues
... Need to update defn of enabled and interactive

<oedipus> scribe+ oedipus

<oedipus> scribe: oedipus

PP: anything can receive focus or be addressed using javascript -- def needs to change -- [reads first sentence]
... could be by spec or author can make content interactive with some code
... remaining needs work; interactive elements -- def doesn't mention -- enabled element piece of content that can be activated through UA or API...

JA: covers it -- doesn't specifically say authors can do, but not limited to doing what is listed

JR: scope of change?

PP: just first sentence needs to be replaced, then 2nd needs to be tweaked to mention "programmatic"

JA: ckpt remains same -- need to redefine terms, right?

JR: according to original issue that's what it looks like, unless missed something in original issue
... even in AJAX content focus is still handled by UA or does javascript hand off?

PP: always UA --
... 2nd issue - Where is the line drawn between what the UA vs Author coding should do to provide for accessibility
... confusing -- example: FF scrollable to display hidden or overflow content -- set to auto, automatically gives focus to div or iframe by UA so scrollbar can be manipulated

JR: does javascript ever take over and draw focus off

JA: UA put focus back, or does author have to programmatically indicate

CL: explain

JA: taking out of task order - can't just focus unless author provides mechanism to give focus;
... sytling through CSS, rather than UA?

CL: [can't hear]

PP: firefox draws border around items that defined as negative 1 in tab order

CL: do we say they have to do this for all ?

JR: another compound document/mashup GL?

<parente> correction: not all with tabindex=-1, things that the browser knows are interactive like scrollable divs

JA: morphing structure of document to make more functionally based

CL: some sections all about navigation (such as 9) -- GLs themselves may need to change

JA: written from perspective of user -- wants keyboard to work; we're flipping it and saying this functionality is for UA devs

CL: did we already define the term "interactive" -- have "enabled elements"
... need def of "interactive"?

JA: add PP's second proposal bullet

PP: might be useful as a clarifying note -- this is what we think UA is responsible for -- if go beyond, great

JA: written as success criteria -- could be technique if written generically
... need to add UA extensions to chrome -- of is anything in the chrome chrome natively or added by scripting

PP: 9.2 - one of issues listed there -- if address now, 9.1, might not have to change 9.2

CL: under 9.2 "provide user interface focus"?

PP: last issue for 9.1 -- for 9.2 issues are: are extensions to the user interface (chrome) considered part of the 'base' UA? Should extensions conform to UAAG? We think, yes. Does UAAG need addtional checkpoints to cover this? Will adding techniqes to cover this, change the scope of the checkpoint?

Definition of Content. Related to Compound Documents and DHTML/AJAX. Focus management between base UA and nested/child UA (Object, flash, mathml, svg). Also, applications within web content that create a new user interface. Is this new application with it's own user interface considered a new embedded UA that must conform to UAAG or just more content?

PP: any extensions to chrome should inform UAAG; base focus -- UA responsible if knows how to render widgets into its own chrome, knows what should receive focus

JA: and what hotkeys apply

PP: should be inspectable -- FF extensions written in same language (XUL)
... most other extensions not written with same code

JA: user interface -- rewrite note or include extensions to User Interface -- reword or note?

PP: reword -- might get lost in note

JR: 2 success criteria
... ensure user interface focus operates within chrome extensions; extends to chrome extensions?

JA: take out "to" and substitute "for"
... or "extensions to the user interface" avoids adding another term need to define

JR: authoring tool, UI applies to everything -- that's why use term "chrome"

PP: additional checkpoints? tied into whether going to mash into something larger

JA: created additional checkpoint

JR: going to publish new editor's draft

<JR> http://www.w3.org/WAI/UA/2007/WD-UAAG20-20071106/WD-UAAG20-20071106.html

JR: 9.x
... things in light pink are new; bold labeled where come from

GJR +1 to adding checkpoint

PP: are extensions to the user interface (chrome) considered part of the 'base' UA? Should extensions conform to UAAG? We think, yes. Does UAAG need addtional checkpoints to cover this? Will adding techniqes to cover this, change the scope of the checkpoint?

Proposals

PP: managing focus -- nested should move into it, but outer UA can't count on secondary UA to be focusable -- up to embedded player/UA to be focusable and manipulatable; would be good to provide an escape from widget/embedded UA

JR: right -- need to state explicitly

JA: what can parent UA do to get focus back from embedded UA

PP: not necessarily true

JA: true in flash

PP: if have something embedded in page, press tab, UA says "flash, focus moved to you" -- when reach last tabbable element in embedded UA take you out of embedded UA; relies on bi-directional communication -- UA still getting keystrokes before embedded UA gets them -- skip key (perhaps CONTROL TAB

JR: embedded UA a viewport -- escape from viewport key needed

JA: don't know if flash misbehaving or UA; update of flash, allows trickle back to parent
... user agent gets keystroke first and passes off to embedded document and then gets back

PP: could be browser dependent; if thing rendered inside browser, broswer should get first say

JA: chicken and egg problem -- CDF related

JR: user agent usually (in HTML) uses native keystrokes -- may be conflict with escape mechanism -- have to thread properly

JA: editor's note about compound document

<JR> User agent is responsible for notifying any nested user agent that focus should move into it

<JR> User agents must be able to escape focus from a nested viewport (including nested viewports that are user agents)

<scribe> ACTION: Jim to email CDF about threading [recorded in http://www.w3.org/2007/11/06-ua-minutes.html#action01]

PP: if treating embedded object as UA, embedded user agents need to communicate with primary UA

CL: not notification, just responsible for moving focus back

PP: flash can't move focus back, but can indicate that it is no longer needed

CL: HPR -- screenreader had to get focus back
... HPR knew what was going on
... UA would pass by flash, but now can tab into it -- API communication between flash and browser

JA: because embedded UAs don't use parent DOM, but use own or don't have one, imperative that API writes to DOM for AT use

JR: special guidance for embedded UAs?

JA: SVG has own dom, etc. don't write back to parent dom

JR: write to DOM
... if DOM in common use, write to it

CL: only applicable to HTML

JR: SVG renderer that embeds HTML - HTML viewer could write to HTML DOM

JA: have to write to Accessibility API

CL: if UA doing that, they are writing to a11yAPI -- authors not going to write to a11yAPI

JR: on IE, has to bring in viewer -- is HTML master of SVG? if SVG master and HTML embedded...

CL: code dependent

JR: little IE inside larger SVG UA -- writes to a11yAPI, but could also write to HTML DOM because well supported by AT

CL: can't write to HTML DOM in that case

JR: for HTML part of compound document; when user gets to HTML portion, uses HTML DOM

JA: realplayer user agent that plays movies and audio, but can also parse HTML, but not writing to a11yAPI -- AT knows nothing about what is occuring in viewport -- not writing to a11yAPI or DOM

CL: any kind of UA of any kind has to either write to a11yAPI or if HTML write to DOM

JR: why not say if technology has a DOM, then write to that

CL: not all DOMs have necessary API to communicate with AT

JA: flip side - firevox model -- extension

CL: writing to HTML DOM

JA: UA for SVG and write extension, UA has to put into SVG DOM

CL: desired trend is to write to accessibility API; HTML DOM needs to be retained --
... ideal is linux with no DOM

Doug Schepers (schepers@w3.org) staff contact for CDF and SVG and WebAPI

<scribe> ACTION: Gregory to contact Doug Schepers about multiple DOMs in CDF and embedded UAs [recorded in http://www.w3.org/2007/11/06-ua-minutes.html#action02]

JA: recylcable viewports -- with mouse can zoom in but couldn't resize viewport embedded in HTML

PP: covered 9.2

JA: what about outermost UA provide way to skip over misbehaving UAs -- solved with escape key?

PP: right

JA: plus one

<parente> what's going on?

<parente> couldn't hear that last bit

scribe's note: JA plus one applies to change to 9.3 first requirement; make explicit about moving content focus backwards and forwards, then cut out redundant checkpoint

<JR> please hold on

<JR> waiting for Zakim to call us back

PP: first sentence of note only
... second part see checkpoint 9.9 about structured navigation and other references still relevant

JR: [reads new verbiage]

<jallan> ACTION: JR to remove first sentence in 9.3 note. leave second sentence intact [recorded in http://www.w3.org/2007/11/06-ua-minutes.html#action03]

JR: combine movement forwards and in reverse into 1 checkpoint?
... [reviews http://www.w3.org/WAI/UA/wiki/NavMechanisms]
... repushes editor's draft to reflect changes
... color coding: pink means proposal, yellow means accepted
... visually and programmitically indicate text changes

<scribe> ACTION: GJR check and make suggestions for improving a11y of stylesheets [recorded in http://www.w3.org/2007/11/06-ua-minutes.html#action04]

PP: UA can't restore viewport/state history due to script or user-set override

JA: global setting

PP: add extensions to browser -- can effect viewport/state history

JA: UA settings, UA extensions, and scripts

JR: content, not so much UA settings

JA: order doesn't make difference

JR: content does it the most (breaking back button)

JA: order not important unless important to JR

JR: proposing a note

JA: notes are normative

PP: if the state has not been affected by content, user agent settings/exceptions, or scripts

JA: could add to provision 2

JR: [rereads from editor's draft]
... all we have to say is "in history/viewport mechanism only responsible for certain states

PP: things can get in way of operation, don't have to overcome that necessarily

JR: asking to retain viewport/history mechanism?
... are we saying need to have a back button for UAAG 2?

CL: thought req was somewhere else

[JR and CL search editor's draft]

CL: 9.10 perhaps?
... orient user under GL 10
... mentioned in passing in GL 10

JA: if no req to retain history don't have to say should

PP: why not?

CL: in GL10 itself -- need to examine GL as well as checkpoints

JA: not normative -- checkpoint provisions and notes are normative

CL: don't think GL10 verbiage normative?

JA: no

CL: then why is it here? that's where we mention it

JR: must have history when history is possible?
... user agent must provide viewport history mech that stores browsing states that are not changeable

JA: ok with that

JR: viewport mechanism for each state maintain info on POR, selection

JA: need good word for available states that are still valid -- bank account balance after paying bill, can't go back

PP: not "stale" -- that is technical term -- "the cache is stale"

JR: if remain viable (not affected by content, user agent settings, etc.)

CL: one concern about viewport history as requirement for UAs not think of as main browser -- applicable to multimedia players?

JA: or if opens a new window can't go back

JR: problem multimedia or embedding of multimedia -- multimedia doesn't have viable states

CL: play a number of videos, retains a list of videos and where stopped for each video? that's what checkpoint impllies

JA: if implements history mechanism
... page-based navigation

CL: not saying not possible, questioning whether should require it -- note sure is a11y issue
... return to page, tries to retain focus -- SR needs precise return to focus

JR: remove selection?

CL: might need selectable

JR: select text on page, changed page, return and no selected text

PP: agree with CL

JR: if listbox selected and move back will it retain selection?

CL: glossary definition

PP: google advanced search has bunch of dropdowns on giant form -- FORM retains state

JR: UA doing that?

PP: browser does it -- even with dummy forms

JR: form controls retain values

PP: can write script that overrides that action

CL: should apply to things that persist -- selections and clipboard don't persist

JR: remove selection?

CL: already says as part of state history have to retain POR and selection

JA: definition of selection

CL: selection includes indicators

JR: filling form field not a selection

JA: FF2 preserves selection when focus moved to another doc
... selected text on page -- IE doesn't retain info but FF2 does

<jallan> GJR: screen reader users, selects text virtually (in the screen reader buffer)

JA: scenario where cognative impaired need to go back to selection so know where left off

JR: POR and content focus one priority and selection another, lower priority

CL: multiple docs in Word -- things still selected when switch documents; not quite the same as UA, but same underlying concept

JA: something in DOM needs to know what is selected

CL: in IE not in DOM

PP: text selection not in DOM of FF

CL: FF using internal variable to retain select
... probably restoring selection from internal state

PP: not in DOM

JA: not in DOM, not in OS, returns us to question

CL: look at techniques for this one -- often times, things explained more fully in techs; more about forms and stuff in my opinion

JA: reads browser refresh - example technique 1
... if browser overwrites it is gone; prefer having it in checkpoint rather than burried in techniques

CL: need to do this a lot more -- look to techniques for context and fuller info

JA: 3 states allow user to configure

JR: all of these are "ifs"

CL: only if chose to implement feature

JR: probably already had in mind if dev

JA: not normative -- just suggestions;

CL: nothing about forms -- that's what i'm most concerned about

JA: differentiation between normative and informative sections

CL: selection

JR: proposed bring in PP's stuff with viable states; keep JR's previous suggestion (if support history, support) and POR and content focus might be P1; selection might be P2
... combine restore verbiage
... still have original wording (marked as such)

CL: POR perspective

JR: POR (point of regard) where you are at present moment

CL: if select a section using the keyboard and move POR from selection, selection would go away
... selection is marking your point of regard (POR)

PP: 9.4.1 new wording question

CL: use keyboard to select

JA: selected with keyboard; shift-tab away, return

CL: don't use mouse

JA: cursor browsing on in FF select text from keyboard -- when do SHIFT + TAB selection vanishes; if select with pointer/mouse, select persists

CL: if leave selection and ALT + LeftArrow -- can mark POR

JR: selection is one place, focus another, POR on a third; activate link with focus; return with focus and selection

JA: failing the keyboard -- only works with mouse

CL: glossary contradictory
... one selection -- assuming that requirement if only 1 selection
... selection there important for history purposes is POR

JA: keyboard processing broken

CL: want to enable you to return where you were -- doesn't care if have selection
... some cases POR will be marked to select text

JR: using keyboard

JA: virtual cursor remembering where you were

JR: selection persists when use mouse

JA: keyboard interface -- either focus or selection or POR -- only going to inform what was last focused; if something highlighted, going to remember; if just in a position with no focus and selection remembers where caret was
... when come back, returns to one that is currently active; mouse can give you all 3 states
... distinguish between keyboard and mouse? where you left off is important state-holder

JR: want to come back to one of 3 -- which? POR?

CL: POR really covers it according to glosary def

JR: only maintaining POR

JA: most important one; POR most important no matter how browser handles POR

CL: intent is purely about POR

JA: agree

GJR: if POR equals virtual caret ok

PP: looks fine to me

<jallan> GJR: agree that point of regard is most important, want to return to same point in page.

LUNCH BREAK!!!

pick up on 9.5 in 30 minutes -- CL leaving now, PP meeting at 2pm

<JR> We're starting in a minute

<parente> dialing in now

<jallan> PP: what we really want to say is 'don't change focus on a change of focus'

<jallan> PP: don't want to block all event handlers

<jallan> PP: allow configuration so that moving the content focus to or from an enabled element does not cause the UA to change.

<jallan> ... if a script is on the newly focused element, the UA doesnot know what a script will do

<jallan> ... the UA should allow the event handler to execute

<jallan> JR: what are the things we don't want the UA to do

<jallan> PP: give focus, call event handler.

<jallan> ... anything beyond that is not up to the UA it is content driven.

<jallan> PP: this totally changes this checkpoint.

<jallan> PP: firevox does focus tracking by looking at on-focus events.

<jallan> PP: UA still cannot tell what what an event hander will do for on-focus.

<jallan> ... the UA can only move focus, any event is outside UA control

<parente> http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets#Use_onfocus_to_track_the_current_focus

<jallan> JR: cannot control for bad authoring. that is a WCAG issue.

<JR> Allow the user to activate, through keyboard input alone, all input device event handlers that are explicitly associated with the element designated by the content focus.

<JR> In order to satisfy provision one of this checkpoint, the user must be able to activate as a group all event handlers of the same input device event type. For example, if there are 10 handlers associated with the onmousedown event type, the user must be able to activate the entire group of 10 through keyboard input alone, and must not be required to activate each handler separately.

<jallan> JR: this is related to 1.2 event handlers

<jallan> JR: need to add event handers include "on-focus" events. so user must explicitly execute on-focus events.

<jallan> JR: move provision 9.5.1 to be part of 1.2.1

<jallan> PP: not sure this helps the screen reader. the UA must block on-focus events.

<jallan> JR: this may be a P2

<jallan> PP: this should be possible, just who is responsible

<jallan> JR: Move 9.6.1 to 1.2

<jallan> JR: must show events (9.6.1) before you can trigger them (9.5) - both moved to 1.2

<jallan> PP: 9.7 already done

<jallan> PP: 9.8 review issues

<jallan> PP: review proposals

<jallan> ... Whether conditional content is rendered or not, it should be searched if it's intended for human consumption, exists in the markup of the page, and is not hidden via a style attribute.

<jallan> PP: proposal should be searchable.

<jallan> JA: if hidden and you search, where should the point of regard appear?

<jallan> PP: where ever the pointer is in the DOM, if alt on image, the search finds the image. if hidden by css off top of screen, move point of regard to top of screen.

<jallan> PP: correction, regardless of css positioning, the point of regard should match the location on the page in the dom.

<jallan> JR: why say "if hidden by style"

<jallan> JR: then say "within rendered text and text alternatives"

<jallan> http://www.w3.org/WAI/UA/2007/WD-UAAG20-20071106/WD-UAAG20-20071106.html

<jallan> PP: 9.9 UAAG issues # Change "allow" to "provide", structured navigation should be provided natively, not added on by AT.

<jallan> # Issue/Technique: add technique or requirement stating that UA must provide object attributes (element name and roles, etc.) to the accessibiltiy API to enable structured navigation function by AT

<jallan> KF: a screen reader user uses a different viewport, so structured navigation provided by the UA is not relevant

<jallan> KF: how to synch screen reader viewport with the UA viewport

<jallan> ... using JAWS and you hit ctrl-f, you are using JAWS find not UA find

<jallan> KF: screen reader searches through the alternative view not the visually rendered view, and will not get all of the highlighted found items.

<jallan> ... screen reader should be able to list all of the found items and surrounding text to the user.

<jallan> ... don't know hwere to draw line, who should provide the enhanced visual view to the AT.

<jallan> PP: so the UA is not writing the found information to the DOM or a11yapi for the AT

<parente> i have to head out to another meeting

<parente> i'll keep this window open to track

<jallan> KF: UAs doing more with rendered text, need to give more guidance to alternative views.

<jallan> JA: just tested, UA only highlights first instance.

<parente> jallan: some extensions higlight multiple

<parente> e.g. Google Toolbar

<jallan> KF: but the feature exists. views are getting richer. How does UAWG provide guidance to AT for richer alternative views

<jallan> KF: info must be communicated some way...DOM or a11yapi.

<jallan> Peter, what are your thoughts

<jallan> KF: same thing is true in structured navigation. but reversed...AT has richer navigation than UA

<JR> JA: So put of regard has moved in DOM

<JR> JA: AT could then move to that point and do something

<JR> JA: So if browser does h=next header

<JR> JA: And Jaws could do nothing

<JR> JA: But if IE did a q=next quote then JAWS could use the feature

<JR> KF: We have struggled with this a lot - features we want to add - with this alternat viewport going on.

<JR> ACTION: KF to Re-raise alternate view at call on Nov 22 [recorded in http://www.w3.org/2007/11/06-ua-minutes.html#action05]

<parente> when any browser feature that moves the point of regard is actived, that information has to be communicated via DOM + A11y API

<JR> JA: Historically we did get a lot of structured nav push back in uaag1

<JR> KF: From end user perspective, having struct nav on headers, list, tables has made a huge difference

<JR> KF: Who does this other than ATs?

<jallan> JR: not so much mouse user, but for keyboard, screen mag users.

<JR> JA: Opera

<JR> KF: Don't know about Opera and AT support

<parente> Some extensions to FF

<parente> (or at least it's conceivable)

<JR> JA: Opera may be missing MSAA

<JR> JA: We'll pick this up later

<JR> JA: PP said there are extensions for struct nav

<jallan> UIUC accessibility extensions do this.

<jallan> and WAT toolbar in IE

<JR> JA:We'll leave 9...

Guidelin 7

<JR> KF: http://lists.w3.org/Archives/Public/w3c-wai-ua/2007OctDec/0043.html

<JR> JA: This should be moved to GL1...

<JR> JA: We've been consolidating the doc...

<JR> JA: My thought on 7.1 is that we are trying to get content selection from the keyboard

<JR> JA: It's got to work from whatever content selection...

<JR> KF: Historically Windows good about text selection, but browsers haven't

<JR> KF: Fine to move it up

<JR> KF: Browsers doing that now with browsers

<JR> KF: nytimes lets you doubleclick on any word and look it up

also highlights for spelling errors in checkboxes -- native in FF, but not programatically expressed

substitute edit boxes/textareas for checkboxes

<jallan> JA: tried in FF from keyboard, highlight word, hit enter, no action taken by UA

have only been able to do when someone tells me a word is underlined, then route cursor to underlined word and simulate a right-mouse click

exposes suggestions

<jallan> KF: does not work with a screen reader, unless mouse cursor used

<jallan> ... user agent accessibility: 1-basic OS keyboard, highcontrast, etc. 2. a11y apis, 3. for some folks, using AT.

<jallan> ... UAAG provide guidance for AT. but as UA become more robust, and new platforms, web apps.

<jallan> ... The UA is adding much more robust experience. UAWG needs to provide more guidance to get same/similar experience for the AT users.

<jallan> KF: example. in Vista. search box. start | search - when you start typing the search results start updating immediately,

i assume that the underlining (as in the FF example) is achieved through scripting and not included in dom -- needs to be communicated to a11yAPI

<jallan> ... this is following the apis etc. and should be accessible. AT is reading the highlighted item as it changes rather than the search box which has topic

<jallan> ... the AT stepped up, to do this. How does UAWG provide this guidance.

<jallan> KF: as UA developer works with UA...remember the end user experience, not just the data model. Are you exposing the "right" information to enhance the AT user experience

if draw to screen/canvas need to programmtically indicate state/change to a11yAPI

<JR> KF: Not sure how this all comes together into a guideline doc

<JR> JA: in google there is the same type of type-ahead thing

<JR> FF-instant answers

<JR> GR: Some older implementations are annoying because they actually do the completion as you go along and can mess up what you are looking for

can only get to FF3 search context info by reviewing status line - either no match or reached end of page, continued from top

<JR> KF: Has to go look to see where this is

ARIA would enable AT to say "dropdown available"

what's needed is 3 states: expose, examine (without acting), perform action

<JR> JA: So out of box, applications work a certain way, then some features become popular then AT's support them better

<JR> JA=KF

<JR> JA: THat's what UAAG is about if someone would follow them.

server would have to implement ARIA, of course

<JR> JA: Some widegets like search bar can be HTML

<JR> GR: Lots of middleware uses XML

<JR> GR: But wrapped in HTML at last minute

<JR> KF: RIght then back into a win32 control (in FFwin google bar example)

<JR> JA: Anything more for 7?

AT needs to know that a combo box (no matter how defined) is a combo box and communicate that to end-user

<JR> KF: Are we talking about getting rid of 7?

<JR> JA: JR was saying we moved selection part of 7.1 to 1.X

<JR> JA: But still 2 other parts - other focus...

<jallan> KF: 7.2

<jallan> ... using cell phone, with voice input. new version of lsearch for mobile phones using voice input (but you have to press a key to activate voice search feature).

<jallan> ... need to pay attention to how to separate voice input to the phone from voice input to application.

7.3

<JR> JR: Mentions keyboard access, overlaps 7.2

<JR> KF: Just saying do what you have to do to be accessible

<JR> JA: Good idea to look at techs before we start changing things

<JR> JA: Interesting note, Jaws can't be used with sticky keys since Insert is not sticky keys

<JR> KF: Good point about following operating environment...and techniques are important to keep

<jallan> JA: we've already moved 7.1 and 7.2 should we move 3 and 4 somewhere else

<jallan> KF: OS has expected behaviors for accessibility, don't mess with them.

<jallan> JR: would not be a bad thing to restate 1.x into a respecting OS guideline.

<jallan> JR rerwwriting 7.x and refershing

<jallan> refershing=refreshing

<jallan> JA: in PF yesterday, order of precedence says the OS gets the key first.

<jallan> KF: can't rely on that, screen readers for example hook into the OS at the keyboard level

<jallan> ... so the screen reader can use OS tools.

<jallan> JA: so we should keep this CP, the remind developers NOT to use reserved keys.

<jallan> KF: everything in this GL is good software design. be a good neighbor

<KFord> ssEverything here is really good software design. Play nice in the neighborhood you live.

<jallan> JR: publish new draft, reviewing changes...

<jallan> ACTION: KF to email GR, create schema for editing changes [recorded in http://www.w3.org/2007/11/06-ua-minutes.html#action06]

<jallan> discussing changes to 2.3 http://lists.w3.org/Archives/Public/w3c-wai-ua/2007OctDec/0038.html

<jallan> JR publishes a new draft to review 2.3

<jallan> JR: reads conditional content definition.

<jallan> ... this is inadequate. any content meets this definition.

<jallan> ... need something new.

<jallan> JR: perhaps we don't need a configuration

<jallan> ... the user should be able to access all pieces of conditional content.

<jallan> JA: when? and How?

<jallan> JR: that is a UI question.

<jallan> JR: so provision 2 etc. explains how and why.

<jallan> ... removing letters 'C' and 'D' replace with real words...conditional content, base content.

<jallan> JR: what if there is more than one piece of conditional content?

<jallan> JR: what if conditional content is larger than base content, or is not physical e.g. sound

<jallan> ... large alt on small image, or a sound replaces an image

<jallan> all: reviewing 2.3 - ???

<jallan> JA: perhaps, we need to create a new list of what we want to happen, and them match up or replace current wording.

<jallan> ... if current wording is so confusing, then...

<jallan> KF: user cannot deal with base content

<jallan> ... want access to any and all replace contnet

<jallan> ... move between them

<jallan> ... configure a default replace ment

<jallan> ... without refreshing page, go back to base content

<jallan> JA: if conditional content is visible then it becomes the base content, and original base content should show in the list of conditional content the user can choose from

<jallan> JR: there is a stack of content (base + conditionals)

<jallan> ... user should be able to have access to all conditionals that the UA can understand (render or call a plug-in)

<jallan> ... user should be alerted to the presence of other non-rendered conditional content

<jallan> ... given a stack, the user preferred item(s) should be rendered

<jallan> ... user should be able to have access (step through)

<jallan> JR: how to render conditional content that is 'larger' than space provided for base content.

<jallan> ... how to render multiple condtionals simultaneously

<jallan> from techniquest for 2.3 For an object (e.g., an image) with an author-specified geometry that the user agent does not render, allow the user to configure how the conditional content should be rendered. For example, within the specified geometry, or by ignoring the specified geometry altogether.

<jallan> ja: discuss size issue

<jallan> JR: if voice browser. ALT size not a concern

<jallan> JA: if text only UA ALT size also not a concern.

<jallan> JA: UA with images off may truncate ALT.

<jallan> JR: the user should have option of deciding if the base dimensions should be ignored.

<jallan> JR: if the conditonal content is plain text then the userr should have the option of having it not displayed onscreen but rather in the DOM title

<KFord> I'm not sure why you don't hear me, but I'm still here.

<jallan> JR: we are talking about stepping through

<KFord> Right, I hear you just fine.

<jallan> JA: scenario: have image on page, screen reader reads alt, indicates additional content, hit a key context menu opens with title: title contents

<jallan> ... longdesc that is an actionable link, and

<jallan> ... the alt again.

<jallan> ... this could also work for a keyboard user without AT, UA inserts a placeholder as an indicator for more conditional content so

<jallan> ... user can get same menu with all conditionals listed

<JR> User should be able to have access (step through) to any items in a "conditional content stack" that the user agent can understand.

<JR> Given a stack, the user preferred items should be rendered

<JR> User should be alerted to the presence of other non-rendered items in the stack

<JR> If the conditional content has larger onscreen dimensions than the top item in the stack, the user should hvae the option of deciding if the dimensions should be ignored

<JR> If the conditional content is plain text then the user should have the option of having it not display onscreen but rather in the DOM title.

<jallan> JR: problem now, can;t get title and alt at the same time with the screen reader

<jallan> ... is this an msaa issue,

<jallan> KF: msaa gives a name to an object and have roles.

<jallan> ... on html element x map it from this tag

<jallan> JR: idea of cycling through a stack of conditionals.

<jallan> ... have image, tooltip of of alt

<jallan> KF: in msaa tree image link has 2 children

<jallan> ... name becomes alt

<JR> JA: What if it has a title?

<JR> KF: Could we make another child -yeah.

<JR> JA: Is MSAA the prob for JAWS?

<JR> KF: No that's JAWS thing

<jallan> JR: thinking about collisions, on screen

<jallan> ... things get messy, have movie, image, alt, longdesc

<jallan> ... how to put them all on the screen at the same time, difficult to put movie and image on screen at the same time.

<jallan> ... if don't want to change dimensions, difficult to put image and alt on screen simultaneously.

<JR> JA: Currently can have img and alt at the same time

<JR> KF: Are we getting too bogged down

<jallan> JR: yes, getting bogged down, concerned about the media with multiple caption, and audio tracks. only show one of each but not multiples

<JR> JR: Idea of complimentary conditional content

<jallan> JA: how to say with a movie...only allow selection of one caption and one audio track at a time to play with the movie

<jallan> JR: have a SMIL, with video with english and spanish audio, with english audio description

<jallan> .... the english and english audio description track can play well together.

<jallan> ... spanish track and english audio may not play well because of timing.

<JR> KF: Maybe ok not to cover this right now

<jallan> KF: this is an issue, but may not be critical to this CP

<JR> ACTION: JR to To follow up on 2.3 and make proposal. [recorded in http://www.w3.org/2007/11/06-ua-minutes.html#action07]

<KFord> IE web developer toolbar:

<KFord> http://www.microsoft.com/downloads/details.aspx?FamilyID=E59C3964-672D-4511-BB3E-2D5E1DB91038&displaylang=en

<jallan> no conference all this week 11/8, next call 11/15

- DRAFT -

WAI UA

6 Nov 2007

Attendees

Contents

Section 9

Guidelin 7

7.3

Summary of Action Items

Scribe.perl diagnostic output