IRC log of ua on 2011-11-04

Timestamps are in UTC.

00:00:20 [jallan]
cross reference this with 1.8.6, 1.8.7
00:00:27 [jallan]
topic 3.4.2
00:01:39 [jallan]
greg: this is in ISO
00:03:12 [greg]
Jan is correct that this should only include things the UA does, not things the content does that the UA cannot know about.
00:05:22 [jallan]
this is different that checkbox behavior
00:07:58 [Jan]
http://www.w3schools.com/html/tryit.asp?filename=tryhtml_form_radio
00:08:39 [greg]
ISO 9241-171 includes 9.3.14 Separate keyboard navigation and activation:
00:08:41 [greg]
Software shall allow users to move the keyboard focus without triggering any effects other than the presentation of information (e.g. scrolling or pop-ups that do not change the focus or selection). An explicit keystroke or similar user action shall be provided to trigger any other user-initiated effect.
00:10:15 [jallan]
big discussion.
00:12:29 [jallan]
kelly: software does not work this way
00:12:46 [jallan]
kim: this is a huge problem for speech input users.
00:13:23 [jallan]
if you jump to a radio button group, it will select the first one.
00:14:15 [jallan]
jan: need disclaimer for things that the ua recognizes
00:15:02 [jallan]
kelly: touch interface you see it you touch it, you select it.
00:15:32 [jallan]
kim: there is no speech control of phones because of this problem
00:16:42 [jallan]
jan: the behavior of arrowing through radio buttons should select them. but can CTRL arrow to not select.
00:16:52 [Jan]
http://www.w3.org/TR/wai-aria-practices/#radiobutton
00:26:36 [jallan]
rrsagent, make minutes
00:26:36 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/11/04-ua-minutes.html jallan
00:26:56 [jallan]
rrsagent, set logs public
00:29:32 [jallan]
rrsagent, make minutes
00:29:32 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/11/04-ua-minutes.html jallan
00:35:20 [jeanne]
http://www.w3.org/2011/11/03-ua-irc.html
00:37:14 [kford]
kford has joined #ua
15:45:43 [RRSAgent]
RRSAgent has joined #ua
15:45:43 [RRSAgent]
logging to http://www.w3.org/2011/11/04-ua-irc
15:45:45 [trackbot]
RRSAgent, make logs public
15:45:45 [Zakim]
Zakim has joined #ua
15:45:47 [trackbot]
Zakim, this will be WAI_UAWG
15:45:47 [Zakim]
ok, trackbot; I see WAI_UAWG(TPAC)11:30AM scheduled to start 15 minutes ago
15:45:48 [trackbot]
Meeting: User Agent Accessibility Guidelines Working Group Teleconference
15:45:48 [trackbot]
Date: 04 November 2011
15:47:44 [chsiao]
chsiao has joined #ua
15:52:27 [jallan]
jallan has joined #ua
15:52:33 [Admin]
Admin has joined #ua
15:52:37 [jeanne]
chair: Jim, Kelly
15:52:49 [jallan]
scribe: jallan
15:52:58 [jeanne]
present+ Kelly, Mark, Jim, Greg, Kim, Jeanne, Jan
15:53:00 [jallan]
kelly: reviewing agenda
15:53:48 [kford]
Latest draft.
15:53:50 [kford]
http://www.w3.org/WAI/UA/2011/ED-UAAG20-20111104/MasterUAAG20111104.html
15:57:27 [jallan]
Topic: 4.1.1 platform a11y architecture
15:58:14 [jallan]
greg: details of how to support this are in other SC. 411 may be considered redundant...or
15:58:19 [greg]
greg has joined #ua
15:58:23 [jallan]
kim: it sets the stage.
15:58:55 [greg]
Kelly is concerned that 4.1.1 Platform Accessibility Architecture is vague.
15:59:19 [greg]
Greg says it could b considered redundant to the other 4.1.x that require platform accessibility API usage.
16:00:38 [Jan]
FYI: ATAG2 says: A.1.2.2 Platform Accessibility Services: Non-web-based authoring tools implement communication with platform accessibility services. (Level A)
16:00:46 [jallan]
jim asks about current a11y architecture support in current browsers
16:00:51 [jallan]
411 OK
16:01:49 [jallan]
jim +1 to ATAG communication
16:01:53 [Ruinan]
Ruinan has joined #ua
16:03:17 [jallan]
js: web-based players (embedded) may be talking to the a11y arch. directly
16:03:54 [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...
16:03:55 [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
16:03:55 [Jan]
...platform accessibility service.
16:04:53 [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).
16:06:24 [jallan]
make it a no add a scoping note at the top of the document.
16:07:13 [greg]
General scoping/exception for SC that are not relevant to your platform (e.g. color on audio output, AT compat on closed systems).
16:07:18 [jallan]
kf: where the platform support an platform a11y api then use it, if you don't support it you must make one.
16:08:29 [jallan]
action: kelly to write a scoping NOTE about Guideline 4.1
16:08:30 [trackbot]
Created ACTION-647 - Write a scoping NOTE about Guideline 4.1 [on Kelly Ford - due 2011-11-11].
16:08:42 [jallan]
rrsagent, make minutes
16:08:42 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/11/04-ua-minutes.html jallan
16:09:51 [jallan]
topic: 412 name, role, state, value, description
16:09:53 [Jan]
Action: JR to propose a conformance applicability note re: platform and device constratins (eg. lacking platform accessibility service, monochrome screen)
16:09:53 [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].
16:10:30 [jallan]
kelly: votes no, concept is good, lmay not be right bulleted list
16:10:36 [jallan]
mh: could agree
16:11:15 [jallan]
kelly: other platforms may have these but called other names, or the may have others that are also necessary
16:11:52 [jallan]
kf: the list may need to be different.
16:12:11 [jallan]
jan: the list is prescriptive.
16:12:30 [jallan]
kf: goal is that the user can determine what something is and how to use it
16:13:18 [jallan]
gl: goal - ua and generated content...should be in the dom, other spec were ambigious
16:13:57 [jallan]
kf: msaa uses these labels, UI automation has different names and concepts.
16:14:53 [jallan]
action: kelly to rewrite in modern terms (genericize) 4.1.2 with greg
16:14:54 [trackbot]
Created ACTION-649 - Rewrite in modern terms (genericize) 4.1.2 with greg [on Kelly Ford - due 2011-11-11].
16:15:17 [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.
16:15:38 [jallan]
topic: 413 Accessible Alternative
16:15:49 [jallan]
jeanne, jan, kelly +1
16:17:28 [jallan]
jan: some cool drag/drop interface can make it work in platform a11y api,
16:18:13 [jallan]
topic: 414 programmatic availability of doms
16:18:18 [jallan]
all ok
16:19:17 [jallan]
jim: generated content does not appear in the DOM
16:19:29 [jallan]
kf: need to check in HTML 5
16:19:48 [jallan]
action: jim to review generated css content in html5
16:19:48 [trackbot]
Created ACTION-650 - Review generated css content in html5 [on Jim Allan - due 2011-11-11].
16:20:13 [jallan]
topic: 415 write access
16:20:28 [jallan]
jan: didn't ARIA say they did not want write
16:21:24 [jallan]
... AT wants to check a check box, don't send command to the UA, write to the DOM
16:21:41 [jallan]
there is an action and issues related to this
16:21:44 [jallan]
all NO
16:22:44 [greg]
The title doesn't match the body of the SC, which is not related to write access.
16:23:21 [jallan]
topic: 416 properties
16:24:00 [jallan]
kelly: this needs work, to specific
16:25:11 [jallan]
kf: stem is vague
16:25:36 [jallan]
jan: reviews the content
16:26:02 [jallan]
kf: is this the right laundry list. what is general goal.
16:26:46 [jallan]
kf: classic argument. the ADA was passed before the internet so it doesent apply
16:27:14 [jallan]
gl: the list is a minimum,
16:27:32 [jallan]
... if you want to argue that it be vague, then how to check compliance
16:28:02 [jallan]
mh: similar to 412, perhaps remove and beef up 412
16:28:12 [jallan]
kf: +1
16:29:44 [jallan]
action: kelly to combine 412 and 416, with Mark
16:29:44 [trackbot]
Created ACTION-651 - Combine 412 and 416, with Mark [on Kelly Ford - due 2011-11-11].
16:30:13 [jallan]
short discussion of msaa, IA2, UIA, other platforms
16:30:34 [jallan]
jan: the items in 416 are very basic, and won't go away
16:30:48 [jallan]
kf: we don't want to leave anything out
16:30:58 [jallan]
gl: need a balance.
16:31:19 [jallan]
topic: 417 timely communication
16:31:28 [jallan]
jan: does this need to be said
16:32:18 [jallan]
... what is the rate...10 milliseconds? it is vague
16:32:38 [jallan]
gl: efficiency, 200 api calls.
16:32:54 [jallan]
kf: leave it in, an easy win
16:33:20 [jallan]
jan: testing compliance, do you name the AT and record time?
16:34:02 [jallan]
gl: say something in the intent on how we expect it to be tested. new update to the screen,
16:34:19 [jallan]
kp: we do speed tests with speech software. this is important
16:34:53 [jallan]
on of the most practical tests is cursor blink rate (max of 2)
16:35:11 [jallan]
present+ John
16:35:20 [jallan]
kf: this is tough to measure.
16:36:01 [jallan]
editors note applies to this
16:36:16 [jallan]
topic: 421 hands-off focus
16:36:46 [jallan]
gl: not convinced for the need for this.
16:37:17 [jallan]
jan: you need to be able to move focus to nested UA.
16:37:34 [jallan]
gl: it does not say this.
16:37:48 [greg]
that is, I think things have to implemented this way regardless of accessibility concerns.
16:37:48 [jallan]
js: john are there nested UA in mobile
16:38:11 [jallan]
john: yes, moving toward nested UA.
16:39:13 [jallan]
john: flash, get out of UA, open new app (Flash) then runs content. if you close browser, the flash wont close
16:39:29 [jallan]
jan: there are implementations that this is not true.
16:39:59 [jallan]
discussion 421-3
16:40:15 [jallan]
gl: 423 very necessary - return focus
16:41:11 [jallan]
gl: if nested, should return
16:41:27 [JohnS]
JohnS has joined #ua
16:41:30 [jallan]
kf: need review,
16:41:52 [jallan]
gl: 422 user can do something, 423 UA can do something.
16:43:11 [jallan]
422 implies 423
16:43:34 [jallan]
related to 212, 213, 221, 222
16:44:15 [jallan]
killing 423
16:44:23 [jallan]
return focus
16:44:52 [jallan]
need to review the GL2 items before setting action for 421, 422
16:45:14 [greg]
We might end up moving 4.2.2 Retrieve Focus but note it's not just about keyboard.
16:45:46 [jallan]
topic: 511 non-web-based accessible
16:46:11 [Jan]
ATAG2: Non-web-based authoring tool user interfaces follow user interface accessibility guidelines for the platform.
16:46:44 [jallan]
every platforms has a11y guidelines, follow them
16:47:12 [jallan]
kelly: borrow ATAG language
16:47:32 [Jan]
A.1.2.1 Accessibility Guidelines: Non-web-based authoring tool user interfaces follow user interface accessibility guidelines for the platform. (Level A)
16:47:33 [jallan]
Non-web-based user agent user interfaces follow user interface accessibility guidelines for the platform
16:48:13 [jallan]
john: is this really necessary
16:49:37 [jallan]
gl: windows a11y guidelines say have underline letters, if a UA doesn't do this, you are getting a pessimal experience
16:50:01 [jallan]
john: it is users choice to install a browser.
16:51:14 [jallan]
john: the way it is written, sounds like it could apply to non UAs
16:51:35 [jeanne]
rrsagent, do not start a new log [at midnight]
16:51:35 [RRSAgent]
I'm logging. I don't understand 'do not start a new log [at midnight]', jeanne. Try /msg RRSAgent help
16:51:46 [jallan]
jan: we have a definition of a UA
16:53:11 [jallan]
shadi: definition of UA. big concerns. Inherited from WCAG...UA anything that renders webcontent...webcontent is anything that is rendered in a browser
16:53:31 [jallan]
... definition of extension and AT are very similar
16:53:44 [jallan]
definitions are not clear.
16:54:11 [jallan]
3 types of user agents
16:54:38 [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.
16:54:48 [jallan]
jan: we may decide, scope it to only be desktop
16:54:53 [jallan]
shadi: why
16:55:30 [jallan]
jan: don't need web-based UA, because they fall under WCAG
16:56:11 [jallan]
shadi: functional requirements need to be the same.
16:57:36 [jallan]
shadi: AT that renders web content to help the user
16:57:53 [jallan]
kelly: webanywhere,
16:58:16 [jallan]
shadi: NPII, more webbased tools, part of the tools that will be used
16:58:37 [jallan]
shadi: the more definitions you have the more stuff can fall between the cracks
16:59:10 [jallan]
jan: UAAG has 100+ SC, don't expect from every browser.
16:59:37 [jallan]
shadi: web-based UA, interaction is not passed directly from the UA
17:01:20 [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.
17:02:52 [Ruinan]
Ruinan has joined #ua
17:04:23 [jallan]
kelly: similar to 332
17:05:12 [jallan]
js: propose using ATAG wording
17:05:12 [jallan]
Non-web-based user agent user interfaces follow user interface accessibility guidelines for the platform
17:05:36 [jallan]
stem change: Follow A11y Guidelines
17:07:43 [jallan]
gl: there may be conflicts with other guidelines. should have something in the doc, that says if there are conflicts UAAG overrules
17:08:29 [jallan]
john: problems with that. 3rd party developers. may not be familiar with all the platform spec, let alone UAAG guidelines.
17:08:43 [jallan]
... who decides whats a conflict.
17:08:58 [jallan]
... understand why it is here....
17:09:12 [jallan]
... creates a lot of cases where it hurts the user.
17:09:28 [jallan]
jan: don't agree where UAAG should overrule...
17:10:11 [RRSAgent]
RRSAgent has joined #ua
17:10:11 [RRSAgent]
logging to http://www.w3.org/2011/11/04-ua-irc
17:10:42 [RRSAgent]
RRSAgent has joined #ua
17:10:42 [RRSAgent]
logging to http://www.w3.org/2011/11/04-ua-irc
17:10:54 [jallan]
rrsagent, make minutes
17:10:54 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/11/04-ua-minutes.html jallan
17:12:42 [RRSAgent]
RRSAgent has joined #ua
17:12:42 [RRSAgent]
logging to http://www.w3.org/2011/11/04-ua-irc
17:12:56 [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.
17:13:51 [jallan]
john: n the mobile sphere, most manufactures define look and feel, and platform a11y requirements.
17:14:29 [jallan]
gl: there are some case where user of some platform want the application to behave consistently as other apps on the platform.
17:15:01 [jallan]
... there may be a user who wants the same app to behave the same way across all platforms, regardless of rules.
17:15:39 [jallan]
john: Facebook lock look and feel across all platforms
17:16:17 [jallan]
jan: filling gap with our own generic guidelines. we are a general purpose software guidelines.
17:16:44 [jallan]
john: disagree. these are general UI a11y guidelines.
17:16:55 [jeanne]
jeanne has joined #ua
17:17:21 [jallan]
kf: jan, you said you could meed UAAG but still have an inaccessible browser...example
17:18:29 [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?
17:18:32 [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
17:20:12 [jallan]
kf: @@in next draft, call out 521-3 with color and other scenarios, see what folks think@@
17:21:35 [jallan]
jan: don't want general software a11y guidelines
17:22:38 [Jan]
A.1.1.1 Web-Based Accessible (WCAG): Web-based authoring tool user interfaces meet the WCAG 2.0 success criteria.
17:25:40 [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.
17:25:59 [greg]
It conflates the two concepts of web-based UI and web-based UA.
17:27:15 [greg]
We agree on the concept, but the wording needs tweaking to clarify.
17:27:22 [jallan]
s/521-3 with color/511 with color
17:27:54 [jallan]
topic: 531 implement a11y features in content specs
17:28:11 [jallan]
kf: why is this here
17:28:31 [jallan]
jan: must support alt. bullet 2 is broad
17:28:59 [chsiao]
chsiao has joined #ua
17:29:24 [greg]
Kelly feels this is not testable because few if any tech specs call out their accessibility features.
17:30:22 [jallan]
kelly: how to test compliance. I am implementing html5, it has sparce a11y documented features, what happens now
17:31:23 [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.
17:31:28 [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
17:31:39 [jallan]
jan: that would be a very good thing.
17:31:49 [jallan]
kelly: kick it out.
17:32:22 [jallan]
greg: this kind of big topic discussion works better in person.
17:32:36 [jallan]
bring definition issues to the CG
17:32:40 [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.
17:33:33 [jallan]
531 NO
17:33:55 [jallan]
topic: 532 implement a11y features of platform.
17:34:01 [jallan]
kf: kick it
17:34:11 [jallan]
gl: sounds like 511
17:34:51 [jallan]
jan: good resources. should go to 511
17:35:15 [greg]
General noting overlap between 5.1.1 Non-Web-Based Accessible and 5.3.2 Implement Accessibility Features of platform
17:36:14 [jallan]
move intent of 532 to 511
17:36:16 [jallan]
topic: 541 follow specifications
17:36:34 [jallan]
jan: brutal to test
17:36:44 [jeanne]
action: jeanne to move IER of 5.3.2 to 5.1.1 Follow accessibility guidelines
17:36:44 [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].
17:37:15 [jallan]
gl: previous left out the exception. need access to generated content -- against other specs
17:37:38 [jallan]
jan: why are we the police man for other specs, we don't know how good those are.
17:38:02 [jallan]
kf: kick it out
17:38:21 [jallan]
kf: objections to deleting it...
17:39:02 [jallan]
gl: processing... do we say somewhere...follow a11y guidelines...this says follow all the non-a11y parts of the specs
17:40:15 [jallan]
gl: isn't it important that the UA parse html.
17:40:23 [jallan]
kf: don't want to be a policeman
17:40:48 [jallan]
@@next status update...call out the removals and why.@@
17:40:58 [jallan]
kim: need to capture the examples
17:41:15 [jallan]
topic: 542 handle unrendered technologies
17:42:49 [jallan]
kf: this is not an a11y thing.
17:43:14 [jallan]
john: in mobile, you will save the link but not content. there are rights management.
17:43:32 [jallan]
jan: it says "the user can choose a way"
17:43:47 [jallan]
kim: isn't this an easy win.
17:43:57 [jallan]
kf: perhaps not
17:44:39 [jallan]
jan: very tough to test...have to check what happen with the other 1m technologies.
17:45:11 [jallan]
kim: look at usecases, how would we solve them...where should we place them.
17:45:47 [jallan]
kf: this is not testable
17:46:16 [jallan]
kf: don't see an a11y benefit.
17:46:43 [jallan]
kf: need review. this should not be A.
17:47:14 [jallan]
topic: 543 alternative content handlers
17:47:28 [jallan]
kf: to vague, should be AAA
17:48:15 [jallan]
gl: select content, open in my preferred viewer
17:48:31 [jallan]
kf: does this mean text. I want this DIV to view in FF.
17:49:25 [jallan]
action: Mark to rework 543...tighten up, use mathml use case
17:49:26 [trackbot]
Created ACTION-653 - Rework 543...tighten up, use mathml use case [on Markku Hakkinen - due 2011-11-11].
17:51:11 [jallan]
@@move applicability note in principle 5 to conformance section at top of document -- Jan@@
18:06:37 [chsiao]
chsiao has joined #ua
18:07:45 [Zakim]
Zakim has left #ua
18:12:26 [jallan]
topic: 211 keyboard operation
18:13:45 [jallan]
js: need to do something major, usecase - keyboard emulators, intentional events, gestures, mobile devices,
18:14:38 [jallan]
kim: when we say keyboard access, we mean lowest demoninator. at unconference there was a misunderstanding...folks are say why need the keyboard
18:15:02 [jallan]
... we need to expand the meaning of our def of keyboard....
18:15:34 [jallan]
... what we really mean by keyboard access is a universal method of access.
18:15:55 [kford]
John: the way we solvedthis in Europe was just to say keyboard interface.
18:16:12 [jallan]
john: call is 'keyboard interface' and it means all of those
18:16:12 [kford]
John: It was understood by manufactures what we meant.
18:16:14 [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)
18:16:18 [greg]
ISO and ANSI used the phrase "keyboards and keyboard emulators"
18:16:33 [jallan]
jr: keyboard interface is WCAG language
18:16:52 [jallan]
gl: ISO ANSI -- keyboard emulator
18:17:21 [jallan]
john: keyboard emulator, they only generate keyboard events
18:17:44 [jallan]
keyboard used for navigation, direct commands, selection, activation, deactivation
18:18:23 [jallan]
js: could put in a note, or part of definition. there are other ways to do it other than keyboard emulation.
18:18:47 [jallan]
kp: keyboard is overloaded, how do you do touch. how do I get to touch with speech
18:19:11 [jallan]
john: on devices have touch correlated with mouse.
18:19:18 [greg]
a sixth use of the keyboard is modification (e.g. holding down shift during drag, holding down ctrl to slow animation).
18:19:25 [jallan]
kp: mouse in theory has keyboard equivalents
18:19:34 [jallan]
kp: still issues with hovering
18:19:54 [jallan]
jan: can attach a full keyboard to device, can have a keyboard interface
18:20:15 [jallan]
john: not every touch device had keyboard interface
18:20:38 [jallan]
jan: all have some keyboard underlying
18:20:55 [jallan]
kelly: not on the MAC OS ... no keyboard
18:21:16 [jallan]
jan: there are switch interfaces that create some keyboard simulator.
18:21:40 [jallan]
kf: if you just hook up a keyboard you cannot navigate to all UI objects
18:22:12 [jallan]
kp: mobile does not have arrows, control, alt, etc
18:22:24 [jallan]
keyboards are for text entry... no nav or control
18:22:44 [jallan]
js: what are functions of keyboard, make sure SC cover those
18:23:13 [jallan]
... spec will be more general if we focus on functions.
18:23:50 [jallan]
kf: broader issue...iphone, what are we expecting the user agent to do, I can touch every thing, do I need object navigation
18:24:25 [jallan]
jan: yes, scanning keyboard users, single switch users, speech input users.
18:24:37 [jallan]
what if platform doesn't do that?
18:24:44 [jallan]
jan: then platform is broken
18:25:24 [jallan]
gl: if platform is broken (non-accessible) can you have a UA on it that is fully accessible meets UAAG
18:25:33 [jallan]
john: car use case
18:27:25 [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
18:27:37 [jallan]
...huge issue. big vacuum
18:28:15 [jallan]
jan: exploring interface with out activating. need an input method for this
18:29:12 [jallan]
kf: what to we really mean by "All functionality can be operated via the keyboard using sequential or direct keyboard commands "
18:29:32 [jallan]
... do we need something that says next UI element...
18:29:56 [jallan]
jan: device needs to have that concept at a deep level.
18:30:11 [jallan]
Does the UA have to provide that.
18:31:31 [jallan]
does UA have to repair the OS
18:32:12 [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.
18:32:27 [jallan]
... don't want to leave out something important
18:33:30 [jallan]
jan: keyboard for android, hooks in to emulator
18:34:18 [jallan]
mh: webspeak, we named every action available in the browser, and allowed the user to choose a mechanism to cause them to happen
18:34:58 [jallan]
kf: OFFICE, expose all actions, user defines how they are activated.
18:35:31 [jallan]
mh: UA must expose this low level to the user/AT/Extensions
18:36:14 [jallan]
jr: this is called the standard input method on android.
18:36:42 [jallan]
kf: how do we make this SC say what we want it say.
18:38:13 [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
18:39:11 [jallan]
jr: these are the classes of things that the platform allows, need to work in the UA,
18:39:57 [jallan]
gl: need an API to expose/invoke actions/intentions available in the OS to the UA and user
18:41:15 [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
18:41:49 [jallan]
... thsi is hard because the software is not architected that way.
18:42:39 [jallan]
gl: there is a function 'refresh' - F5 maps to it, refresh button maps to it, menu button maps to it.
18:43:11 [jallan]
kf: are there ways of doing on to
18:43:43 [jallan]
jan: needs to be totally non-device independent
18:44:14 [jallan]
jim: do we need to talk to multimodal or intentional actions group
18:44:41 [jallan]
kp: there are input methods that are unaware of each other. UA doesn't know that user is using voice and touch.
18:44:57 [jallan]
... need something low level, very important.
18:45:40 [jallan]
kf: system know key or mouse event, they are separate....bubbling up the software decides what needs happen on the UI
18:45:49 [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.
18:45:53 [jallan]
kp: very complicated.
18:46:29 [jallan]
kf: third layer...programmatic actions....send button activate method
18:47:21 [jallan]
gl: need to know what has been standardized on.
18:48:33 [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
18:49:19 [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
18:50:42 [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
18:51:13 [jallan]
gl: devices lacking modifier keys.
18:51:50 [jeanne]
http://www.w3.org/WAI/UA/work/wiki/Keyboard_Interface_use_cases
18:52:12 [jallan]
kf: UA is collecting events/adtions from the platforms
18:52:41 [jallan]
... trying to get at that people made things that only worked with the mouse
18:52:51 [jallan]
... what are examples with touch...
18:52:57 [jallan]
hover
18:53:38 [jallan]
mh: touch interface nano interface to know touch in 3d (to get hover)
18:53:56 [jallan]
kf: what are we expecting UA to do. not have hover feature
18:54:35 [jallan]
gl: can have hover
18:54:47 [jallan]
gl: any problem with keyboard emulator
18:55:19 [Jan]
jan: universal input
18:55:29 [jallan]
kp: universal input interface
18:56:01 [jallan]
kf: close to agreeing on bluedog
18:56:22 [jallan]
... we mean that features work with bluedog input method
18:57:24 [jallan]
mh: core set of function/methods/actions that meet these SC, that expose core
18:58:13 [jallan]
jr: allow control with voice, gestures, keyboard, mouse, thought
18:59:21 [jallan]
jr: at top of document, we have set of assumptions - color
19:00:34 [jallan]
gl: everything must be doable by the mouse
19:00:39 [jallan]
?
19:02:50 [jallan]
js: some of 21x need to stay with proviso 'if you have a keyboard'
19:03:11 [jallan]
kp: if we do universal input can cover everything.
19:03:34 [jallan]
js: may be important to keep some as keyboard.
19:04:11 [jallan]
kp: need to define and reinforce UII (bluedog)
19:05:11 [jallan]
working lunch...
19:06:39 [jallan]
Jan: UA would not do this….it has to expose what is available on the platform May write an extension that exposes
19:12:21 [AllanJ]
AllanJ has joined #ua
19:12:32 [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.
19:12:40 [Jan]
Note 1: Meeting this success criterion does not require the presence of a conventional keyboard.
19:13:12 [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.
19:13:22 [AllanJ]
john: only people who will argure that keyboard is not the write word are those not involved in this work
19:13:32 [AllanJ]
kp: that;s a lot of people
19:13:51 [AllanJ]
... what it to be wider
19:14:24 [AllanJ]
http://www.mandate376.eu/
20:00:46 [jeanne]
jeanne has joined #ua
20:12:52 [AllanJ]
starting up again
20:13:12 [Jan]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2011OctDec/0045.html
20:16:52 [AllanJ]
2.1.1 Keyboard Access (Minimum):
20:16:54 [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)
20:16:56 [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...
20:16:57 [AllanJ]
...and/or touch input in addition to keyboard interface operation.
20:16:59 [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.
20:17:18 [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.
20:17:27 [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...
20:17:29 [Jan]
...and/or touch input in addition to keyboard interface operation.
20:17:49 [JohnS]
JohnS has joined #UA
20:18:11 [AllanJ]
gl: referring to mouse keys. it is not efficient and it requires you to see the screen
20:18:13 [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.
20:18:41 [greg]
What we had before covered that correctly.
20:18:57 [AllanJ]
ICT=information communication technology
20:20:14 [AllanJ]
electronic user interface is very broad
20:20:30 [AllanJ]
john: scope of this is everything ... anything that communicates electronically with something else
20:22:02 [AllanJ]
jr: there are other inputs that are analogue, path exception covers other technologies
20:22:29 [AllanJ]
gl: 3 different wordings -
20:23:11 [AllanJ]
john: this still needs more rewording
20:23:39 [AllanJ]
... input from a mouse can be mapped to a keyboard. but mouseing it time dependent. it is a path
20:24:27 [AllanJ]
gl: mouse keys explanation
20:24:40 [AllanJ]
john: this is not a base navigation function.
20:25:13 [AllanJ]
... navigation is a separate interface. they are not part of the keyboard. depends on form factor
20:25:51 [AllanJ]
... touch device only has text input via a keyboard. but keyboard has no arrow...those are handled by touch gestures
20:26:12 [AllanJ]
device pickup standard inputs and convert to something it needs.
20:26:48 [AllanJ]
kf: have a generic problem. software UA can work with more than one input device.
20:28:40 [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.
20:29:43 [AllanJ]
john: users communicate with devices with keyboard interface
20:30:10 [AllanJ]
... you are able to know the location of what is on the screen.
20:30:38 [AllanJ]
.... you must be able to navigate from element to element.
20:32:10 [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'
20:32:21 [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.
20:32:24 [AllanJ]
-----------------------------
20:33:33 [AllanJ]
2.1.2 Keyboard Focus: Every viewport has an active or inactive keyboard focus at all times.
20:33:45 [AllanJ]
the focus does not have to be displayed
20:35:13 [AllanJ]
Ted O'Connor Apple webkit
20:36:28 [AllanJ]
... does standards related things. not necessarily a11y (see James Craig)
20:42:12 [AllanJ]
ted: terms...not sure what to use. using keyboard interface is not a horrible idea.
20:42:43 [AllanJ]
... everything must be accessible from the keyboard...and mouse. they should not be priviledged.
20:43:28 [AllanJ]
... now we have more input methods. not mouse only. cann't be excluding. need to allow all input methods
20:44:01 [AllanJ]
jan: worried about first reaction to the guidelines.
20:44:18 [AllanJ]
ted: modality independent operation
20:44:40 [AllanJ]
add to preface, index, somewhere
20:45:53 [AllanJ]
Michael Cooper - intentional events
20:46:33 [AllanJ]
... problem with a11y of touch devices, even if you have gestures that blind folks can do....what about those using AT.
20:46:55 [AllanJ]
... how does AT send proprietary touch events to a device.
20:48:00 [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
20:48:16 [AllanJ]
... device is also able to send the hardware events.
20:48:30 [AllanJ]
.... critical on mobile, and most other platforms
20:49:12 [AllanJ]
have developers develop for intentions. critical for a11y, but easier for developes and mainstream folks (web events)
20:50:10 [AllanJ]
... proposed charter for 2 groups... intentional events (WAI group), web events WG, work on same issue. WAI would control and have deliverable
20:50:37 [AllanJ]
... possible user action events
20:51:13 [AllanJ]
... will complement ARIA work
20:51:49 [AllanJ]
js: cureently working on keyboard access....working on what is a broader term, that covers all input modality.
20:52:25 [AllanJ]
... things implied by the SC, navigation, command control, text input, etc
20:53:11 [AllanJ]
mc: group would accept input on requirements in the next few months. intermediate layer could be very important
20:53:31 [AllanJ]
... expand at future date, all events across all applications
20:53:49 [AllanJ]
... how much is science and what is art
20:54:29 [AllanJ]
... discussion about DOM activate event,
20:54:54 [AllanJ]
... intent should be different from a hardware specific event
20:55:34 [AllanJ]
js: maybe something we could point to.
20:55:50 [AllanJ]
john: implications for our keyboard work
20:56:02 [AllanJ]
... reders it redunant.
20:56:13 [AllanJ]
all--NO
20:56:36 [AllanJ]
john: when intentional events happen, then the layers become important
20:57:12 [AllanJ]
mc: hardware , user abstraction, other layers
20:57:36 [AllanJ]
kf: if I hit TAB what was the real intention, or I make some gesture what does it mean.
20:57:45 [AllanJ]
mc: context sensitive
20:58:11 [AllanJ]
gl: concept of layers is impt for AT, who gets what first
20:58:30 [AllanJ]
... interaction of AT with keyboard macros, bypassing each other or chaining
20:59:12 [AllanJ]
s/redunant/redundant
21:00:50 [AllanJ]
kp: what are you trying to solve
21:01:42 [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
21:02:36 [AllanJ]
gl: voice input interface on desktop, needs same layer of intentions as mobile
21:03:35 [AllanJ]
mc: need use cases, what are things users intend to do with web applications, any requirements related to AT
21:04:49 [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
21:05:11 [AllanJ]
mc: lines getting fuzzy.
21:05:50 [AllanJ]
ted: imagine 2 keyboard, one without spacebar. one can space between words, the other not
21:07:11 [AllanJ]
jr: app on android, that emulates events on droid from external AT with a keyboard
21:08:13 [AllanJ]
ted: scroll, swipe to bottom, loads new page. scroll event make this happen.
21:08:20 [AllanJ]
john: user must be able to stop the auto uploading.
21:09:24 [AllanJ]
jr: bluetooth input
21:09:59 [AllanJ]
jr: two finger turn to flip map. how do I do that from a keyboard.
21:10:14 [AllanJ]
mc: with intential events can do that
21:10:19 [AllanJ]
rotate event
21:11:19 [AllanJ]
kf: come up with a list of events...rotate. you figure out how you want us to tell you how to do it.
21:11:38 [AllanJ]
... r =touch rotate
21:12:11 [AllanJ]
jr: no current way to send intentional event from the keyboard
21:12:24 [AllanJ]
ted: thinks the list is small
21:13:15 [AllanJ]
john: AT can only send keyboard events. they don't have access to gestures. all functions are mapped to the gesture.
21:13:39 [AllanJ]
mc: could have keyboard command that will send a gesture
21:14:31 [AllanJ]
trickling through layers
21:15:12 [AllanJ]
web-application
21:15:41 [AllanJ]
intention layer mediating AT input and passing to the hardware
21:17:12 [greg]
It sounds like people here are building up different mental models, would be helped by very specific use cases/examples.
21:17:39 [jeanne]
scribe: jeanne
21:18:16 [jeanne]
MC: Some of the use cases have been documented, at least likely.
21:19:57 [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
21:20:47 [jeanne]
... chaals stated that the browser serves the javascript first.
21:21:43 [jeanne]
GL: The OS gets it first and passes events to the browser, which passes it to the web app
21:22:11 [jeanne]
... when we talk about keyboard events, they change formats
21:22:53 [jeanne]
... its a chain of emulation. "I got a VK (virtual key) event, so I will trigger a PgDn event
21:23:13 [MichaelC]
MichaelC has joined #ua
21:23:19 [MichaelC]
-> http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html Original Intentional Events proposal
21:23:42 [MichaelC]
-> http://www.w3.org/WAI/PF/src/iui Updated Intentional Events preliminary editors draft
21:24:03 [MichaelC]
-> http://www.w3.org/2011/08/intentional-events-charter Draft Intentional Events WG charter
21:26:22 [jeanne]
MC: events is an input into the application, and ARIA is more of an output
21:29:19 [hober]
hober has joined #ua
21:31:12 [jeanne]
KF: we will discuss how UAWG wants to participate in Intentional Events
21:33:39 [MichaelC]
MichaelC has left #ua
21:35:18 [jeanne]
RS: logical navigation and intent-based events
21:35:55 [jeanne]
... need to generate them based on (e.g.) touch, gesture, higher level commands
21:36:03 [jeanne]
... need to know the semantics of the target
21:36:51 [jeanne]
... bind the hardware level events to higher level components, like a event that operates a widget.
21:37:13 [jeanne]
... "open" is conistent across platforms
21:52:39 [jeanne]
JS: Like "Modality Independent Interface" and don't want to lose track of that phrase for Principle 2
21:53:14 [jeanne]
Topic: 2.2 Keyboard Focus
21:54:46 [jeanne]
RS: Is upcoming browser version going to continue to have a concept of keyboard focus?
21:55:01 [jeanne]
JR: Yes, it is already in Android
21:55:58 [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
21:56:44 [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.
21:57:30 [jeanne]
GL: Not necessarily - if you say click, then you want mouse focus; if you say enter, you want keyboard focus.
21:58:37 [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.
21:58:53 [jeanne]
2.1.2 is YES good to go.
21:58:59 [mhakkinen]
mhakkinen has joined #ua
21:59:12 [jeanne]
Topic: 2.1.3 Viewport Navigation
21:59:29 [jeanne]
KF: Problem with the stem
22:00:43 [jeanne]
GL: It conflicts with other standards that say that you don't want to take focus
22:00:59 [jeanne]
JR: On-screen keyboards are not part of the content viewport, it wouldn't apply.
22:01:58 [jeanne]
GL: It is really saying you can activate any viewport, that there is no sidebar that only takes mouse input
22:02:24 [jeanne]
2.1.3 is YES with BlueDog
22:02:48 [jeanne]
s/2.1.2 is YES good to go./2.1.2 is YES with Bluedog
22:02:55 [jeanne]
topic: 2.1.4
22:03:29 [jeanne]
KF: I think this should be AA or AAA, I don't think this is a hill to stand on.
22:04:14 [jeanne]
KP: There is an issue right now with Crtl-F in Google docs and Ctrl-F in Firefox.
22:05:48 [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?
22:06:52 [jeanne]
KF: there are always other ways to get to anything with a shortcut. Menus, preferences
22:07:23 [jeanne]
JR: Not applicable to every platform
22:07:40 [jeanne]
KP: There are users that this is the ONLY way to get to it.
22:09:01 [jeanne]
... it is consistency and user control that I am looking for. I never know which function will be invoked when I press F8.
22:11:30 [jeanne]
... for voice users, the different between 2 and 1 command is huge in efficiency and fatigue.
22:13:34 [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.
22:14:28 [jeanne]
JA: This also compensates for the javascript that grabs a keybinding for unknown tasks.
22:14:53 [jeanne]
2.1.4 is YES as is
22:15:13 [jeanne]
topic: 2.1.5 No keyboard trap
22:16:28 [jeanne]
group agrees it still happens
22:17:20 [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)
22:17:40 [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.
22:17:59 [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)
22:21:01 [AllanJ]
+1 kelly proposal to accept Jan's wording
22:22:21 [greg]
Minor concern whether "users are advised" would allow documenting a key combination on the web site, leaving users stuck.
22:26:11 [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.
22:26:36 [greg]
topic: 2.1.6 Separate Selection from Activation
22:27:34 [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.
22:28:11 [greg]
Kelly: At one point that was a Windows standard behavior, but it doesn't seem to work today.
22:28:28 [greg]
Kelly: Doesn't work that way in Firefox UI but does in its rendered content.
22:28:49 [greg]
Rich: A team led by AOL defined standard keyboard navigation for these types of controls.
22:30:58 [greg]
Kelly: Votes to postpone this SC.
22:31:40 [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.
22:32:14 [greg]
Kim: Big issue for speech users because can't hover.
22:32:14 [mhakkinen]
Yes...
22:32:15 [greg]
Jeanne: Big issue whenever actions cannot be undone.
22:34:21 [greg]
Jan: Needs to be reworded at least for e.g. in the middle.
22:34:44 [greg]
topic: 2.1.7 Follow Text Keyboard Conventions
22:36:12 [greg]
Jan: Can we take examples out of the SC?
22:36:33 [greg]
Jeanne: Without the inline examples readers don't understand it.
22:36:55 [greg]
Decision to move the inline examples to the Intent, otherwise OK.
22:37:11 [greg]
topic: 2.1.8 Make Important Command Functions Efficient
22:37:48 [greg]
Greg: "important" is somewhat subjective here.
22:38:03 [greg]
Kelly: untestable.
22:38:28 [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)
22:40:14 [greg]
Greg: Seems too low a bar, that the UA need only have two shortcut keys to pass.
22:41:14 [greg]
Kim, Jim, Kelly all approve that at Level A.
22:42:50 [greg]
Greg unhappy, but will not object.
22:42:59 [greg]
topic: 2.1.9 Allow Override of User Interface Keyboard Commands
22:43:53 [greg]
This is similar to 2.1.4 but adds requires single-key and key-plus-modifier, and is AA instead of A.
22:44:11 [greg]
Keeping it as is.
22:44:25 [greg]
topic: 2.2.1 Sequential Navigation Between Elements
22:45:13 [greg]
OK.
22:45:17 [greg]
topic: 2.2.2 Sequential Navigation Between Viewports
22:46:02 [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?
22:47:14 [greg]
Jan: Change to "all viewports" to make it require focusabiity of all viewports.
22:47:39 [greg]
Jan: So many SC, if can be combined would prefer them to be.
22:49:50 [Jan]
Action: JR to see if 2.1.3 and 2.2.2 can be combined.
22:49:51 [trackbot]
Created ACTION-654 - See if 2.1.3 and 2.2.2 can be combined. [on Jan Richards - due 2011-11-11].
22:50:52 [greg]
That is, fold 2.1.3 into 2.2.2 and add a reference in 2.1 to 2.2.2.
22:51:02 [Jan]
(folding 2.1.3 into 2.2.2 and make sure to say ALL viewports)
22:51:13 [greg]
topic: 2.2.3 Default Navigation Order
22:52:23 [greg]
Jan: Should this be the default, or could this be optional?
22:54:28 [AllanJ]
If the author has not specified a navigation order, the default sequential navigation order is document order. (Level A)
22:54:49 [greg]
OK.
22:55:13 [greg]
topic: 2.2.4 Options for Wrapping in Navigation
22:55:27 [greg]
Jan likes, Kelly dislikes.
22:57:11 [greg]
Kelly finds wording confusing.
22:58:29 [Jan]
2.2.4 Options for Wrapping in Navigation: The user can have sequential navigation prevent wrapping or receive feedback when wrapping. (Level AA)
22:59:52 [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.
23:00:39 [greg]
Kelly feels strongly it should be in content only, not UA UI.
23:00:55 [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)
23:01:27 [greg]
Greg agrees that if the platform convention is for menus to wrap silently, then UA menus can't be expected to violate that.
23:01:58 [mhakkinen]
What if ua menus or dialogs are web content?
23:02:18 [greg]
Kelly: This is about wrapping at end of the document, not horizontal wrapping between table rows and the like.
23:02:20 [mhakkinen]
Chrome settings, for example
23:03:12 [greg]
Greg: Wrapping is not going to the next row, but going back to the beginning of the same row.
23:03:18 [mhakkinen]
So ua has to know its own content even though AT doesn't
23:05:37 [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)...
23:05:54 [greg]
Kelly: It's end of page.
23:06:13 [greg]
Greg: Page or other set of elements that normally wrap in this browser.
23:06:43 [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)
23:06:59 [greg]
Postponing for further discussion later.
23:11:29 [greg]
topic: 2.3.1 Direct Navigation to Important Elements
23:12:11 [greg]
What is "important' elements?
23:12:30 [greg]
Greg: we say the user can customize what they consider important elements.
23:12:43 [greg]
Rich: make sure ARIA Landmarks are included.
23:13:02 [greg]
Rich: All content required to be in at least one landmark region so nothing orphaned.
23:14:17 [greg]
Related to 1.10.3 Configure Elements for Sequential Navigation.
23:15:13 [greg]
Jeanne reads definition of Important Elements from the glossary.
23:15:19 [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).
23:15:19 [jeanne]
Refer to the Implementing document [Implementing UAAG 2.0] for information about identifying and navigating important elements. @@ Editors' Note: Update links
23:15:34 [greg]
Jan: 2.5.7 is Configure Elements for Structural Navigation is AAA.
23:16:12 [greg]
2.3.1 is Level A without the ability to customize.
23:16:20 [greg]
The example is about numbering hyperlinks.
23:16:45 [greg]
Jan: To reach A every UA needs to have Mouseless Browsing built in or available in add-on?
23:17:56 [greg]
Kelly: Feels it shouldn't be Level A.
23:18:14 [greg]
Kim: Important for voice input.
23:18:15 [greg]
Rich: Important for low vision.
23:18:36 [greg]
Kelly: Should do exercise of prioritizing our Level A SC.
23:18:43 [greg]
Kelly: This used to be common, e.g. Lynx.
23:19:35 [AllanJ]
action: Jallan to create a list of all A SC for prioritization discussion on Thursday
23:19:36 [trackbot]
Created ACTION-655 - Create a list of all A SC for prioritization discussion on Thursday [on Jim Allan - due 2011-11-11].
23:19:51 [greg]
Kelly: Some browsers let you enter mode where it searches as you type.
23:20:13 [greg]
Agreement to keep this one.
23:20:23 [greg]
topic: 2.3.2 Present Direct Commands in Rendered Content
23:21:43 [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)"
23:23:11 [greg]
Kelly: "presented with" is too vague, e.g. show accesskey if you hover over it.
23:23:26 [greg]
Jeanne: then you fail the requirement for keyboard access to all features.
23:23:49 [greg]
Kelly: AAA
23:23:58 [greg]
Jan: 2.3.1 useless without 2.3.2.
23:25:15 [greg]
Kelly: 2.3.1 is UA added, 2.3.2 is about author-supplied.
23:25:35 [greg]
Greg: Could be clarified by adding wording from 2.3.2 into 2.3.1.
23:26:56 [greg]
Jan noted duplication of several SC in this section.
23:29:13 [greg]
Greg: Errors in merging documents. Want to check which version Greg and Kim submitted.
23:32:49 [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
23:32:49 [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].
23:34:54 [greg]
topic: 2.3.3 Direct activation
23:36:40 [mth]
mth has joined #ua
23:37:19 [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)
23:38:35 [greg]
2.3.3 is ambiguous about whether navigate to and activate needs to be a single operation.
23:38:51 [greg]
Kelly: 2.3 is all confusing.
23:39:42 [Jan]
also look at possible duplication: 2.1.4 Specify preferred keystrokes; 2.3.5 Allow Override of Accesskeys
23:41:44 [greg]
Greg and Kim will review all of 2.3.
23:43:31 [greg]
Agreement to suspend the SC review at this point, as only 17 minutes remain.
23:47:18 [greg]
Discussion with Judy Brewer.