See also:
Roland: I'm not here the 26th
Steven: I'm away for December
Roland: Call OK for next week
<oedipus> GJR: no problem with call on december 19
Roland: 19th OK?
... Ok we assume the 19th is OK
... no call on the 26th
<oedipus> boxing day the only skipped date?
Roland: we resume on the 2nd?
... so we miss just one week, the 26th of December
Roland: I will do agendas for this month
Steven: I will be around in case of need (for instance transition calls)
Roland: We produced a new draft of CURIEs last
week
... and we have a request outstanding for FPWD of Access
Roland: And ITS review?
Shane: We are happy with it
<scribe> ACTION: Steven to send ITS review (=thankyou, it's fine) [recorded in http://www.w3.org/2007/11/28-xhtml-minutes.html#action01]
Roland: Yam, are you able to report on this now?
Yam: At least my colleague is testing inputmode, so it is on the way
Roland: When might it be done?
Yam: Next week I think
Steven: That's good news
Yam: I think we are on schedule with the
implementation
... the team spotted two errors, and are fixing that
... all three test cases are tested in our technical team
<oedipus> GJR: RDFa versus Role to be discussed at today's telecon
Roland: There was going to be a followup meeting on this
Steven: Rich, what is your take on the current opinions in the PF about the use of role for title?
Rich: Well, clearly title isn't a unique
thing
... since it may apply to many sections
... it hasn't been proven to me why you need a title element for sections and
the whole document
... maybe because of iframe
Steven: So we have a way to do that already,
the property attribute equal to dc:title
... <h1 property="dc:title">My life</h1>
Rich: We also have labelledby
<ShaneM> Note that the RDFa spec does not say that something with a property of dc:title is the same as / overrides the title element.
<oedipus> GJR: labelledby for today, RDFa for next round
Steven: I agree that role is the wrong way to
do it
... but the use case is still covered
Roland: So the short term goal is role, and the long term goal is RDFa
<oedipus> GJR: short term goal is "labelledby" (ARIA syntax); long term goal is to use RDFa and explore means of communicating RDFa to Assistive Technologies
Steven: You can also say <h2
about="#section3" property="dc:title">Future tasks</h2>
... which says what the title is for some subsection
<oedipus> original example: <h1>Record #35793: <span property="dc:title">Title of Document or Sub-Document or portion of document</span></h1>
<oedipus> thread starts here: http://lists.w3.org/Archives/Member/w3c-wai-pf/2007OctDec/0191.html
Roland: If we are happy, let's move on
<Rich> short term solution: <div role="secondary" aria-labelledby="x26">
<Rich> <div role="header" id="x26">Last week's News Stories</div>
<Rich> </div>
<Rich> </div>
<oedipus> aria- is what has been implemented so far -- Jon Gunderson still using aria: in some examples
<oedipus> aria- being pushed by implementors/developers -- not a patient lot -- don't care about standardization, but product delivery
<Rich> aria:aria-labelledby
<oedipus> +1 to Tina's observation about using DIV to substitute for semantically meaningful markup (theory, i suppose, is that ARIA makes it semantically meaningful, but that is a strawman, in my opinion
<oedipus> extensibility for all but those who don't want it (HTML5 devs) -- SVG integration into HTML5 may be made redundant if CANVAS carries
Steven: I don't think that the aria attributes
should be chameleon
... you want them to work everywhere, without changing the languages; and I
think that the XML languages should use aria:labelledby, and let HTML5 us the
hyphen for its namespace separator if it is so allergic to colons.
Shane: Well, why is role chameleon then?
Roland: So that language designers can decide for themselves which they use.
Roland: This is ongoing
... I still have to do the response to them
Rich: We need a description of the handler
<oedipus> DanC keeps reiterating that "NOTHING" has been decided; there has been, however a "formal survey" on immediate role graphics and CANVAS
(which will become the first decision)
<oedipus> right
Rich: And <purpose> was there for that
<oedipus> Steven: handler specs, purpose element -- strictly speaking with so many types of handlers, good to have solution that addresses that as well; idea of purpose description is very good one -- if can find way to do it; Mark suggested role, i can envision using RDFa to pass description of handler (metadata in a way)
<oedipus> RS: place to put text, associate text with handler via RDFa -- mechanism to put actual text in handler?
<oedipus> Rich: liked Roland's proposal -- similar to solution for XForms
<oedipus> Roland: why not provide information - this is a label, this is what it does, hint can be obtained on user request (tell me more about this)
<oedipus> Steven: label in relation to handler?
<oedipus> Rich: don't see how label fits for handler
<oedipus> Roland: if here is a trigger and this is the handler for it, could get label from handler
<oedipus> Steven: have to think about that
<oedipus> Roland: have as many as want in UI - don't have to write twice; and can get supporting materials
<oedipus> Rich: XML Events -- how to do?
<oedipus> Roland: can still have element as child of handler
<Roland> http://lists.w3.org/Archives/Public/www-html-editor/2007OctDec/0027.html
<Roland> <action id="doThat">
<Roland> <label>Do That</label>
<Roland> <hint>performing this action will delight you.</hint>.
<Roland> <script type="application/x-javascript">
<Roland> doactivate(event);
<Roland> </script>
<Roland> </action>
Shane: Any of this is fine
... only as long as we don't overengineer it
Roland: No one says we have to do all three
... but in XForms we do
... a label for the UI layer
Shane: What is the UA requirement for a label?
Roland: That it is presented to the user
Shane: If I have a span
... and associate an access key with it
... and a handler that is invoked by that key
... if the handler has a label, how does that get manifested?
Roland: I don't think it does
Shane: OK, good
Rich: So do we need all 3 in XML Events2?
Roland: Well, I was suggesting synergy with
stuff we have already
... you don't HAVE to use them
Rich: I see, fine
... I see a way of mapping it to the accessibility API
<oedipus> GJR: can use "prolog" in ARIA concept to provide richer, fuller human-understandable information about specifics of choice (if choice available)
Gregory: See my comment about 'prolog' in
aria
... above
<ShaneM> So I think what I need to do is steal the label, hint, and help elements from XForms and put them into XML Events 2?
Rich: If we had a declarative model, like XForms data model, we could do this all a lot easier
Roland: So I'm saying XForms, and therefore XHTML2 has this already, so why not reuse it rather than reinventing stuff
Shane: Do you mean add it to handlers?
Roland: Yes
<oedipus> +1 add to handlers and reuse in XForms
<alessio> +1
Rich: So we'll be using XML Events2 in XHTML2?
Steven: That is the plan, but there is an
overlap with XForms,which still uses XML Events 1
... and we will use XForms 1.1
Rich: XHTML2 is not fully supported in the browser, and there is HTML, we are looking at a dual timeline in the WAI area
Shane: I would like to go to last call in 2
weeks on CURIEs
... just to push the fight
... we can deal with the comments
Steven: Length?
Roland: Till late January
... for the ftf
Shane: 6 or 7 weeks
Steven: Any objections?
Shane: I will prepare a draft for next week's call
Steven: Will put on the agenda
<scribe> ACTION: Roland put last call of CURIES on next week's agenda [recorded in http://www.w3.org/2007/11/28-xhtml-minutes.html#action02]
<scribe> ACTION: Shane prepare a new draft of CURIES for next week [recorded in http://www.w3.org/2007/11/28-xhtml-minutes.html#action03]