15:00:25 RRSAgent has joined #pf 15:00:25 logging to http://www.w3.org/2009/10/02-pf-irc 15:00:32 zakim, this will be pf 15:00:32 ok, janina; I see WAI_PFWG(HTML)11:00AM scheduled to start now 15:00:38 zakim, call janina 15:00:38 ok, janina; the call is being made 15:00:39 WAI_PFWG(HTML)11:00AM has now started 15:00:40 +Janina 15:00:58 rrsagent, make log public 15:01:07 zakim, who is on the phone? 15:01:07 On the phone I see Janina 15:01:36 -Janina 15:01:36 +Janina 15:01:36 +Cooper 15:01:59 +??P2 15:02:06 zakim, ??P2 is Joshue 15:02:07 +Joshue; got it 15:02:52 Stevef has joined #pf 15:03:06 +??P1 15:03:22 zakim, ??P1 is me 15:03:22 +Stevef; got it 15:04:11 Meeting: PF/HTML_Caucus telecon 15:04:11 Chair: Janina_Sajka 15:04:11 agenda: this 15:04:11 agenda+ identify scribe 15:04:11 agenda+ Recent Developments: Joint TF Status 15:04:12 agenda+ WCAG HTML5 Comments 15:04:14 agenda+ next and future meetings 15:04:16 agenda+ be done 15:04:53 ScribeNick: Joshue 15:04:58 zakim, mute me 15:04:58 Joshue should now be muted 15:05:17 TOPIC 15:05:38 JS: There is a request for consensus on our joint TF on a11y 15:06:08 JS: Members should reply. PF have discussed who our rep could be. The minutes seems unfinished 15:07:04 MC: Maciej said he had overlooked a couple of things - revised call for consensus. He says he has sent it. The new period is next Thurs. We are delayed by a week again. 15:07:07 JS: Ok 15:07:18 +Cynthia_Shelly 15:08:28 15:08:39 Call for HTMLWG volunteers for accessibility task force facilitator 15:08:39 http://lists.w3.org/Archives/Public/public-html/2009Sep/1202.html 15:08:42 JS: What do you sense from the meeting? 15:09:07 CS: No one said anything about that (last call). They are working on the process but the doc is not ready. 15:09:53 SF: They won't have it ready in four weeks. Hixie is closing down issues from the bug tracker, some things are moved to HTML issue tracker. We'll see. 15:10:15 JS: Anyone have a pointer to MS extensibility proposal? 15:10:49 SF: I'll find it and post it. 15:11:27 Distributed Extensibility Submission from Microsoft - 30 September 2009 15:11:35 html issue 41 Decentralized-extensibility http://www.w3.org/html/wg/tracker/issues/41 15:11:35 http://lists.w3.org/Archives/Public/public-html/2009Sep/att-1216/MicrosoftDistributedExtensibilitySubmission.htm 15:11:42 thanks Laura 15:12:00 JS: That will help 15:12:48 JS: We need to figure out facilitators etc we will work it out. I want to discuss that with Judy as she is very involved in this on behalf of the TF. 15:13:33 JS: I hope we are soon at the end of the HTML WG process, and we are looking at the time for the call. This or some other hour. 15:13:58 SF: Opera responded to Maciejs email - to say they support it 15:14:46 JS: Good 15:15:28 Opera's support: http://lists.w3.org/Archives/Public/public-html/2009Sep/1210.html 15:15:40 TOPIC: Moving the API call 15:16:03 CS: Steve would you be up for moving the call an hour earlier? 15:16:06 SF: Yes 15:16:46 zakim, unmute me 15:16:46 Joshue should no longer be muted 15:17:17 http://www.w3.org/mid/824e742c0908171632j77c6551fh66bfbe50a269b4f2@mail.gmail.com 15:18:43 scribe: janina 15:19:09 lg on 3.2.1 15:19:25 lg: do not use elements/attribs/values other than as intended 15:19:39 lg: does this forbid ARIA? Could it be misconstrued that way? 15:20:08 sf: current spec fairly clear about aria use 15:20:39 sf: lg's question should be considered vis a vis what the spec currently does say about ARIA 15:21:25 mc: think lg looked at this when there was no aria integration yet in html spec 15:21:44 mc: phps this is where strong vs weak semantics is described 15:22:00 sf: may i say i have concerns re strong vs weak? 15:22:05 cs: please elaborate 15:22:28 sf: e.g. form control, text box, would be strong and not overwritten 15:22:42 sf: but when part of popup would be different 15:22:49 cs: true, phps we need an inheritance model 15:23:29 sf:
  • elements not overwritten 15:23:45 cs: phps a limited number, checkbox, etc 15:24:13 sf: yes, a limited set should be mappable 15:24:52 sf: any element may have something like 'onclick' attached, 15:25:04 sf: if on heading, isn't it more important to know about the heading? 15:25:29 cs: button, checkbox, radio, select ... 15:26:12 cs: i've been reading interactive elements section; they already have this concept 15:26:23 cs: think apple wrote this section--feels like apple 15:26:35 cs: treat menu items as buttons 15:26:47 cs: already have the concept of dependence on context 15:27:45 sf: many of the new controls, because there's no description of how invoked, will depend on implementation 15:27:56 js: isn't that a bug? 15:28:03 cs: think so. 15:28:31 cs: think color picker will have this problem 15:29:46 sf: spec generally doesn't want to define ui -- whether a button should be a button, etc 15:30:42 +q 15:31:27 js: seems to me a basic principle for at is standardization under the hood and let browsers compete on look & feel and clever functionality 15:32:05 jo: seems the more edge cases come to the fore which are problematic will demonstrate the problems of this 15:32:56 cs: there two kinds of semantics here ... 15:32:59 -q 15:33:02 cs: not override api mapping 15:33:07 cs: and dom mapping 15:33:19 cs: i believe text level things should be overwritable 15:33:32 cs: that's not about building an ui 15:33:45 cs: bot form elements build ui, and overwriting could quickly create problems 15:33:57 cs: text box is so generic, may need overwrite often 15:34:22 cs: text processing not generally through api, so not problem for at 15:34:23 interesting point cynthia - again it depends on context of use. Maybe seperating document semantics from more input controls type things would help? 15:34:46 jo: separating doc semantics from input controls is the disconnect here 15:35:12 jo: does this help us understand what we need? 15:35:21 cs: yes, and html originally a doc lang 15:36:17 js: returning to lg's point ... consensus that no longer an issue as aria addressed sufficiently in html spec 15:37:13 lg: on h group 15:37:36 jo: some thoughts, just now looking at ... 15:37:44 http://dev.w3.org/html5/spec/semantics.html#sections 15:38:15 jo: huge number of new elements .. 15:38:17 4.4.7 The hgroup element 15:38:48 How will that work in practice with screen readers? Will child headings contained in the
    be ignored? In particular legacy UAs? Will legacy UAs just not parse the
    element and just parse the contained headings? 15:40:40 Here s asample 15:40:40
    15:40:40

    The reality dysfunction

    15:40:40

    Space is not the only void

    15:40:40
    15:40:41
    15:40:43

    Dr. Strangelove

    15:40:45

    Or: How I Learned to Stop Worrying and Love the Bomb

    15:40:47
    15:41:09 I don't know if this should be correct? 15:42:24 mc: seems to address title plus subtitle, but they're really just the title. 15:42:28 yes 15:42:31 mc: we also have this problem in w3.org 15:43:10 mc: this would be confusing to current at, but phps needs to be resolved 15:44:21 sf: doesn't h2 will be seen as separate heading? 15:44:28 Yes, Steve. The spec states "The point of using hgroup in these examples is to mask the h2 element (which acts as a secondary title) from the outline algorithm." 15:44:34 mc: this says don't put auxiliary content in the main h 15:45:22 jo: if at learns this is parsed differently, that's fine, but believe this may be problematic for at that doesn't support h group 15:45:52 jo: possibly not a big issue 15:46:17 mc: seems h group offers more clarity for sub headings 15:46:31 I guess that its use makes sense it AT can handle it correctly 15:47:06 consensus here is no problem with h group 15:47:11 sf: what was lg's concern? 15:47:19 mc: that we'll have to adjust headings guidance 15:47:44 mc: we'll have to adjust lots of guidance, because html5 is new, and there will be many 5 vs earlier issues 15:48:06 lg 3.1.2 elemnts in dom -- already a different section number 15:48:33 cs: part of command elements -- and they are labeled, have both text and icon 15:48:54 cs: possibly it's elsewhere, but in commands it's ok 15:51:02 mc: seems ok 15:51:13 cs: actually nice that every command can have label and icon 15:52:04 cs: if label attrib not required, we should ask for that 15:53:15 lg; next is 3.2.3.2 -- still valid as of date 15:53:34 lg: recommended uses of title esp subtrees 15:53:44 mc: we've always had this problem, is this an opportunity to fix/ 15:53:59 sf: issue? 15:54:04 I agree about trying to fix the @title. Or at least work out what we should be doing with it. 15:54:11 mc: that data important for at is recommended for title 15:54:19 sf: i've been on this, it's moved to tracker 15:54:46 sf: bug is alg for defining conforming images -- a non empty title is one you can have 15:55:00 sf: ok for at, since title becomes accessible name without alt 15:55:13 sf: visual users with keyboard can't access 15:55:21 sf: not displayed like alt 15:55:33 sf: suggest remove from alg or change advice for title 15:56:51 mc: suspect html4 had this listed for lack of better knowledge 15:56:57 cs: way it's done in command is correct 15:57:01 document conformance and device dependent display of title attribute content http://www.w3.org/html/wg/tracker/issues/80 15:57:50 lg: next 3.2.3.7 style attrib 15:58:18 lg: we should be sure this doesn't contradict wcag -- but may be it's ok 15:58:31 mc: more a wcag techniques question 15:59:08 mc: personally don't care for hidden text -- bad design and a maint problem 15:59:16 cs: also controversial 15:59:47 -Cynthia_Shelly 16:00:31 consensus this is not html, but wcag adjustment 16:02:28 sf: my concern is it may be hidden from at as well 16:02:39 mc: phps more reliance on css media types in wcag techniques 16:03:16 sf: does any at support media types? 16:03:34 mc: this is actually exploiting a bug 16:04:26 mc: better to have better style sheed and media types support 16:04:50 lg: 3.2.3.8 embedding custom nonvisible 16:05:01 lg: suggest we can ignore if we want -- may not be a11y 16:05:22 sf: this is about stopping an extention point 16:05:41 sf: can put js data binding, but not a back door extensibility 16:05:46 sf: that's why it's there 16:06:21 js: so better to have a defined extensibility mechanism 16:06:30 mc: specs define what's conforming, not what works 16:08:58 so ... title attribute and making label required are our two actions to escalate from lg's comments? 16:09:01 consensus 16:09:30 -Cooper 16:09:31 -Janina 16:09:32 -Joshue 16:09:38 zakim, bye 16:09:38 leaving. As of this point the attendees were Janina, Cooper, Joshue, Stevef, Cynthia_Shelly 16:09:38 Zakim has left #pf 16:09:45 rrsagent, make minutes 16:09:45 I have made the request to generate http://www.w3.org/2009/10/02-pf-minutes.html janina