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.