irc logs from f2f part 1

Status#uaX[Master Draft ->
http://www.w3.org/WAI/UA/2011/ED-UAAG20-20111103/MasterUAAG20111103.html][20:52]
== jallan [qw3birc@128.30.52.28] has joined #ua[20:52] == Admin
[chatzilla@63.145.238.4] has joined #ua[20:52] <jeanne> chair: Jim,
Kelly[20:52] <jallan> scribe: jallan[20:52] <jeanne> present+ Kelly,
Mark, Jim, Greg, Kim, Jeanne, Jan[20:53] <jallan> kelly: reviewing
agenda[20:53] <kford> Latest draft.[20:53] <kford>
http://www.w3.org/WAI/UA/2011/ED-UAAG20-20111104/MasterUAAG20111104.html[20:57]
<jallan> Topic: 4.1.1 platform a11y architecture[20:57] == greg
[chatzilla@63.145.238.4] has quit [Ping timeout][20:58] <jallan> greg:
details of how to support this are in other SC. 411 may be considered
redundant...or[20:58] == greg [chatzilla@63.145.238.4] has joined
#ua[20:58] <jallan> kim: it sets the stage.[20:58] <greg> Kelly is
concerned that 4.1.1 Platform Accessibility Architecture is
vague.[20:59] <greg> Greg says it could b considered redundant to the
other 4.1.x that require platform accessibility API usage.[21:00]
<Jan> FYI: ATAG2 says: A.1.2.2 Platform Accessibility Services:
Non-web-based authoring tools implement communication with platform
accessibility services. (Level A)[21:00] <jallan> jim asks about
current a11y architecture support in current browsers[21:00] <jallan>
411 OK[21:01] <jallan> jim +1 to ATAG communication[21:01] == Ruinan
[sunruinan@63.145.238.4] has joined #ua[21:03] <jallan> js: web-based
players (embedded) may be talking to the a11y arch. directly[21:03]
<Jan> Note: In ATAG 2.0, some success criteria require authoring tools
to make certain information programmatically determinable. In cases
where the platform lacks a platform accessibility service, these
success criteria are to be considered "not applicable". Conformance
claims are optional, but any claim that is made must record the
platform and the fact that the platform does not include a...[21:03]
<jallan> greg: in ISO scoped the beginning of this section. If you are
on a platform that does not have an a11y arch. then this does not
apply[21:03] <Jan> ...platform accessibility service.[21:04] <greg>
ISO 9241-171 8.5.1 General: The provisions in this section are
intended to provide the information and programmatic access needed by
assistive technologies to help users access and use software. These
provisions only apply to systems that allow installation of assistive
technology or where AT will be installed in conjunction with the
software. They are not applicable to closed systems (see 7.2).[21:06]
<jallan> make it a no add a scoping note at the top of the
document.[21:07] <greg> General scoping/exception for SC that are not
relevant to your platform (e.g. color on audio output, AT compat on
closed systems).[21:07] <jallan> kf: where the platform support an
platform a11y api then use it, if you don't support it you must make
one.[21:08] <jallan> action: kelly to write a scoping NOTE about
Guideline 4.1[21:08]  * trackbot noticed an ACTION. Trying to create
it.[21:08] <@trackbot> Created ACTION-647 - Write a scoping NOTE about
Guideline 4.1 [on Kelly Ford - due 2011-11-11].[21:08]  * RRSAgent
records action 1[21:08] <jallan> rrsagent, make minutes[21:08]
<RRSAgent> I have made the request to generate
http://www.w3.org/2011/11/04-ua-minutes.html jallan[21:09] <jallan>
topic: 412 name, role, state, value, description[21:09] <Jan> Action:
JR to propose a conformance applicability note re: platform and device
constratins (eg. lacking platform accessibility service, monochrome
screen)[21:09]  * trackbot noticed an ACTION. Trying to create
it.[21:09]  * RRSAgent records action 2[21:09] <@trackbot> Created
ACTION-648 - Propose a conformance applicability note re: platform and
device constratins (eg. lacking platform accessibility service,
monochrome screen) [on Jan Richards - due 2011-11-11].[21:10] <jallan>
kelly: votes no, concept is good, lmay not be right bulleted
list[21:10] <jallan> mh: could agree[21:11] <jallan> kelly: other
platforms may have these but called other names, or the may have
others that are also necessary[21:11] <jallan> kf: the list may need
to be different.[21:12] <jallan> jan: the list is prescriptive.[21:12]
<jallan> kf: goal is that the user can determine what something is and
how to use it[21:13] <jallan> gl: goal - ua and generated
content...should be in the dom, other spec were ambigious[21:13]
<jallan> kf: msaa uses these labels, UI automation has different names
and concepts.[21:14] <jallan> action: kelly to rewrite in modern terms
(genericize) 4.1.2 with greg[21:14]  * trackbot noticed an ACTION.
Trying to create it.[21:14]  * RRSAgent records action 3[21:14]
<@trackbot> Created ACTION-649 - Rewrite in modern terms (genericize)
4.1.2 with greg [on Kelly Ford - due 2011-11-11].[21:15] <greg> That
is, being specific avoids having user agents failing to implement
minimal things because the spec is too vague, the example being UA
faiing to expose generated content just like they don't copy it to the
clipboard.[21:15] <jallan> topic: 413 Accessible Alternative[21:15]
<jallan> jeanne, jan, kelly +1[21:17] <jallan> jan: some cool
drag/drop interface can make it work in platform a11y api,[21:18]
<jallan> topic: 414 programmatic availability of doms[21:18] <jallan>
all ok[21:19] <jallan> jim: generated content does not appear in the
DOM[21:19] <jallan> kf: need to check in HTML 5[21:19] <jallan>
action: jim to review generated css content in html5[21:19]  *
trackbot noticed an ACTION. Trying to create it.[21:19]  * RRSAgent
records action 4[21:19] <@trackbot> Created ACTION-650 - Review
generated css content in html5 [on Jim Allan - due 2011-11-11].[21:20]
<jallan> topic: 415 write access[21:20] <jallan> jan: didn't ARIA say
they did not want write[21:21] <jallan> ... AT wants to check a check
box, don't send command to the UA, write to the DOM[21:21] <jallan>
there is an action and issues related to this[21:21] <jallan> all
NO[21:21] == jallan [qw3birc@128.30.52.28][21:21] ==  realname :
63-145-238-4.dia.static.qwest.net/63.145.238.4 - h[21:21] ==  channels
: #ua[21:21] ==  server   : irc.w3.org [W3C IRC server][21:21] ==
idle     : 0 days 0 hours 0 minutes 4 seconds [connected: Fri Nov 04
10:52:27 2011][21:21] == End of WHOIS[21:22] <greg> The title doesn't
match the body of the SC, which is not related to write access.[21:23]
<jallan> topic: 416 properties[21:23] <jallan> kelly: this needs work,
to specific[21:25] <jallan> kf: stem is vague[21:25] <jallan> jan:
reviews the content[21:26] <jallan> kf: is this the right laundry
list. what is general goal.[21:26] <jallan> kf: classic argument. the
ADA was passed before the internet so it doesent apply[21:27] <jallan>
gl: the list is a minimum,[21:27] <jallan> ... if you want to argue
that it be vague, then how to check compliance[21:28] <jallan> mh:
similar to 412, perhaps remove and beef up 412[21:28] <jallan> kf:
+1[21:29] <jallan> action: kelly to combine 412 and 416, with
Mark[21:29]  * trackbot noticed an ACTION. Trying to create it.[21:29]
 * RRSAgent records action 5[21:29] <@trackbot> Created ACTION-651 -
