W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2007

full minutes 11-6-2007

From: Jim Allan <jimallan@tsbvi.edu>
Date: Tue, 06 Nov 2007 16:33:16 -0600
To: "'WAI-ua'" <w3c-wai-ua@w3.org>
Message-id: <000201c820c5$066e30b0$134a9210$@edu>

6 Nov 2007


See also: IRC log

    pparente, Gregory_Rosmaita, MediaRoom
    Jim Allan
    JR, oedipus


    * Topics
         1. Section 9
         2. Guidelin 7
         3. 7.3
    * Summary of Action Items



<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


<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

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

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

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

<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

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


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

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

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

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

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

JA: created additional checkpoint

JR: going to publish new editor's draft


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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.


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

<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

<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

<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

<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

<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

<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

<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

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

<jallan> JR rerwwriting 7.x and refershing

<jallan> refershing=refreshing

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

<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

<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

<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

<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

<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

<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

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

<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

<KFord> IE web developer toolbar:


<jallan> no conference all this week 11/8, next call 11/15
Summary of Action Items
[NEW] ACTION: GJR check and make suggestions for improving a11y of
stylesheets [recorded in
[NEW] ACTION: Gregory to contact Doug Schepers about multiple DOMs in CDF
and embedded UAs [recorded in
[NEW] ACTION: Jim to email CDF about threading [recorded in
[NEW] 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]
[NEW] ACTION: JR to To follow up on 2.3 and make proposal. [recorded in
[NEW] ACTION: KF to email GR, create schema for editing changes [recorded in
[NEW] ACTION: KF to Re-raise alternate view at call on Nov 22 [recorded in
[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/11/06 22:28:11 $
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]

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]

Jim Allan, Webmaster & Statewide Technical Support Specialist 
Texas School for the Blind and Visually Impaired 
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
>>> Share to Win! <<<
Received on Tuesday, 6 November 2007 22:34:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:51:50 GMT