13:56:19 RRSAgent has joined #aapi 13:56:19 logging to http://www.w3.org/2009/10/06-aapi-irc 13:56:29 rrsagent, make log world 13:56:39 meeting: ARIA User Agent Implementation Task Force 13:56:44 Chair: Cynthia_Shelly 13:59:31 WAI_PFWG(AAPI)10:00AM has now started 13:59:39 +Andi_Snow_Weaver 13:59:45 Andi has joined #aapi 14:00:43 +??P18 14:01:03 zakim, ??P18 is me 14:01:04 +Stevef; got it 14:01:33 passcode? 14:01:48 aapi 14:01:58 thanks... trying for 3rd time 14:02:20 davidb_ has joined #aapi 14:04:50 +[Mozilla] 14:05:03 Zakim, Mozilla David_Bolter 14:05:03 I don't understand 'Mozilla David_Bolter', davidb 14:05:08 Zakim, Mozilla is David_Bolter 14:05:08 +David_Bolter; got it 14:08:03 +Cynthia_Shelly 14:08:36 rrsagent, make logs public 14:08:46 html5 / aria element mapping table http://www.paciellogroup.com/blog/misc/ARIA/html5-elements1.html 14:08:48 scribe: Andi 14:08:57 meeting: AAPI 14:09:01 chair: Cynthia 14:10:46 SF: maps HTML elements to related aria roles 14:10:56 cyns has joined #aapi 14:11:31 SF: if something is in the DOM, it can't be overridden 14:11:42 CS: everything in the DOM is overridable 14:12:18 CS: agree that elements that have strong semantics shouldn't be overridden 14:12:38 DB: are we talking about telling authors they shouldn't override them or that we shouldn't allow it 14:12:40 url? 14:12:52 html5 / aria element mapping table http://www.paciellogroup.com/blog/misc/ARIA/html5-elements1.html 14:13:08 DB: ARIA is so that authors can tell ATs what's going on 14:13:39 DB: worry that we're not all on the same page about what ARIA is for 14:14:00 SF: agree - but we need to document the reasons 14:14:22 davidb_ has joined #aapi 14:15:16 CS; consistency - like idea of attributes having default values, seems like a good education tool, seems clean as an implementation 14:15:21 DB: code would not be that clean 14:15:56 CS: like it best for interactive element - HTML menu tag, query role, it would be menu 14:16:09 DB: think that would happen without adding ARIA to the DOM 14:16:25 DB: worry is that there are people who think we are adding ARIA to the DOM automatically 14:16:46 DB: should map markup based on markup semantics, where author adds ARIA markup, we take that 14:17:09 CS: didn't mean to say add ARIA to the DOM, some attributes have default values which can be changed by ARIA 14:17:22 CS: worry about "checked" and "aria-checked" 14:17:32 DB: if markup gives you what you want, use markup 14:17:53 CS: worry about "input type=checkbox" and "command type=checkbox" too 14:18:27 CS: command is like a menu but can have input controls 14:18:52 CS: several places in HTML 5 where there are multiple ways of doing things, not clear how an author knows which to use 14:19:35 CS: if you're overriding a heading to be a banner, maybe should generate a warning 14:19:47 CS: but not sure it shouldn't be allowed and not sure it should even be a validation error 14:19:58 SF; it's a matter of working out when it should be a warning and when it shouldn't be 14:21:39 SF: the role doesn't do anything except explain to the AT "what" something is. It's the behavior that really makes it what it is. 14:21:53 CS: need to be pretty targeted about it. 14:22:05 CS: ARIA role on iframe or object doesn't make much sense 14:22:14 CS: canvas does because it can be an image 14:23:06 SF: iframe could be a document or an alert 14:23:38 SF: might want AT to go into application mode to interact with a video 14:23:51 DB: who gains if we limit the ARIA roles you can put on an element 14:24:05 SF: end user will gain if the developer is not coding it correctly 14:24:37 DB: potential to gain something if people are doing something they shouldn't be at a cost of making it more complicated 14:26:04 DB: simplify the browser implementation by just saying use ARIA if it's there 14:26:24 CS: okay with that but may not be the right answer for validators 14:26:56 SF: best way to tackle is to look at what's currently in the spec and chip it away 14:27:41 SF: only arguing about the stuff they see as problematic, like the "a" element 14:28:05 SF: what are the arguments for overriding something 14:28:26 CS: make a column in the table for what is being proposed as something that can't be overridden 14:30:39 CS: add a column for strong/weak? 14:30:50 SF: better to start with the spec table 14:31:57 is http://etherpad.com/ accessible? 14:32:26 SF: find the ones we disagree with, start to get some arguments together as to why we disagree 14:33:29 SF: crosses some other work so should get others involved as appropriate 14:34:52 CS: HTML 5 accessibility task force hasn't started yet. Looking for facilitators now. 14:35:46 SF: will grab tables from HTML 5 spec, put into Excel document, then we can divide up 14:37:45 Looking at tables in 3.2.6 of html5 / aria element mapping table http://www.paciellogroup.com/blog/misc/ARIA/html5-elements1.html 14:38:13 element - does have a native mapping but disagree that semantics can't be overridden 14:38:50 CS: thinking multiple columns 14:39:28 CS: native semantics, override yes/no, mappings for each API (start with MSAA) 14:40:10 SF: landmark roles don't really make sense 14:40:29 CS: override column could list the types that can override it 14:40:48 AS: rationale for why we think things can be overridden? 14:40:50 SF: yes 14:40:55 CS: add comments column 14:44:10 CS: sounds like everything can be overridden by widget because can turn any text element into something interactive 14:44:47 SF: can't think of an example of where "radiogroup" would be appropriate for