Combine 412 and 416, with Mark [on Kelly Ford - due
2011-11-11].[21:30] <jallan> short discussion of msaa, IA2, UIA, other
platforms[21:30] <jallan> jan: the items in 416 are very basic, and
won't go away[21:30] <jallan> kf: we don't want to leave anything
out[21:30] <jallan> gl: need a balance.[21:31] <jallan> topic: 417
timely communication[21:31] <jallan> jan: does this need to be
said[21:32] <jallan> ... what is the rate...10 milliseconds? it is
vague[21:32] <jallan> gl: efficiency, 200 api calls.[21:32] <jallan>
kf: leave it in, an easy win[21:33] <jallan> jan: testing compliance,
do you name the AT and record time?[21:34] <jallan> gl: say something
in the intent on how we expect it to be tested. new update to the
screen,[21:34] <jallan> kp: we do speed tests with speech software.
this is important[21:34] <jallan> on of the most practical tests is
cursor blink rate (max of 2)[21:35] <jallan> present+ John[21:35]
<jallan> kf: this is tough to measure.[21:36] <jallan> editors note
applies to this[21:36] <jallan> topic: 421 hands-off focus[21:36]
<jallan> gl: not convinced for the need for this.[21:37] <jallan> jan:
you need to be able to move focus to nested UA.[21:37] <jallan> gl: it
does not say this.[21:37] <jallan> js: john are there nested UA in
mobile[21:37] <greg> that is, I think things have to implemented this
way regardless of accessibility concerns.[21:38] <jallan> john: yes,
moving toward nested UA.[21:39] <jallan> john: flash, get out of UA,
open new app (Flash) then runs content. if you close browser, the
flash wont close[21:39] <jallan> jan: there are implementations that
this is not true.[21:39] <jallan> discussion 421-3[21:40] <jallan> gl:
423 very necessary - return focus[21:41] <jallan> gl: if nested,
should return[21:41] == JohnS [qw3birc@128.30.52.28] has joined
#ua[21:41] <jallan> kf: need review,[21:41] <jallan> gl: 422 user can
do something, 423 UA can do something.[21:43] <jallan> 422 implies
423[21:43] <jallan> related to 212, 213, 221, 222[21:44] <jallan>
killing 423[21:44] <jallan> return focus[21:44] <jallan> need to
review the GL2 items before setting action for 421, 422[21:45] <greg>
We might end  up moving 4.2.2 Retrieve Focus but note it's not just
about keyboard.[21:45] <jallan> topic: 511 non-web-based
accessible[21:46] <Jan> ATAG2: Non-web-based authoring tool user
interfaces follow user interface accessibility guidelines for the
platform.[21:46] <jallan> every platforms has a11y guidelines, follow
them[21:47] <jallan> kelly: borrow ATAG language[21:47] <Jan> A.1.2.1
Accessibility Guidelines: Non-web-based authoring tool user interfaces
follow user interface accessibility guidelines for the platform.
(Level A)[21:47] <jallan> Non-web-based user agent user interfaces
follow user interface accessibility guidelines for the platform[21:48]
<jallan> john: is this really necessary[21:49] <jallan> gl: windows
a11y guidelines say have underline letters, if a UA doesn't do this,
you are getting a pessimal experience[21:50] <jallan> john: it is
users choice to install a browser.[21:51] <jallan> john: the way it is
written, sounds like it could apply to non UAs[21:51] <jeanne>
rrsagent, do not start a new log [at midnight][21:51] <RRSAgent> I'm
logging. I don't understand 'do not start a new log [at midnight]',
jeanne.  Try /msg RRSAgent help[21:51] <jallan> jan: we have a
definition of a UA[21:53] <jallan> shadi: definition of UA. big
concerns. Inherited from WCAG...UA anything that renders
webcontent...webcontent is anything that is rendered in a
browser[21:53] <jallan> ... definition of extension and AT are very
similar[21:53] <jallan> definitions are not clear.[21:54] <jallan> 3
types of user agents[21:54] <greg> John has a valid concern that our
SC should not prevent the user from getting the experience they want,
e.g. if the user wants a browser that gives a more Mac-like experience
even on Windows (e.g. no underlined access keys) they should be able
to have that. Thus we use a lot of language about user choice rather
than requiring "always" behaviors.[21:54] <jallan> jan: we may decide,
scope it to only be desktop[21:54] <jallan> shadi: why[21:55] <jallan>
jan: don't need web-based UA, because they fall under WCAG[21:56]
<jallan> shadi: functional requirements need to be the same.[21:57] ==
Ruinan [sunruinan@63.145.238.4] has quit [Quit: Ruinan][21:57]
<jallan> shadi: AT that renders web content to help the user[21:57]
<jallan> kelly: webanywhere,[21:58] <jallan> shadi: NPII, more
webbased tools, part of the tools that will be used[21:58] <jallan>
shadi: the more definitions you have the more stuff can fall between
the cracks[21:59] <jallan> jan: UAAG has 100+ SC, don't expect from
every browser.[21:59] == chsiao [chatzilla@63.145.238.4] has quit
[Ping timeout][21:59] <jallan> shadi: web-based UA, interaction is not
passed directly from the UA[22:01] <greg> Jim: notes that single
purpose airline scheduling apps on his phone talks via internet to a
specific server to get specific information, displays a very limited
set of data, is it a user agent? Some say yes, some no it's a web
service.[22:02] == Ruinan [sunruinan@63.145.238.4] has joined
#ua[22:04] <jallan> kelly: similar to 332[22:05] <jallan> js: propose
using ATAG wording[22:05] <jallan> Non-web-based user agent user
interfaces follow user interface accessibility guidelines for the
platform[22:05] <jallan> stem change: Follow A11y Guidelines[22:07]
<jallan> gl: there may be conflicts with other guidelines. should have
something in the doc, that says if there are conflicts UAAG
overrules[22:08] <jallan> john: problems with that. 3rd party
developers. may not be familiar with all the platform spec, let alone
UAAG guidelines.[22:08] <jallan> ... who decides whats a
conflict.[22:08] <jallan> ... understand why it is here....[22:09]
<jallan> ... creates a lot of cases where it hurts the user.[22:09]
<jallan> jan: don't agree where UAAG should overrule...[22:09] ==
RRSAgent [rrs-loggee@128.30.52.169] has quit [Client exited][22:10] ==
RRSAgent [rrs-loggee@128.30.52.169] has joined #ua[22:10] <RRSAgent>
logging to http://www.w3.org/2011/11/04-ua-irc[22:10] == RRSAgent
[rrs-loggee@128.30.52.169] has quit [Client exited][22:10] == No such
nick/channel: rrsagent[22:10] <greg> jan: in some cases platform
guidelines may be necessary for acc on that platform, we would not
want to interefere with that.[22:10] == RRSAgent
[rrs-loggee@128.30.52.169] has joined #ua[22:10] <RRSAgent> logging to
http://www.w3.org/2011/11/04-ua-irc[22:10] <jallan> rrsagent, make
minutes[22:10] <RRSAgent> I have made the request to generate
http://www.w3.org/2011/11/04-ua-minutes.html jallan[22:11] == RRSAgent
[rrs-loggee@128.30.52.169] has quit [Client exited][22:12] <jallan>
kf: msn explorer,  at the time all applications had menu bars. but was
designed specifically without menu bars in direct conflict with
platform a11y aps[22:12] <jallan> jan: specs should not say 'thou
shalt not have menubars[22:12] == RRSAgent [rrs-loggee@128.30.52.169]
has joined #ua[22:12] <RRSAgent> logging to
http://www.w3.org/2011/11/04-ua-irc[22:12] <greg> Greg: an example of
where we might want our standard to take precedence over other cited
standards would be that we may say generated content be available
through the DOM where CSS says it should not be.[22:13] <jallan> john:
n the mobile sphere, most manufactures define look and feel, and
platform a11y requirements.[22:14] == jeanne [jeanne@128.30.52.169]
has quit [Client exited][22:14] <jallan> gl: there are some case where
user of some platform want the application to behave consistently as
other apps on the platform.[22:15] <jallan> ... there may be a user
who wants the same app to behave the same way across all platforms,
regardless of rules.[22:15] <jallan> john: Facebook lock look and feel
across all platforms[22:16] <jallan> jan: filling gap with our own
generic guidelines. we are a general purpose software
guidelines.[22:16] <jallan> john: disagree. these are general UI a11y
guidelines.[22:16] == jeanne [jeanne@128.30.52.169] has joined
#ua[22:17] <jallan> kf: jan, you said you could meed UAAG but still
have an inaccessible browser...example[22:18] <greg> Greg: An example
of where this SC is useful would be a mobile platform that said all
apps should show a magnified view of where the user is touching text
because it's necessary for people whose vision is not terribly acute.
If a browser fails to do that so it's not usable by people with low or
even moderate vision, yet it doesn't violate any other aspect of UAAG,
should it pass UAAG?[22:18] <jallan> jan: don't use only color to
convey info. this is true for webbased UA, but we push this off to the
platform a11y spec...it is not in UAAG for desktop UA[22:20] <jallan>
kf: @@in next draft, call out  521-3 with color and other scenarios,
see what folks think@@[22:21] <jallan> jan: don't want general
software a11y guidelines[22:22] <Jan> A.1.1.1 Web-Based Accessible
(WCAG): Web-based authoring tool user interfaces meet the WCAG 2.0
success criteria.[22:25] <greg> Greg: I believe it's not as clear as
it could be that these are intended to apply to any aspect of a UA's
UI that's implemented using web technologies, whether the UA is
web-based or native to the platform.[22:25] <greg> It conflates the
two concepts of web-based UI and web-based UA.[22:27] <greg> We agree
on the concept, but the wording needs tweaking to clarify.[22:27]
<jallan> s/521-3 with color/511 with color[22:27] <jallan> topic: 531
implement a11y features in content specs[22:28] <jallan> kf: why is
this here[22:28] <jallan> jan: must support alt. bullet 2 is
broad[22:28] == chsiao [chatzilla@63.145.238.4] has joined #ua[22:29]
<greg> Kelly feels this is not testable because few if any tech specs
call out their accessibility features.[22:30] <jallan> kelly: how to
test compliance. I am implementing html5, it has sparce a11y
documented features, what happens now[22:31] <greg> Greg: If a tech
spec doesn't call out any acc features, then the UA would not have to
do anything to comply with the first bullet of this SC.[22:31]
<jallan> kelly: writing test case, with out reading every word in
html5 or css, how do I know that the a11y features are present. where
are they documented[22:31] <jallan> jan: that would be a very good
thing.[22:31] <jallan> kelly: kick it out.[22:32] <jallan> greg: this
kind of big topic discussion works better in person.[22:32] <jallan>
bring definition issues to the CG[22:32] <greg> Greg: Thus it's not
that UA can't comply with this SC's first bullet, but that in many
cases complying with it won't actually benefit anyone.[22:33] <jallan>
531 NO[22:33] <jallan> topic: 532 implement a11y features of
platform.[22:34] <jallan> kf: kick it[22:34] <jallan> gl: sounds like
511[22:34] <jallan> jan: good resources. should go to 511[22:35]
<greg> General noting overlap between 5.1.1 Non-Web-Based Accessible
and 5.3.2 Implement Accessibility Features of platform[22:36] <jallan>
move intent of 532 to 511[22:36] <jallan> topic: 541 follow
specifications[22:36] <jallan> jan: brutal to test[22:36] <jeanne>
action: jeanne to move IER of 5.3.2 to 5.1.1 Follow accessibility
guidelines[22:36]  * trackbot noticed an ACTION. Trying to create
it.[22:36]  * RRSAgent records action 1[22:36] <@trackbot> Created
ACTION-652 - Move IER of 5.3.2 to 5.1.1 Follow accessibility
guidelines [on Jeanne F Spellman - due 2011-11-11].[22:37] <jallan>
gl: previous left out the exception. need access to generated content
-- against other specs[22:37] <jallan> jan: why are we the police man
for other specs, we don't know how good those are.[22:38] <jallan> kf:
kick it out[22:38] <jallan> kf: objections to deleting it...[22:39]
<jallan> gl: processing... do we say somewhere...follow a11y
guidelines...this says follow all the non-a11y parts of the
specs[22:40] <jallan> gl: isn't it important that the UA parse
html.[22:40] <jallan> kf: don't want to be a policeman[22:40] <jallan>
@@next status update...call out the removals and why.@@[22:40]
<jallan> kim: need to capture the examples[22:41] <jallan> topic: 542
handle unrendered technologies[22:42] <jallan> kf: this is not an a11y
thing.[22:43] <jallan> john: in mobile, you will save the link but not
content. there are rights management.[22:43] <jallan> jan: it says
"the user can choose a way"[22:43] <jallan> kim: isn't this an easy
win.[22:43] <jallan> kf: perhaps not[22:44] <jallan> jan: very tough
to test...have to check what happen with the other 1m
technologies.[22:45] <jallan> kim: look at usecases, how would we
solve them...where should we place them.[22:45] <jallan> kf: this is
not testable[22:46] <jallan> kf: don't see an a11y benefit.[22:46]
<jallan> kf: need review. this should not be A.[22:47] <jallan> topic:
543 alternative content handlers[22:47] <jallan> kf: to vague, should
be AAA[22:47] == chsiao [chatzilla@63.145.238.4] has quit [Ping
timeout][22:48] <jallan> gl: select content, open in my preferred
viewer[22:48] <jallan> kf: does this mean text. I want this DIV to
view in FF.[22:49] <jallan> action: Mark to rework 543...tighten up,
use mathml use case[22:49]  * RRSAgent records action 2[22:49]  *
trackbot noticed an ACTION. Trying to create it.[22:49] <@trackbot>
Created ACTION-653 - Rework 543...tighten up, use mathml use case [on
Markku Hakkinen - due 2011-11-11].[22:51] <jallan> @@move
applicability note in principle 5 to conformance section at top of
document -- Jan@@[22:58] == Ruinan [sunruinan@63.145.238.4] has quit
[Quit: Ruinan][23:06] == chsiao [chatzilla@63.145.238.4] has joined
#ua[23:07]  * Zakim excuses himself; his presence no longer seems to
be needed[23:07] == Zakim [rrs-bridgg@128.30.52.169] has left #ua
[][23:12] <jallan> topic: 211 keyboard operation[23:13] <jallan> js:
need to do something major, usecase - keyboard emulators, intentional
events, gestures, mobile devices,[23:14] <jallan> kim: when we say
keyboard access, we mean lowest demoninator. at unconference there was
a misunderstanding...folks are say why need the keyboard[23:15]
<jallan> ... we need to expand the meaning of our def of
keyboard....[23:15] <jallan> ... what we really mean by keyboard
access is a universal method of access.[23:15] <kford> John: the way
we solvedthis in Europe was just to say keyboard interface.[23:16]
<jallan> john: call is 'keyboard interface' and it means all of
those[23:16] <kford> John: It was understood by manufactures what we
meant.[23:16] <Jan> WCAG2 says: 2.1.1 Keyboard: All functionality of
the content is operable through a keyboard interface without requiring
specific timings for individual keystrokes, except where the
underlying function requires input that depends on the path of the
user's movement and not just the endpoints. (Level A)[23:16] <greg>
ISO and ANSI used the phrase "keyboards and keyboard emulators"[23:16]
<jallan> jr: keyboard interface is WCAG language[23:16] <jallan> gl:
ISO ANSI -- keyboard emulator[23:17] <jallan> john: keyboard emulator,
they only generate keyboard events[23:17] <jallan> keyboard used for
navigation, direct commands, selection, activation,
deactivation[23:18] <jallan> js: could put in a note, or part of
definition. there are other ways to do it other than keyboard
emulation.[23:18] <jallan> kp: keyboard is overloaded, how do you do
touch. how do I get to touch with speech[23:19] <jallan> john: on
devices have touch correlated with mouse.[23:19] <greg> a sixth use of
the keyboard is modification (e.g. holding down shift during drag,
holding down ctrl to slow animation).[23:19] <jallan> kp: mouse in
theory has keyboard equivalents[23:19] <jallan> kp: still issues with
hovering[23:19] <jallan> jan: can attach a full keyboard to device,
can have a keyboard interface[23:20] <jallan> john: not every touch
device had keyboard interface[23:20] <jallan> jan: all have some
keyboard underlying[23:20] <jallan> kelly: not on the MAC OS ... no
keyboard[23:21] <jallan> jan: there are switch interfaces that create
some keyboard simulator.[23:21] <jallan> kf: if you just hook up a
keyboard you cannot navigate to all UI objects[23:22] <jallan> kp:
mobile does not have arrows, control, alt, etc[23:22] <jallan>
keyboards are for text entry... no nav or control[23:22] <jallan> js:
what are functions of keyboard, make sure SC cover those[23:23]
<jallan> ... spec will be more general if we focus on
functions.[23:23] <jallan> kf: broader issue...iphone, what are we
expecting the user agent to do, I can touch every thing, do I need
object navigation[23:24] <jallan> jan: yes, scanning keyboard users,
single switch users, speech input users.[23:24] <jallan> what if
platform doesn't do that?[23:24] <jallan> jan: then platform is
broken[23:25] <jallan> gl: if platform is broken (non-accessible) can
you have a UA on it that is fully accessible meets UAAG[23:25]
<jallan> john: car use case[23:27] <jallan> kp: i am speech input, I
can do text feature with voice, but cannot control device fully with
voice. can do high level things. and text...but command/control not
there[23:27] <jallan> ...huge issue. big vacuum[23:28] <jallan> jan:
exploring interface with out activating. need an input method for
this[23:29] <jallan> kf: what to we really mean by "All functionality
can be operated via the keyboard using sequential or direct keyboard
commands "[23:29] <jallan> ... do we need something that says next UI
element...[23:29] <jallan> jan: device needs to have that concept at a
deep level.[23:30] <jallan> Does the UA have to provide that.[23:31]
<jallan> does UA have to repair the OS[23:32] <jallan> gl: highest
level...would rather have a UA that say I do all of this, but not X
because the OS doesn't allow it.[23:32] <jallan> ... don't want to
leave out something important[23:33] <jallan> jan: keyboard for
android, hooks in to emulator[23:34] <jallan> mh: webspeak, we named
every action available in the browser, and allowed the user to choose
a mechanism to cause them to happen[23:34] <jallan> kf: OFFICE, expose
all actions, user defines how they are activated.[23:35] <jallan> mh:
UA must expose this low level to the user/AT/Extensions[23:36]
<jallan> jr: this is called the standard input method on
android.[23:36] <jallan> kf: how do we make this SC say what we want
it say.[23:38] <jallan> mh: we need some statement that there is some
api or something that all the functions are allowed and expose to the
user so whatever input method the user wants can activate the
functions[23:39] <jallan> jr: these are the classes of things that the
platform allows, need to work in the UA,[23:39] <jallan> gl: need an
API to expose/invoke actions/intentions available in the OS to the UA
and user[23:41] <jallan> kf: what is the scope of this. most UA don't
expose a list of its functions,,, because most of the UA don't know
all of their functions[23:41] <jallan> ... thsi is hard because the
software is not architected that way.  [23:42] <jallan> gl: there is a
function 'refresh' - F5 maps to it, refresh button maps to it, menu
button maps to it.[23:43] <jallan> kf: are there ways of doing on
to[23:43] <jallan> jan: needs to be totally non-device
independent[23:44] <jallan> jim: do we need to talk to multimodal or
intentional actions group[23:44] <jallan> kp: there are input methods
that are unaware of each other. UA doesn't know that user is using
voice and touch.[23:44] <jallan> ... need something low level, very
important.[23:45] <jallan> kf: system know key or mouse event, they
are separate....bubbling up the software decides what needs happen on
the UI[23:45] <greg> There needs to be a lowest common denominator
interface for alternative input devices or software to drive ANY
software or device. In the past the keyboard interface, discrete
low-level commands, have been used for this.[23:45] <jallan> kp: very
complicated.[23:46] <jallan> kf: third layer...programmatic
actions....send button activate method[23:47] <jallan> gl: need to
know what has been standardized on.[23:48] <jallan> jim: seems very
low level in the OS. we don't care and have no control over what the
OS is doing, just need to make sure the UA follows them and exposed to
the user and user AT/extensions/etc[23:49] <jallan> js: suggests wiki
to collect use cases make sure we have cover what is needed, then
review SC to make sure they are covered[23:50] <jallan> kp: can use to
methods at the same time (control mouse click, voice mouse, mouse
keyboard, etc), methods are not aware of each other, but can be used
together[23:51] <jallan> gl: devices lacking modifier keys.[23:51]
<jeanne> http://www.w3.org/WAI/UA/work/wiki/Keyboard_Interface_use_cases[23:52]
<jallan> kf: UA is collecting events/adtions from the platforms[23:52]
<jallan> ... trying to get at that people made things that only worked
with the mouse[23:52] <jallan> ... what are examples with
touch...[23:52] <jallan> hover[23:53] <jallan> mh: touch interface
nano interface to know touch in 3d (to get hover)[23:53] <jallan> kf:
what are we expecting UA to do. not have hover feature[23:54] <jallan>
gl: can have hover[23:54] <jallan> gl: any problem with keyboard
emulator[23:55] <Jan> jan: universal input[23:55] <jallan> kp:
universal input interface[23:56] <jallan> kf: close to agreeing on
bluedog[23:56] <jallan> ... we mean that features work with bluedog
input method[23:57] <jallan> mh: core set of function/methods/actions
that meet these SC, that expose core[23:58] <jallan> jr: allow control
with voice, gestures, keyboard, mouse, thought[23:59] <jallan> jr: at
top of document, we have set of assumptions - color[00:00] <jallan>
gl: everything must be doable by the mouse[00:00] <jallan> ?[00:02]
<jallan> js: some of 21x need to stay with proviso 'if you have a
keyboard'[00:03] <jallan> kp: if we do universal input can cover
everything.[00:03] <jallan> js: may be important to keep some as
keyboard.[00:04] <jallan> kp: need to define and reinforce UII
(bluedog)[00:05] <jallan> working lunch...[00:06] <jallan> Jan: UA
would not do this….it has to expose what is available on the platform
May write an extension that exposes  [00:09] == JohnS
[qw3birc@128.30.52.28] has quit [Quit: Page closed][00:12] == AllanJ
[chatzilla@63.145.238.4] has joined #ua[00:12] <Jan> A.3.1.1 Keyboard
Access (Minimum):  All functionality of the authoring tool is operable
through a keyboard interface without requiring specific timings for
individual keystrokes, except where the underlying function requires
input that depends on the path of the user's movement and not just the
endpoints.[00:12] <Jan> Note 1: Meeting this success criterion does
not require the presence of a conventional keyboard.[00:13] <greg>
John pointed the group to http://www.mandate376.eu/, particularly D1:
Draft EN "European accessibility requirements for public procurement
of ICT products and services" zip archive, specifying the functional
accessibility requirements applicable to ICT products and
services.[00:13] <AllanJ> john: only people who will argure that
keyboard is not the write word are those not involved in this
work[00:13] <AllanJ> kp: that;s a lot of people[00:13] <AllanJ> ...
what it to be wider[00:14] <AllanJ>  http://www.mandate376.eu/[00:22]
== chsiao [chatzilla@63.145.238.4] has quit [Ping timeout][00:53] ==
jeanne [jeanne@128.30.52.169] has quit [Client exited][01:00] ==
jeanne [jeanne@128.30.52.169] has joined #ua[01:12] <AllanJ> starting
up again[01:13] <Jan>
http://lists.w3.org/Archives/Public/w3c-wai-ua/2011OctDec/0045.html[01:16]
<AllanJ> 2.1.1 Keyboard Access (Minimum):[01:16] <AllanJ> All
functionality is operable through a keyboard interface without
requiring specific timings for individual actions, except where the
underlying function requires input that depends on the path of the
user's movement and not just the endpoints. (Level A)[01:16] <AllanJ>
Note 1: This success criterion does imply the presence of a
conventional keyboard. Keyboard interfaces are platform-level
mechanisms that enable operation via a range of input methods and
assistive technologies, such as touch gestures, voice input,
single-switch input, conventional keyboards, etc. Therefore, this
success criterion does not forbid and should not discourage providing
mouse...[01:16] <AllanJ> ...and/or touch input in addition to keyboard
interface operation.[01:16] <AllanJ> Note 2: The path exception
relates to the underlying function, not the input technique. For
example, if using handwriting to enter text, the input technique
(handwriting) requires path-dependent input, but the underlying
function (text input) does not. The path exception encompasses other
input variables that are continuously sampled from pointing devices,
including pressure, speed, and angle.[01:17] <greg> I still maintain
that things that can be done with the keyboard but that rely on the
user's ability to understand screen locations is not
sufficient.[01:17] <Jan> Note 1: This success criterion does NOT imply
the presence of a conventional keyboard. Keyboard interfaces are
platform-level mechanisms that enable operation via a range of input
methods and assistive technologies, such as touch gestures, voice
input, single-switch input, conventional keyboards, etc. Therefore,
this success criterion does not forbid and should not discourage
providing mouse...[01:17] <Jan> ...and/or touch input in addition to
keyboard interface operation.[01:17] == JohnS [qw3birc@128.30.52.28]
has joined #UA[01:18] <AllanJ> gl: referring to mouse keys. it is not
efficient and it requires you to see the screen[01:18] <JohnS> DRAFT:
4.3.19 Keyboard Operation For an ICT with a keyboard or an electronic
user interface that supports keyboard operation, a mode of operation
shall be provided that allows all functions that do not require a
time-dependent analogue input, to be operable through the keyboard or
a keyboard interface.[01:18] <greg> What we had before covered that
correctly.[01:18] <AllanJ> ICT=information communication
technology[01:20] <AllanJ> electronic user interface is very
broad[01:20] <AllanJ> john: scope of this is everything ... anything
that communicates electronically with something else[01:22] <AllanJ>
jr: there are other inputs that are analogue, path exception covers
other technologies[01:22] <AllanJ> gl: 3 different wordings -[01:23]
<AllanJ> john: this still needs more rewording[01:23] <AllanJ> ...
input from a mouse can be mapped to a keyboard. but mouseing it time
dependent. it is a path[01:24] <AllanJ> gl: mouse keys
explanation[01:24] <AllanJ> john: this is not a base navigation
function.[01:25] <AllanJ> ... navigation is a separate interface. they
are not part of the keyboard. depends on form factor[01:25] <AllanJ>
... touch device only has text input via a keyboard. but keyboard has
no arrow...those are handled by touch gestures[01:26] <AllanJ> device
pickup standard inputs and convert to something it needs.[01:26]
<AllanJ> kf: have a generic problem. software UA can work with more
than one input device.[01:28] <AllanJ> gl: test case. app only uses a
mouse for command and control. keyvboard only for text. they say we
are fully UAAG compliant. because you can use mousekeys from the
OS.[01:29] <AllanJ> john: users communicate with devices with keyboard
interface[01:30] <AllanJ> ... you are able to know the location of
what is on the screen.[01:30] <AllanJ> .... you must be able to
navigate from element to element.[01:32] <AllanJ> kf: hold off on
keyboard. lets look at other SC, see if this gets worse or better. 211
is the generic case. even with Jan's rewording...how do you test 'all
functions'[01:32] <greg> My concern is that the EU wording would allow
a UA on a mainstream desktop GUI to be compliant even if it requires a
mouse for command and control, by claiming that the user can fall back
on the MouseKeys feature in the OS that lets the user emulate mouse
input using the keyboard.[01:32] <AllanJ>
-----------------------------[01:33] <AllanJ> 2.1.2 Keyboard Focus:
Every viewport has an active or inactive keyboard focus at all
times.[01:33] <AllanJ> the focus does not have to be displayed[01:35]
<AllanJ> Ted O'Connor Apple webkit[01:36] <AllanJ> ... does standards
related things. not necessarily a11y (see James Craig)[01:42] <AllanJ>
ted: terms...not sure what to use. using keyboard interface is not a
horrible idea.[01:42] <AllanJ> ... everything must be accessible from
the keyboard...and mouse. they should not be priviledged.[01:43]
<AllanJ> ... now we have more input methods. not mouse only.  cann't
be excluding. need to allow all input methods[01:44] <AllanJ> jan:
worried about first reaction to the guidelines.[01:44] <AllanJ> ted:
modality independent operation[01:44] <AllanJ> add to preface, index,
somewhere[01:45] <AllanJ> Michael Cooper - intentional events[01:46]
<AllanJ> ... problem with a11y of touch devices, even if you have
gestures that blind folks can do....what about those using AT.[01:46]
<AllanJ> ... how does AT send proprietary touch events to a
device.[01:47] <AllanJ> ... create an intermediate layer. record the
intent, motion is time dependent. the path is analysed and mapped to
an intent, then send the proper command to the device[01:48] <AllanJ>
... device is also able to send the hardware events.[01:48] <AllanJ>
.... critical on mobile, and most other platforms[01:49] <AllanJ> have
developers develop for intentions. critical for a11y, but easier for
developes and mainstream folks (web events)[01:50] <AllanJ> ...
proposed charter for 2 groups... intentional events (WAI group), web
events WG, work on same issue. WAI would control and have
deliverable[01:50] <AllanJ> ... possible user action events[01:51]
<AllanJ> ... will complement ARIA work[01:51] <AllanJ> js: cureently
working on keyboard access....working on what is a broader term, that
covers all input modality.[01:52] <AllanJ> ... things implied by the
SC, navigation, command control, text input, etc[01:53] <AllanJ> mc:
group would accept input on requirements in the next few months.
intermediate layer could be very important[01:53] <AllanJ> ... expand
at future date, all events across all applications[01:53] <AllanJ> ...
how much is science and what is art[01:54] <AllanJ> ... discussion
about DOM activate event,[01:54] <AllanJ> ... intent should be
different from a hardware specific event[01:55] <AllanJ> js: maybe
something we could point to.[01:55] <AllanJ> john: implications for
our keyboard work[01:56] <AllanJ> ... reders it redunant.[01:56]
<AllanJ> all--NO[01:56] <AllanJ> john: when intentional events happen,
then the layers become important[01:57] <AllanJ> mc: hardware , user
abstraction, other layers[01:57] <AllanJ> kf: if I hit TAB what was
the real intention, or I make some gesture what does it mean.[01:57]
<AllanJ> mc: context sensitive[01:58] <AllanJ> gl: concept of layers
is impt for AT, who gets what first[01:58] <AllanJ> ... interaction of
AT with keyboard macros, bypassing each other or chaining[01:59]
<AllanJ> s/redunant/redundant[02:00] <AllanJ> kp: what are you trying
to solve[02:00] == JohnS [qw3birc@128.30.52.28] has quit [Ping
timeout][02:01] <AllanJ> mc: if AT user of smart phone, how do you
interface and make it work. not a problem with native apps, but
webapps are bigger[02:02] <AllanJ> gl: voice input interface on
desktop, needs same layer of intentions as mobile[02:03] <AllanJ> mc:
need use cases, what are things users intend to do with web
applications, any requirements related to AT[02:04] <AllanJ> jr:
interface between the UA chrome and the application. playing with UA
touch interface...then move to content. hearing that intentional
events scoped to content, not to UA in general[02:05] <AllanJ> mc:
lines getting fuzzy.[02:05] <AllanJ> ted: imagine 2 keyboard, one
without spacebar. one can space between words, the other not[02:07]
<AllanJ> jr: app on android, that emulates events on droid from
external AT with a keyboard[02:08] <AllanJ> ted: scroll, swipe to
bottom, loads new page. scroll event make this happen.[02:08] <AllanJ>
john: user must be able to stop the auto uploading.[02:09] <AllanJ>
jr: bluetooth input[02:09] <AllanJ> jr: two finger turn to flip map.
how do I do that from a keyboard.[02:10] <AllanJ> mc: with intential
events can do that[02:10] <AllanJ> rotate event[02:11] <AllanJ> kf:
come up with a list of events...rotate. you figure out how you want us
to tell you how to do it.[02:11] <AllanJ> ... r =touch rotate[02:12]
<AllanJ> jr: no current way to send intentional event from the
keyboard[02:12] <AllanJ> ted: thinks the list is small[02:13] <AllanJ>
john: AT can only send keyboard events. they don't have access to
gestures. all functions are mapped to the gesture.[02:13] <AllanJ> mc:
could have keyboard command that will send a gesture[02:14] <AllanJ>
trickling through layers[02:15] <AllanJ> web-application[02:15]
<AllanJ> intention layer mediating AT input and passing to the
hardware[02:17] <greg> It sounds like people here are building up
different mental models, would be helped by very specific use
cases/examples.[02:17] <jeanne> scribe: jeanne[02:18] <jeanne> MC:
Some of the use cases have been documented, at least likely.[02:19]
<jeanne> JA: Browsers can't do things, so people are using javascript
to create actions that the assistive technology doesn't know about, is
there something being worked on to keep authors from creating new
javascript objects[02:20] <jeanne> ... chaals stated that the browser
serves the javascript first.  [02:21] <jeanne> GL: The OS gets it
first and passes events to the browser, which passes it to the web
app[02:22] <jeanne> ... when we talk about keyboard events, they
change formats[02:22] <jeanne> ... its a chain of emulation.  "I got a
VK (virtual key) event, so I will trigger a PgDn event[02:23] ==
MichaelC [Michael@128.30.52.169] has joined #ua[02:23] <MichaelC> ->
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html
Original Intentional Events proposal[02:23] <MichaelC> ->
http://www.w3.org/WAI/PF/src/iui Updated Intentional Events
preliminary editors draft[02:24] <MichaelC> ->
http://www.w3.org/2011/08/intentional-events-charter Draft Intentional
Events WG charter[02:26] <jeanne> MC: events is an input into the
application, and ARIA is more of an output[02:29] == hober
[ted@174.143.153.77] has joined #ua[02:29]  * hober hello, this is
ted[02:31] <jeanne> KF: we will discuss how UAWG wants to participate
in Intentional Events[02:33] == MichaelC [Michael@128.30.52.169] has
left #ua [][02:35] <jeanne> RS: logical navigation and intent-based
events[02:35] <jeanne> ... need to generate them based on (e.g.)
touch, gesture, higher level commands[02:36] <jeanne> ... need to know
the semantics of the target[02:36] <jeanne> ... bind the hardware
level events to higher level components, like a event that operates a
widget.[02:37] <jeanne> ... "open" is conistent across
platforms[02:52] <jeanne> JS: Like "Modality Independent Interface"
and don't want to lose track of that phrase for Principle 2[02:53]
<jeanne> Topic: 2.2 Keyboard Focus[02:54] <jeanne> RS: Is upcoming
browser version going to continue to have a concept of keyboard
focus?[02:55] <jeanne> JR: Yes, it is already in Android[02:55]
<jeanne> GL: Some browsers may not have a concept of keyboard focus,
but we mean they need they need to have a concept of focus, there is
potentially a focus for every input  device[02:56] <jeanne> JR: If you
are a speech user and wanted to act on a viewport, you want it to take
place at the keyboard section.[02:57] <jeanne> GL: Not necessarily -
if you say click, then you want mouse focus; if you say enter, you
want keyboard focus.[02:58] <jeanne> KF: We do know the existing
universe of input mechanism, are there essentials for that input
mechanism that we want to call out? That is essential to that input
mechanism.[02:58] <jeanne> 2.1.2 is YES good to go.[02:58] ==
mhakkinen [mth@206.29.182.207] has joined #ua[02:59] <jeanne> Topic:
2.1.3 Viewport Navigation[02:59] <jeanne> KF: Problem with the
stem[03:00] <jeanne> GL: It conflicts with other standards that say
that you don't want to take focus[03:00] <jeanne> JR: On-screen
keyboards are not part of the content viewport, it wouldn't
apply.[03:01] <jeanne> GL: It is really saying you can activate any
viewport, that there is no sidebar that only takes mouse input[03:02]
<jeanne> 2.1.3 is YES with BlueDog[03:02] <jeanne> s/2.1.2 is YES good
to go./2.1.2 is YES with Bluedog[03:02] <jeanne> topic: 2.1.4[03:03]
<jeanne> KF: I think this should be AA or AAA, I don't think this is a
hill to stand on.  [03:04] <jeanne> KP: There is an issue right now
with Crtl-F in Google docs and Ctrl-F in Firefox.[03:05] <jeanne> GL:
If the browser has a function that is only accessible with the F8 key,
and the app has the F8, if you specify that the content gets the
command, how do you get to the other command?[03:06] <jeanne> KF:
there are always other ways to get to anything with a shortcut.
Menus, preferences[03:07] <jeanne> JR: Not applicable to every
platform[03:07] <jeanne> KP: There are users that this is the ONLY way
to get to it.  [03:09] <jeanne> ... it is consistency and user control
that I am looking for.  I never know which function will be invoked
when I press F8.  [03:11] <jeanne> ... for voice users, the different
between 2 and 1 command is huge in efficiency and fatigue.  [03:13]
<jeanne> GL: I compare the number of actions a mouse user needs to
accomplish a task, compared to the keyboard user actions - I often
find it is more than 3x the number of actions.[03:14] <jeanne> JA:
This also compensates for the javascript that grabs a keybinding for
unknown tasks.  [03:14] == mth [qw3birc@128.30.52.28] has quit [Ping
timeout][03:14] <jeanne> 2.1.4 is YES as is[03:15] <jeanne> topic:
2.1.5 No keyboard trap[03:16] <jeanne> group agrees it still
happens[03:17] <Jan> From ATAG2...A.3.1.2 No Keyboard Traps: If
keyboard focus can be moved to a component using a keyboard interface,
then focus can be moved away from that component using only a keyboard
interface, and, if it requires more than unmodified arrow or tab keys
or other standard exit methods, authors are advised of the method for
moving focus away. (Level A)[03:17] <jeanne> JR: If it can be moved to
the object, it can be moved away, and there is a fixed command to take
it out.[03:17] <Jan> So ,maybe: 2.1.5 No Keyboard Traps: If keyboard
focus can be moved to a component using a keyboard interface, then
focus can be moved away from that component using only a keyboard
interface, and, if it requires more than unmodified arrow or tab keys
or other standard exit methods, users are advised of the method for
moving focus away. (Level A)[03:21] <AllanJ> +1 kelly proposal to
accept Jan's wording[03:22] <greg> Minor concern whether "users are
advised" would allow documenting a key combination on the web site,
leaving users stuck.[03:26] <greg> Decision was to accept Jan's
wording, and clarify in the Intent and Examples that it's better not
bury this critical information on the web site.[03:26] <greg> topic:
2.1.6 Separate Selection from Activation[03:27] <greg> Kelly: ARIA
best practices says that radio buttons should be automatically
selected when you navigate through them (e.g. with arrow). But with
ctrl+arrow should move focus without changing activation.[03:28]
<greg> Kelly: At one point that was a Windows standard behavior, but
it doesn't seem to work today.[03:28] <greg> Kelly: Doesn't work that
way in Firefox UI but does in its rendered content.[03:28] <greg>
Rich: A team led by AOL defined standard keyboard navigation for these
types of controls.[03:30] <greg> Kelly: Votes to postpone this
SC.[03:31] <greg> Jeanne: This is a big issue for Mark, because kids
using online tests get stuck if they accidentally select a radio
button and cannot unselect it.[03:32] <greg> Kim: Big issue for speech
users because can't hover.[03:32] <mhakkinen> Yes...[03:32] <greg>
Jeanne: Big issue whenever actions cannot be undone.[03:34] <greg>
Jan: Needs to be reworded at least for e.g. in the middle.[03:34]
<greg> topic: 2.1.7 Follow Text Keyboard Conventions[03:36] <greg>
Jan: Can we take examples out of the SC?[03:36] <greg> Jeanne: Without
the inline examples readers don't understand it.[03:36] <greg>
Decision to move the inline examples to the Intent, otherwise
OK.[03:37] <greg> topic: 2.1.8 Make Important Command Functions
Efficient[03:37] <greg> Greg: "important" is somewhat subjective
here.[03:38] <greg> Kelly: untestable.[03:38] <Jan> A.3.1.3 Efficient
Keyboard Access: The authoring tool user interface includes mechanisms
to make keyboard access more efficient than sequential keyboard
access. (Level AA)[03:40] <greg> Greg: Seems too low a bar, that the
UA need only have two shortcut keys to pass.[03:41] <greg> Kim, Jim,
Kelly all approve that at Level A.[03:42] <greg> Greg unhappy, but
will not object.[03:42] <greg> topic: 2.1.9 Allow Override of User
Interface Keyboard Commands[03:43] <greg> This is similar to 2.1.4 but
adds requires single-key and key-plus-modifier, and is AA instead of
A.[03:44] <greg> Keeping it as is.[03:44] <greg> topic: 2.2.1
Sequential Navigation Between Elements[03:45] <greg> OK.[03:45] <greg>
topic: 2.2.2 Sequential Navigation Between Viewports[03:46] <greg>
Jan: This assumes that all viewports can take focus, and is Level A.
Could this be combined by the 2.1.3 Viewport Navigation?[03:47] <greg>
Jan: Change to "all viewports" to make it require focusabiity of all
viewports.[03:47] <greg> Jan: So many SC, if can be combined would
prefer them to be.[03:49] <Jan> Action: JR to see if 2.1.3 and 2.2.2
can be combined.[03:49]  * trackbot noticed an ACTION. Trying to
create it.[03:49]  * RRSAgent records action 3[03:49] <@trackbot>
Created ACTION-654 - See if 2.1.3 and 2.2.2 can be combined. [on Jan
Richards - due 2011-11-11].[03:50] <greg> That is, fold 2.1.3 into
2.2.2 and add a reference in 2.1 to 2.2.2.[03:51] <Jan> (folding 2.1.3
into 2.2.2 and make sure to say ALL viewports)[03:51] <greg> topic:
2.2.3 Default Navigation Order[03:52] <greg> Jan: Should this be the
default, or could this be optional?[03:54] <AllanJ> If the author has
not specified a navigation order, the default sequential navigation
order is document order. (Level A)[03:54] <greg> OK.[03:55] <greg>
topic: 2.2.4 Options for Wrapping in Navigation[03:55] <greg> Jan
likes, Kelly dislikes.[03:57] <greg> Kelly finds wording
confusing.[03:58] <Jan> 2.2.4 Options for Wrapping in Navigation: The
user can have sequential navigation prevent wrapping or receive
feedback when wrapping. (Level AA)[03:59] <greg> Kelly: When user
interaction with web content causes focus wrapping, the user agent
allows the user to either (a) tell them it wrapped or (b) prevent the
wrapping.[04:00] <greg> Kelly feels strongly it should be in content
only, not UA UI.[04:00] <jeanne> When user interaction with web
content causes focus wrapping, the user can haveprevent wrapping or
the user can receive feedback when wrapping. (Level AA)[04:01] <greg>
Greg agrees that if the platform convention is for menus to wrap
silently, then UA menus can't be expected to violate that.[04:01]
<mhakkinen> What if ua menus or dialogs are web content?[04:02] <greg>
Kelly: This is about wrapping at end of the document, not horizontal
wrapping between table rows and the like.[04:02] <mhakkinen> Chrome
settings, for example[04:03] <greg> Greg: Wrapping is not going to the
next row, but going back to the beginning of the same row.[04:03]
<mhakkinen> So ua has to know its own content even though AT
doesn't[04:05] <greg> Greg: What we mean is when sequential navigation
within a set of elements tries to move beyond the last element (or
first when navigating in reverse order)...[04:05] <greg> Kelly: It's
end of page.[04:06] <greg> Greg: Page or other set of elements that
normally wrap in this browser.[04:06] <jeanne> When user interaction
with web content causes focus wrapping at the end of the content or
whenever sequential navigation within a set of elements reaches the
last element, the user can prevent wrapping or the user can receive
feedback when wrapping. (Level AA)[04:06] <greg> Postponing for
further discussion later.[04:11] <greg> topic: 2.3.1 Direct Navigation
to Important Elements[04:12] <greg> What is "important'
elements?[04:12] <greg> Greg: we say the user can customize what they
consider important elements.[04:12] <greg> Rich: make sure ARIA
Landmarks are included.[04:13] <greg> Rich: All content required to be
in at least one landmark region so nothing orphaned.[04:14] <greg>
Related to 1.10.3 Configure Elements for Sequential Navigation.[04:15]
<greg> Jeanne reads definition of Important Elements from the
glossary.[04:15] <jeanne> This specification intentionally does not
identify which "important elements" must be navigable because this
will vary by specification. What constitutes "efficient navigation"
may depend on a number of factors as well, including the "shape" of
content (e.g. sequential navigation of long lists is not efficient)
and desired granularity (e.g. among tables, then among the cells of a
given table).[04:15] <jeanne> Refer to the Implementing document
[Implementing UAAG 2.0] for information about identifying and
navigating important elements. @@ Editors' Note: Update links[04:15]
<greg> Jan: 2.5.7 is Configure Elements for Structural Navigation is
AAA.[04:16] <greg> 2.3.1 is Level A without the ability to
customize.[04:16] <greg> The example is about numbering
hyperlinks.[04:16] <greg> Jan: To reach A every UA needs to have
Mouseless Browsing built in or available in add-on?[04:17] <greg>
Kelly: Feels it shouldn't be Level A.[04:18] <greg> Kim: Important for
voice input.[04:18] <greg> Rich: Important for low vision.[04:18]
<greg> Kelly: Should do exercise of prioritizing our Level A
SC.[04:18] <greg> Kelly: This used to be common, e.g. Lynx.[04:19]
<AllanJ> action: Jallan to create a list of all A SC for
prioritization discussion on Thursday[04:19]  * RRSAgent records
action 4[04:19]  * trackbot noticed an ACTION. Trying to create
it.[04:19] <@trackbot> Created ACTION-655 - Create a list of all A SC
for prioritization discussion on Thursday [on Jim Allan - due
2011-11-11].[04:19] <greg> Kelly: Some browsers let you enter mode
where it searches as you type.[04:20] <greg> Agreement to keep this
one.[04:20] <greg> topic: 2.3.2 Present Direct Commands in Rendered
Content[04:21] <greg> Easier to read with slight change: "The user can
have any recognized direct commands in rendered content (e.g.
accesskey) be presented with their associated elements. (Level
A)"[04:23] <greg> Kelly: "presented with" is too vague, e.g. show
accesskey if you hover over it.[04:23] <greg> Jeanne: then you fail
the requirement for keyboard access to all features.[04:23] <greg>
Kelly: AAA[04:23] <greg> Jan: 2.3.1 useless without 2.3.2.[04:25]
<greg> Kelly: 2.3.1 is UA added, 2.3.2 is about
author-supplied.[04:25] <greg> Greg: Could be clarified by adding
wording from 2.3.2 into 2.3.1.[04:26] <greg> Jan noted duplication of
several SC in this section.[04:29] <greg> Greg: Errors in merging
documents. Want to check which version Greg and Kim submitted.[04:32]
<greg> action: Greg and Kim to reconcile duplications of 2.3.2, 2.3.x
and 2.3.4 all about presenting direct commands in content[04:32]  *
trackbot noticed an ACTION. Trying to create it.[04:32]  * RRSAgent
records action 5[04:32] <@trackbot> Created ACTION-656 - And Kim to
reconcile duplications of 2.3.2, 2.3.x and 2.3.4 all about presenting
direct commands in content [on Greg Lowney - due 2011-11-11].[04:34]
<greg> topic: 2.3.3 Direct activation[04:34] == mhakkinen
[mth@206.29.182.207] has quit [Quit: Bye][04:36] == mth
[mth@206.29.182.207] has joined #ua[04:37] <greg> Confusion over
difference between this and 2.3.1; 2.3.1 is about important elements
(A), while 2.3.3 is about ALL operable elements (AA)[04:38] <greg>
2.3.3 is ambiguous about whether navigate to and activate needs to be
a single operation.[04:38] <greg> Kelly: 2.3 is all confusing.[04:39]
<Jan> also look at possible duplication: 2.1.4 Specify preferred
keystrokes; 2.3.5 Allow Override of Accesskeys[04:41] <greg> Greg and
Kim will review all of 2.3.[04:43] <greg> Agreement to suspend the SC
review at this point, as only 17 minutes remain.[04:47] <greg>
Discussion with Judy Brewer.[04:53] == kford [chatzilla@63.145.238.4]
has quit [Ping timeout][04:59] == greg [chatzilla@63.145.238.4] has
quit [Ping timeout][05:04] == mth [mth@206.29.182.207] has quit [Quit:
Bye]


-- 
Jim Allan, Accessibility Coordinator & Webmaster
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/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

Received on Thursday, 17 November 2011 16:51:48 UTC