See also: IRC log
<JR> Scribe: JR
JA: PF thoughts?
CL: We really do need a Charles or Aaron type person
JA: JR and I talking about
... If they don't want to do it maybe we can put it in as P3
irc.w3.org, port: 6665, channel: #ua
<jallan> CL discussing 6.7 - order of key execution.
<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?
<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!)
<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
<jallan> add to 1.1
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> 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
JA: We've been making reasonable progress.
PP: Most sections in GL9 had
... Need to update defn of enabled and interactive
<oedipus> scribe+ oedipus
<oedipus> scribe: oedipus
PP: anything can receive focus or
... 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
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
JA: UA put focus back, or does author have to programmatically indicate
JA: taking out of task order -
can't just focus unless author provides mechanism to give
... 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
... 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
... 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?
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: 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
... 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 (firstname.lastname@example.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?
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
... 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
... 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
... 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?
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
... page-based navigation
CL: not saying not possible,
questioning whether should require it -- note sure is a11y
... 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
... 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
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
... 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
... 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
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.
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
<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> 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...
<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
<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: 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.
<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> 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:
<jallan> no conference all this week 11/8, next call 11/15
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 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 Found Scribe: oedipus Inferring ScribeNick: oedipus Scribes: JR, oedipus ScribeNicks: JR, oedipus Default Present: pparente, Gregory_Rosmaita, MediaRoom Present: pparente Gregory_Rosmaita MediaRoom Agenda: http://www.w3.org/WAI/UA/2007/nov2007_ua_meeting.html#agenda Got date from IRC log name: 6 Nov 2007 Guessing minutes URL: http://www.w3.org/2007/11/06-ua-minutes.html People with action items: gjr gregory jim jr kf WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]