14:04:09 RRSAgent has joined #ua 14:04:09 logging to http://www.w3.org/2005/03/03-ua-irc 14:04:27 jim has joined #ua 14:04:29 rrsagent, make log world 14:04:41 kyle has joined #ua 14:05:08 JRG has joined #UA 14:05:58 introductions 14:09:09 louie has joined #ua 14:10:35 discussing Mozilla keyboard model from Sun Beijing 14:11:15 overview of the UAAG meeting today 14:11:53 development of test suites for xhtml, joint meeting with xhtml wg in afternoon 14:14:40 korn has joined #ua 14:16:31 UA test suites-have been working on tests for 3 years. history of UAAG, and process of developing UAAG 14:18:30 jrg demos uaag test suites system 14:24:42 http://cita.rehab.uiuc.edu/wai-eval/index.php?option=Test%20Suites 14:30:23 contact jrg for login/password to enter system for conducting test jongund@uiuc.edu 14:32:35 testging... 14:32:54 jim has joined #ua 14:33:01 JRG has joined #UA 14:33:16 cklaws has joined #ua 14:33:20 kyle has joined #ua 14:34:21 Jessie (Sun) demos mozilla accessibility 14:36:22 speech access on sun desktop with mozilla 14:39:05 aaronlev has joined #ua 14:40:53 there is a describe feature, but need more "help" for blind users. submit feedback to bugzilla.gnome.org file against screenreader or mozilla at bugzilla.mozilla.org 14:41:19 File Gnopernicus bugs: http://bugzilla.gnome.org category 'gnopernicus' 14:41:30 File Mozilla accessibility bugs: http://bugzilla.mozilla.org 14:41:59 Can discuss Gnopernicus (and general GNOME) accessibility bugs: gnome-accessibility-list@gnome.org 14:42:04 screen reader making xul accessible 14:42:30 xul accessibility guidelines 14:43:17 http://www.mozilla.org/access/xul-guidelines 14:44:49 f7 caret browsing mode, arrow keys control audio rendering (character, word, line) 14:45:57 word navigation caret position is different from character navigation caret position. 14:47:02 can change caret postion behavior in user profile (about:config) 14:48:50 mozilla prefers looking at system settings to establish browser behaviors 14:52:18 showing mozilla with speech in uaag test suites. 14:53:12 label on input controls, if there is no label on form control will screen reader ignore it or guess. preference is to ignore. 14:54:07 hpr looks for "for" attribute, then "label" element, then proximity algorithm 14:55:56 korn: first release, follow the rules and only the rules, line in sand for developers, push good behavior, then come back and let assistive tech fill in the gaps 14:57:00 jg: if author puts in appropriate code then the user agent should use it. and use heuristics only if proper code is missing 14:58:19 alt ] to exit form control 15:00:36 move in to radio button, presented redundant information - spoke "value" and on screen label text - blue blue 15:07:33 mimasa has joined #ua 15:07:54 change value=1, still said blue blue, discussion ensued, different browser behavior and assistive technology behavior 15:12:36 optgroup-discussion about speaking group label, when or if it should occur 15:13:54 http://cita.rehab.uiuc.edu/mozilla/ts-test-page-input.html 15:15:59 discussion of fieldset/legend rendering and screen reader use 15:19:02 of them with radio buttons and checkboxes 15:19:51 discussion of disabled form controls, should not be able to tab to disabled controls. should be able to tab to read-only controls and read them 15:24:42 http://cita.rehab.uiuc.edu/mozilla/ts-index.html 15:29:32 data table test http://cita.rehab.uiuc.edu/mozilla/ts-test-page-text.html#data 15:31:15 discussion of character reading mode between table cells, should it say new table cell or just continue reading the next character regardless of cell boundries 15:32:45 http://cita.rehab.uiuc.edu/mozilla/ts-test-page-input.html 15:39:36 discussion of definition of "container" 15:40:09 iframe test. 15:42:50 gnopernicus uses platform specific api and role, doesn't currently have a 15:43:04 break until 11am 15:44:14 gnopernicus doesn'tcurrently have a role for iframe, discussion of xhtml existence of frame, xlink, embedding 16:05:48 accessible xul authoring guidelines http://www.mozilla.org/access/xul-guidelines presentation 16:06:43 by aaron leventhal 16:06:57 extension writers should follow these 16:08:44 2. no keyboard access to the toolbar in mozilla, toolbar items should be in the menus 16:10:01 3. define sensible focus behavior - change order of 2 and 3 to make focus items occur in tandem 16:11:35 e.g. change from day view to week view, were on jan 7 in day view, when change to week view, focus should still be on jan 7 in week view. focus should not just disappear 16:14:31 4. problem with multiply defined access keys, do they cycle through. mozilla developer toolbar key controls override other extension toolbar keys 16:20:42 ** need for review of xul access key faq http://www.mozilla.org/access/keyboard/accesskey for linux 16:21:40 mozilla trying to merge windows, linux, mac hci guidelines 16:22:44 jessie has joined #ua 16:24:02 8. make it stronger. "don't use mouse only controls" if you only have mouse only controls you are not accessible. 16:25:05 in sun, you can attach actions to events (?), do a mouse over and substitute key press or other appropriate action 16:26:58 suggest putting in context menu 16:28:46 can't scroll from keyboard in xul 16:33:24 need functionality to change the column width from the keyboard 16:39:04 themes - need to respect color and font size on the desktop - from 508 1194.21 - should inherit 16:40:21 link to -moz- mozilla proprietary theme definition 16:41:57 ask developers to test, perhaps develop xul accessibility test suite. e.g. change to large fonts on the desktop, does the xul widget change fonts 16:42:51 xul discussion ends 16:42:57 http://www.disability.uiuc.edu/ita/dwatt/accessext/accessibilityext.xpi 16:43:51 discussion of accessibility extension for mozilla from uiuc 16:52:50 navigation dialog - should have "move to" as well as activate link, allows user to read information around the anchor to get the context of the link 16:56:02 not picking up alt text of images, blogs.sun.com/korn 16:58:34 was an error in the page not with the tool. 16:59:27 How to restyle focus outline using CSS: https://bugzilla.mozilla.org/attachment.cgi?id=165562 17:04:32 we will move the wall at 3:30 you are next door 17:05:38 break for lunch, eat in room, discuss xhtml issues in prep for meeting 17:47:29 aaronlev has joined #ua 17:48:32 alt popup extension for mozilla http://piro.sakura.ne.jp/xul/_popupalt.html.en 17:54:53 cklaws has joined #ua 18:04:07 uaag svg joint meeting 18:04:49 Craig Northway from SVG (canoon) 18:04:59 introductions 18:06:19 review uaag svg accessibility document 18:06:46 svg group has a draft response, not yet ready to deliver to uaag 18:07:17 want to learn about plans for svg test suites. 18:07:58 uaag charter task the group with developing svg test suites, want to coordinate with svg group test suites 18:08:08 kyle has joined #ua 18:08:14 want to have svg accessibility in the useragent 18:09:48 personal comment (Craig) - document is push for things beyond the svg spec, they are more user agent items, and are something that is better placed in the conformance document 18:10:58 jg: want implementation to include accessibility, using style to change the content 18:11:21 e.g. gray scale, 18:13:45 seems to be a year or two lag in the implementation of accessibility features. user agents may include different accessibility features, which is the author or assistive technology supposed to pay attention to? 18:14:59 jg: gives accessibility scenarios. 18:15:32 specs need to provide an expected set of behaviors for the rendering of the items. 18:15:39 Craig: 18:16:53 color changes - they are useful, user may want to change the color of the svg. this does not fit with the rendering model, can't use a compositing operator, 18:17:23 do you want to change the way individual items blend together or change the whole image 18:18:10 korn: AT users want to use one tool across the platform 18:18:40 compositing is beginning to happen on the desktop, want to have more control over the rendering. 18:19:47 craig: color items are more related to the filtering effects in svg 18:20:30 jg: comp-op property 18:21:01 craig: better to do with filter effect (my opinion) 18:21:40 working group thought it was a post rendering issue, add requirements to the accessiblity appendix, 18:22:30 svg 1.2 is being redone at the moment to a full version. 18:22:53 any new drafts will have an accessibility chapter. 18:23:48 korn: svg to make an engine diagram, it is broken into parts, exhaust, fan, 18:24:24 with a compositing manager, could gray out everything but exhaust 18:24:39 craig: could also do it with filters. 18:25:52 jg: with the current immplementation, author would have to script the make the section gray work now 18:27:13 craig: this is a large expansion of the color statement in the document. 18:27:29 you want visual access to the dom and interact with them 18:28:07 korn: currently can have personal custom style sheet, UA allows this to happen 18:28:41 craig: can use css to style, current svg views don't allow personal style sheets 18:30:10 korn: need to have the svg guidelines make authoring suggestions, 18:30:53 what are the grouping categories? 18:31:15 craig: enumerates them 18:31:30 korn: any relationships other than grouping 18:31:53 craig: css selector relationships (parent, child, etc.) 18:32:28 korn: call out relationship, 18:33:12 craig: things can have description, title, etc. with the element, but not an id distant reference 18:34:37 ah, like a label for the item, like a tooltip, or you could group the text and the item 18:35:32 korn: want a group operator and label operator so you can extract the text 18:35:48 craig: could genericize it. 18:37:36 korn: title and desc are not rendered on the display. if already have a callout, make a tooltip for an item it becomes the accessible description of the time, using the label/for then can programmatically link the description and item. 18:38:49 craig: hint element, if tooltip enabled then the hint will be used for the tooltip, but must be a child of a graphical element. hint is a string 18:39:18 korn: ideally hint would be an element that can form a relationship with other elements. 18:39:57 jg: ***action send relationship concept to svg (new document) 18:40:25 color issues can be resolved with filter options. 18:41:08 craig: would be part of the accessibility chapter not part of the spec 18:41:35 jg: need to continue the dialog 18:41:56 craig: would be a recommendation not required in the spec 18:42:29 --include accessibilty features as part of svg examples 18:42:51 craig: accessibility examples are in a seperate section 18:43:26 korn: makes sense, but all other examples exemplars of accessibility. 18:43:51 then have a special section extending the accessibility. 18:44:23 craig: test suites, need help writing the examples, we can do svg, don't know the accessibility part, 18:44:57 korn has joined #ua 18:45:05 jg: would love to work with you, connect us with the test suite contact 18:45:08 test. 18:56:07 author has to provide some information about an image, that explains the images and the relationships between items 18:58:50 svg tiny, small subset of svg-full for mobile devices, contains most useful features. 19:00:06 may be more implementation on the desktop as a result of svg-tiny, development is less costly 19:00:22 --outline view of the document 19:00:45 craig: use xslt to transform to html 19:01:10 aaron: assumes static content. 19:01:42 korn: getting all of the rendered information out of the svg objects...bounding rectangles 19:02:33 craig: bounding comes from the dom. svg extended the dom, in the svg spec.get bounding box, tranformation matrix, 19:02:52 user agent will know this from the dom. 19:03:12 screen magnifiers will find this useful. 19:04:12 craig: will be addressing text only view in the accessibility chapter, 19:05:31 jg: a spec has to have features that all users can benefit from. (cynically) 19:06:00 korn: try to have things in teh spec that are multi use. 19:06:58 jg: have structure, so the user can style the information to meet their needs. the author can see this and create new ways to present information 19:07:43 craig: have to do things structurally if you have animated scripted content. 19:08:34 slatin: multimodal demos yesterday, showed uses for other folks than just those with disabilities, electronic curb cuts 19:09:16 --all items in dom have a focusable property 19:10:01 cklaws has joined #ua 19:11:01 what about button with drop shadow, can you focus on the drop shadow 19:11:14 depends how it was created 19:11:34 craig: need to look a nested focus 19:12:17 author decides what is focusable 19:13:03 aaron: focusablity is not boolean, should be part of main tabbing order, 19:14:51 craig: focusable - mean item can get focus, but not how to navigate to it. can use navnext and navprev to move focus, author must provide all of the hooks 19:15:28 nav-up,down, left, right. (not in/out) 19:23:09 ---mozilla keyboard proposal 19:24:47 www.mozilla.org/access/keyboard 19:26:53 http://www.mozilla.org/access/keyboard/proposal 19:27:40 review document 19:30:25 frame boundries and caret movement, caret stops 19:31:22 frames is different dom. 19:32:41 aaron: from the user view, a frame is just a container on the screen, the user doesn't care what it is, just want to select into it. 19:33:20 **no stong opinion of the group about frame boundries 19:34:27 ctrl+right - different behaviors depending on OS 19:34:38 mozilla should follow the desktop 19:36:53 --discontinous navigation 19:39:23 ok 19:40:25 --text selection 19:43:16 --keyboard across frame boundry 19:46:03 tab and f6 should include both frameset and iframe - move across frame boundry 19:46:58 --form control navigation 19:49:08 jg: when you move caret into form control, have status line update to include form label, author will see some benefit. 19:51:29 korn: suggest haveing about:config setting to turn this off. screen readers check status line for changes and reads it out 19:54:48 aaron: use alt+] to move to next form control, (or some other character) 19:55:54 discussion of using alt] to move in and out of form control moving down the page and alt[ moving in and out of form controls up the page. 19:56:38 perhaps have additional navigation schemes. 19:57:19 look at this function more closely 19:59:00 jim has left #ua 19:59:18 Keyboard bindings for get out of a form control 19:59:53 Aaron: Use alt+shift+arrow for movng instead of control+[ 19:59:59 Internationalization issues 20:00:21 Alt+shift is avalaible on most keyboard 20:00:44 Kyle: Is arrow the right key 20:01:21 PK: How do you tell if you are in edit mode? 20:01:38 PK: GP will tell you that you are in edit mode 20:02:17 PK: GP will tell you when you leave something 20:02:31 AL: Arrows are useful for table navgation 20:03:01 AL: Atl+shift+arrow may be used for directional navigation, may get back into the trunk 20:03:14 PK: There is not a consensus 20:03:31 AL: There doesn't seem to be agreement 20:03:44 Kyle: What is the conclusion 20:03:53 AL: There is no conclusion 20:03:55 Steven has joined #ua 20:04:04 Steven has left #ua 20:04:26 http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_13228 20:42:21 shinichi has joined #ua 20:43:22 mcmay has joined #ua 20:44:05 RichS has joined #ua 20:44:18 jg: Comments on 24 Feb draft of XHTML 2 20:44:24 aaronlev has joined #ua 20:44:44 Steven has joined #ua 20:45:13 jg: We talk about enabled elements, maps to focusable. 20:45:29 mdubinko has joined #ua 20:45:58 sp: I have an issue with "visible" here. 20:46:14 jg: cite attrib in quote element. Is that focusable? 20:46:34 sp: not at the moment. cite is metadata. may well be navigable, but only to the extent that all metadata is navigable. 20:46:45 sp: Link elements are not focusable in this definition. 20:46:57 jg: elements with event handlers? 20:47:23 sp: not necessarily interactive (load, submitdone in XForms). XForms is full of non-interaction events. 20:47:32 jg: a paragraph with an onfocus/onblur event? 20:47:55 sp: by putting a listener on an event, doesn't mean that element is ever going to get that event. 20:48:29 Mark Birbeck (mb): If you stick a listener on a p, doesn't mean the p originates the event. 20:49:11 al: Could put focus on buttons contained within. 20:49:24 jg: we hav a checkpoint to activate event handlers. 20:49:40 cl: ...using the keyboard 20:50:05 jg: on an onmouseover event, UA should also supply a way to handle via keyboard. 20:50:56 sp: these are requirements on the user agent and not the language. 20:51:03 jg: what do you define focusable as? 20:52:00 mb: need to specify the type of events. DOM UIEvent should be a part of this. 20:52:21 rs: Just because you don't have it focusable doesn't mean you don't want it in the tabindex. 20:52:50 sp: currently defined as all elements that can receive a DOMActivate. Can't DOMActivate a p. 20:53:22 rs: Other side of this: someone wants to put a handler on a div/span. 20:53:43 rs: This looks like anchors/form elements only. 20:53:54 rs: Example: custom widget bound to the model using div/span. 20:54:05 sp: that could get a DOMActivate apart from these? 20:54:07 rs: yes. 20:54:20 mb: Fall under the category of something with an event listener? 20:54:25 rs: Could we bind a listener? 20:55:08 sp: XML Events does the binding. Want to be more generic than XHTML 2. Want to say that any element can create a handler. 20:55:45 sp: Don't want to make a submission element focusable. 20:56:13 9FOR EXAMPLE0 20:56:22 (for example) 20:57:07 sp: roles are far more generic, but you could say elements that are targeted by the access element, that makes those focusable. 20:57:26 cl: How to expose roles? 20:57:31 sp: targetrole 20:58:10 sp: If you have 16 bound to same key, will scroll between them. 20:58:25 al: If there are a lot of descendent elements, will put a handler on a parent element. 20:58:30 sp: Not all events bubble. 20:58:32 al: Focus does. 20:58:39 sp: XForms focus doesn't bubble. 21:00:30 jg: We have a requirement to let people choose their own style, and UAs must or should conform to UAAG 1.0. 21:00:41 sp: If we say UAAG, other points are subsumed? 21:00:44 jg: Yes. 21:02:39 sp: to conform to UAAG 1.0, would have to select a conformance level, and so wouldn't need to specify single-A. 21:02:54 jg: Could say must conform to A, should conform to AA, may conform to AAA. 21:05:33 mm: UAAG contains checkpoints that involve repair, because of legacy. Could remove those from conformance for something like XHTML 2. 21:05:48 sp: Many of our UAs are plugins. How does that affect it? 21:07:01 mb: Wouldn't think it would be a problem. 21:07:19 sp: test cases? 21:07:26 jg: We'd like to work with you on that. 21:08:37 jg: We have an eval system for UAAG. Users can look at our requirements. 21:09:02 (FYI, we have some example documents at: http://www.w3.org/2000/07/8378/xhtml2/spec-examples/ ) 21:09:11 jg: If we can build a system that creates the proper markup, we can build it. 21:09:19 rrsagent, pointer? 21:09:19 See http://www.w3.org/2005/03/03-ua-irc#T21-09-19 21:09:47 jessie has joined #ua 21:09:54 jg: We can generate our own reports out of this. 21:11:20 sp: suppose we have a kiosk. Then can have no XHTML 2 impl. 21:11:55 jg: Kiosks can have a keyboard or alt UI working via accessibility APIs. 21:12:12 pk: Also onscreen keyboard. 21:12:18 sp: Do those count for keyboard compliance? 21:12:20 mm: Yes. 21:14:51 jg: Most UAs don't support nav to headers. Opera, ATs. Hard for authors to know that they did the right thing. 21:15:07 jg: Should be some language that UAs are expected to do something with header other than style it. Navigation to headers. 21:16:01 sp: Does UAAG say that? 21:16:51 jg: We require users to move focus forward and reverse, then to be able to navigate structure (P2). 21:18:03 pk: Under 1194.25 of Section 508, kiosks must be directly accessible without users having to add AT. Also 1194.21(a), for keyboard access. 21:18:16 pk: Protocol needs to generate content that is accessible to systems with keyboards. 21:18:38 mb: We can't mandate a keyboard, but can make it possible. 21:19:27 mb: Do we need to refer to UAAG if we say section element must be focusable? 21:19:29 rs: no. 21:19:55 Melinda Grant (mg): What about printer devices? 21:20:21 jg: We have "implement acc. features of specs". That could be considered an acc. feature of the spec. 21:20:41 jg: Could have an appendix saying "these are the acc. features." 21:21:46 mb: Should add to our spec, headers must be focusable, then say in appendix that we conform to 9.9 of UAAG? 21:21:47 jg: yes. 21:22:00 s/headers/section/ 21:22:27 mb: Another question of whether devices have to support focus. 21:23:21 sp: So since you don't support focusable, don't need to support by UAAG. 21:25:18 jg: UAs that support screen, braille and speech apple? 21:25:29 pk: No. Say, is this a user agent or something else? 21:25:53 sp: Google is a UA to us. Follows processing rules of HTML. 21:26:44 sp: If it's pretending to handle the content, that's our definition of a user agent. 21:27:56 pk: Separate agent from user agent? 21:30:32 cl: UAAG and XHTML 2 are two different specs. 21:31:06 jg: Don't want to make it easy to get out of UAAG, or put it off. 21:31:14 mb: We should really be doing this appendix. 21:33:07 jg: There's agreement that desktop browsers should conform to UAAG. The outliers (printer, refrigerator) notwithstanding, we should push people to conform to UAAG. 21:34:11 jg: Take a class of "desktop" for normal browsers, e.g. "utility" for others. 21:34:28 pk: There's parsing the protocol, then being a validated presentation of the protocol, which means meet UAAG. 21:34:42 sp: Could be possible. 21:35:02 rs: We could go through the UAAG requirements, list what is required to do that. 21:35:59 sp: One of the reasons of XHTML 2 is easier and better accessibility. 21:36:25 sp: So it's absolutely understandable. We want to encourage accessibility as far as possible. Need a consensus position where you get what you want and we get through CR. 21:37:33 pk: is there a situation where we can be hardnosed? e.g., a printer with a screen and a keyboard. 21:37:48 mb: Printer display could be just a small LCD. 21:38:05 mg: Printer could allow document to be displayed to LCD, and maybe interact. 21:38:42 jg: UAAG wasn't thinking about a refrigerator. 21:38:55 sp: Could be that UAAG's UA is different from XHTML's UA. 21:39:09 mg: New devices may deserve a new term other than UA. 21:39:35 jg: Could limit scope to a set of devices. 21:40:11 mg: Or "as fully as possible"? 21:40:18 pk: No, that's subjective. 21:40:52 sp: answer to "is h element required for a section" is no. We're only applying facilities. 21:41:12 mb: Section may not have any rendered consequence. 21:41:15 cl: Could have a title? 21:41:19 sp: Could have a role... 21:41:29 mb: Could be for the author's convenience to have n sections. 21:42:16 jg: Section is implying structure while div is more stylistic. 21:42:27 sp: Disagree. 21:44:03 jg: abbr expansion? 21:44:08 sp: possible in style sheets. 21:44:18 jg: If UA came with default alt stylesheet. 21:46:11 jg: I don't think it needs to be a requirement of the UA. 21:46:35 jg: Doesn't have to be a required feature. But useful. 21:47:01 sp: You'll see we don't specify presentation rules. We do have a default stylesheet in the back. 21:47:07 cl: No techniques document to go along with it? 21:47:10 sp: Not yet. 21:47:53 (FYI, "XHTML Ruby Support" provides an option to render abbr's title as ruby: http://piro.sakura.ne.jp/xul/_rubysupport.html.en ) 21:47:55 sp: cite is a particular case of metainformation. You can add metadata much more widely in XHTML 2 than HTML 4. 21:48:27 jg: What's its navigation mode? 21:48:33 sp: none. That's the case with all metadata. 21:48:47 sp: If the intention is navigation, then you put an href and a cite. 21:49:57 sp: href and rel="cite" 21:50:08 mb: Could use dc:creator as well. 21:51:21 rs: longdesc replaced with container element ("

") so there's the possibility of rendering beneath. 21:51:57 jg: possible to disable access element? 21:52:08 rs: can let UA assign it. 21:53:07 sp: I heard you wanted id in access. 21:54:21 rs: UA solves key conflicts. 21:54:28 jg: How does the UA communicate to the user? 21:54:45 rs: will have to bring up a dialog. 21:54:53 sp: addressed by UA. 21:55:54 rs: I also mentioned an idref. Still needed? 21:56:00 cl: No, because now we have targetrole. 21:56:47 jg: does default styling mode reference keyboard? 21:58:30 jg: Could create a best practices document for this. 21:58:57 mb: XForms hints. Concept of an ephemeral message, like a tooltip, but in a voice context, what does that mean? 22:03:05 jg: Can XHTML tables still be used for layout? 22:03:13 sp: It's not the intention, but you can't stop people from doing it. 22:09:31 jessie has left #ua 22:14:09 (re tables: in XHTML2 you can't even set border nor width without style sheet. It's still possible to abuse them, but I guess there's less motivation to do so) 22:14:24 mimasa has left #ua 22:19:52 mdubinko has left #ua