<davidb> hi all are we live?
<Stevef> yes
<Stevef> http://www.w3.org/html/wg/tracker/issues/85
<Stevef> ARIA roles added to the a element should be conforming in HTML5
<scribe> scribe: janina
cs: there's a bug on this, yes?
sf: yes, and a change proposal.
<cyns> cp url?
<Stevef> http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAonanchor
sf: i agree with it, of course
rich: +1
cs: still reading
sf: only difference with this and full proposal, this has text box
<Stevef> draft aria mapping http://www.paciellogroup.com/blog/misc/HTML5/aria-html5.html
<davidb> db: +1
cs: we want to be precise. we're not saying any and every element can be overwritten.
... what do we call it--we don't want to spend a lot of time explaining needlessly
sf: it's been out there already
... i thought rich had given us an explanation that avoided complexity
rs: you mean interactive content?
sf: rs: big concern is when you want to extend interactive controls
rs: and, we want to encourage html5 controls
... except for button and lin, say 'don't overwrite'
... not for roles
... other problem is headings aren't enforcing structure
... but things like footer have begin and end tags
cs: thought we were talking about anchor?
... i'm suggesting we explicitly say why we can overwrite on these roles, but not others
rs: don't want to say a specific list
... people should be able to overwrite widget
cs: i'm ok if we want to edit the change proposal that widgets can be overwritten
... else we should explain what we have
... i think our set is those things that are invokable
rs: status bar could be overwriteable?
db: what about an umbrella term like 'invocable'
rs: yes
... or what can be put in tab order
... grid cell is another
sf: seems odd
cs: that you could turn a link into a table cell
... think the right rule for <a (and similar) "invocable roles"
... are the roles categorized that way?
... would like us to make our recommendation based on a taxonomy subtree
<MichaelC> Taxonomy diagram
sf: isn't that 'anything that's child of input?'
cs: abstract roles?
sf: yes
... that's our block
rs: suggest 'single invocation input controls'
cs: not sure select makes sense, maybe select item
sf: we could delineate if a widget can contain other widgets
... so we essentially agree on proposal, minus text box
cs: yes, we only need to figure out how to categorize, so we can clearly explain
rs: would we eliminate combo box
sf: yes
cs: if we can categorize based on taxonomy branches, then check what's covered
rs: rdfa really codifies your design
cs: and, anything in the list can overwrite each other?
... there's a spec section that talkbs about what can be a command ...
... we need to look at menus and commands, sec 4.11
<richardschwerdtfe> having problems hearing cynthia
cs: things to resolve:
... forms and links; sounds like we agree
... menu command -- i will do
... document -- i think we have some disagreement
sf: yes -- good summary
cs: menu command probably about 3-4 weeks work
... probably 1 week work, but need to leeway to get it done as promissed
... we should look at some of the new ones, like calendar from apple that maps into their os
rs: but not for aria 1.0
sf: we need to keep perspective
cs: why not do these?
sf: adding aria roles too far into our tr process
<richardschwerdtfe> ACTION: Rich review additional HTML 5 input controls as to whether can be overriden by aria roles [recorded in http://www.w3.org/2010/05/04-aria-minutes#action01]
<scribe> ACTION: cynthia to menu and command mappings due to subteam on 20100519 [recorded in http://www.w3.org/2010/05/04-aria-minutes#action02]
<scribe> ACTION: rich to do new input types due 20100518 [recorded in http://www.w3.org/2010/05/04-aria-minutes#action03]
<scribe> ACTION: steve to html4 interactive elements (form and links?) due 20100518 [recorded in http://www.w3.org/2010/05/04-aria-minutes#action04]
