- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Tue, 06 Nov 2007 16:33:16 -0600
- To: "'WAI-ua'" <w3c-wai-ua@w3.org>
W3C
- DRAFT -
WAI UA
6 Nov 2007
Agenda
See also: IRC log
Attendees
Present
pparente, Gregory_Rosmaita, MediaRoom
Regrets
Chair
Jim Allan
Scribe
JR, oedipus
Contents
* 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
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?
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?
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
Summary of Action Items
[NEW] ACTION: GJR check and make suggestions for improving a11y of
stylesheets [recorded in
http://www.w3.org/2007/11/06-ua-minutes.html#action04]
[NEW] 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]
[NEW] ACTION: Jim to email CDF about threading [recorded in
http://www.w3.org/2007/11/06-ua-minutes.html#action01]
[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
http://www.w3.org/2007/11/06-ua-minutes.html#action07]
[NEW] ACTION: KF to email GR, create schema for editing changes [recorded in
http://www.w3.org/2007/11/06-ua-minutes.html#action06]
[NEW] 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]
[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 UTC