14:56:10 RRSAgent has joined #html-a11y
14:56:10 logging to http://www.w3.org/2012/09/20-html-a11y-irc
14:56:12 RRSAgent, make logs world
14:56:14 Zakim, this will be 2119
14:56:14 ok, trackbot; I see WAI_PFWG(HTML TF)10:00AM scheduled to start 56 minutes ago
14:56:15 Meeting: HTML Accessibility Task Force Teleconference
14:56:15 Date: 20 September 2012
14:56:23 zakim, who's here?
14:56:23 WAI_PFWG(HTML TF)10:00AM has not yet started, janina
14:56:24 On IRC I see RRSAgent, janina, trackbot, Zakim, Judy, davidb, MichaelC, [tm]
14:56:36 hober has joined #html-a11y
14:56:55 WAI_PFWG(HTML TF)10:00AM has now started
14:57:02 +??P19
14:57:07 +Cooper
14:57:12 zakim, ??P19 is Janina
14:57:12 +Janina; got it
14:58:16 +Judy
14:59:09 +[Apple]
14:59:13 Zakim, Apple is me
14:59:13 +hober; got it
15:00:01 rubys has joined #html-a11y
15:00:38 Meeting: HTML-A11Y Task Force Teleconference
15:00:38 Chair: Janina_Sajka
15:00:38 agenda+ Getting HTML5 to Recommendation in 2014 http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0367.html
15:00:38 zakim, what is the passcode?
15:00:39 the conference code is 2119 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), rubys
15:00:41 agenda+ Open Issues Status and Next Steps
15:00:43 agenda+ The Task Force at the TPAC
15:00:46 agenda+ Other Business
15:00:48 agenda+ Actions Review http://www.w3.org/WAI/PF/HTML/track/actions/open
15:00:51 agenda+ Identify Scribe for the next TF teleconference http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List
15:00:54 agenda+ be done
15:01:10 +Sam
15:01:19 +John_Foliot
15:03:03 JF has joined #html-a11y
15:03:07 zakim, who is on the call?
15:03:07 On the phone I see Janina, Cooper, Judy, hober, Sam, John_Foliot
15:03:21 +??P2
15:03:36 scribe: MichaelC
15:03:43 zakim, ??P2 is Steve_Faulkner
15:03:43 +Steve_Faulkner; got it
15:03:48 agenda?
15:04:02 Stevef has joined #html-a11y
15:05:20 zakim, next item
15:05:20 agendum 1. "Getting HTML5 to Recommendation in 2014 http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0367.html" taken up [from janina]
15:05:27 js: Proposal from HTML chairs
15:05:35 also signed off by me, Judy, Philippe
15:06:06 goal to get HTML5 to Rec in 2014
15:06:10 +Cynthia_Shelly
15:06:12 plh has joined #html-a11y
15:06:13 it's only a proposal right now
15:06:16 +Plh
15:06:16 we should discuss
15:06:21 but not expect to come to conclusions
15:06:55 q+
15:07:17 plan could change based on discussion here, in HTML WG, and in PFWG
15:07:20 ack j
15:07:24 q+
15:07:26 http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0367.html
15:07:26 http://www.w3.org/QA/2012/09/getting_html5_to_recommendatio.html
15:07:26 http://lists.w3.org/Archives/Public/public-html/2012Sep/0243.html
15:07:26 http://dev.w3.org/html5/decision-policy/html5-2014-plan.html
15:07:48 jb: first link is announcement of plan from Paul
15:07:53 second is blog by Philippe
15:08:13 third is another announcement of plan
15:08:25 fourth is the plan proposal itself
15:08:37 Philippe and I signed off as Domain leads, not as W3C management representatives
15:08:59 there's a lot of detail including re accessibility
15:09:07 have seem some good requests for clarification on the lists
15:09:21 would like to have a HTML co-chair go over plan
15:09:29 and then go into accessibility implications
15:09:53 one error: http://lists.w3.org/Archives/Public/public-html/2012Sep/0269.html
15:10:02 plh: we have found one error at least
15:10:08 so we know the plan will change
15:10:32 sr: nothing to add to PLH
15:10:49 not sure going through plan point by point will help, though can
15:10:54 paulc has joined #html-a11y
15:10:55 jb: some high level points
15:11:02 one is emphasis on modularity
15:11:13 joining soon
15:11:19 q+
15:11:38 features could start as extensions, and either move to standalone spec with separate timeline, or get integrated into core spec
15:12:20 one concern is different conformance mode for HTML5 spec, more of a smorgasbord of what implementers may choose
15:12:59 so extension specs could be preferred sometimes
15:13:15 the plan also gives a mandate to this task force to work on extension specs
15:13:31 seeking careful review and consideration of whether this would work into the future
15:13:54 js: there's been some question about how TF decisions are weighed in HTML decision process
15:14:07 this plan shifts authority to TF to develop specs for features of key interest
15:14:10 ack plh
15:14:47 ack s
15:15:34 sf: if an extension spec provides a feature not in HTML5, it seems to work
15:15:38 s/one concern is different conformance mode/one aspect of background context is the existing different conformance model/
15:15:47 q+
15:15:50 if an extension changes or removes an HTML5 feature, it gets messy
15:16:12 Background on Steve's point: http://lists.w3.org/Archives/Public/public-html/2012Sep/0282.html
15:16:19 s/so extension specs could be preferred sometimes/so extension specs could be considered peer-level specifications with the core/
15:16:21 Q+
15:16:30 I tried today creating an extension spec to remove and ended up needing to copy the whole spec with references removed
15:16:58 Background on Steve's second point: http://lists.w3.org/Archives/Public/public-html/2012Sep/0284.html
15:17:05 also was caught by surprise by recommendation to move text alternative document to the TF
15:17:12 since I'm the editor
15:17:21 ack j
15:17:25 q+ JF
15:17:27 ack judy
15:18:01 jb: one part of the plan is "willful violations"
15:18:20 q+
15:18:22 which extension specs can do
15:18:48 think the general intent was not to remove existing accessibility support
15:18:59 but to provide a smoother path to development of features that hadn't yet made it in
15:19:06 including different timeline
15:19:08 +[Microsoft]
15:19:34 zakim, [Microsoft] has paulc
15:19:34 +paulc; got it
15:19:50 there is still effort to remove text alternative section in spec
15:19:52 ack ru
15:20:23 sr: wouldn't want an extension spec to be an entire replacement of spec
15:20:35 would prefer to come up with a core spec that can be cleanly extended
15:20:41 should work together on how to do that
15:21:26 q?
15:21:52 sf: keeping would be controversial and potential accessibility impact
15:22:04 would prefer to see a "clean" core spec and all these features as extension specs
15:22:18 s/not as W3C management representatives/Philippe's role wasn't specific as W3C management representatives, but rather he and I are counterpart domain leads; we are also both part of W3C management./
15:22:29 sr: what do you think should become of the text alternative doc?
15:22:33 sf: prefer to leave it where it is
15:22:52 if it's an extension spec making a willful violation of HTML, it's less strong
15:23:08 js: what if the conflict with what's in HTML now gets resolved?
15:23:12 sf: then we could re-assess
15:23:21 right now everything in flux
15:23:41 s/and then go into accessibility implications/and then Janina or I may go into accessibility implications in more detail/
15:23:51 q?
15:24:28 q+
15:24:31 q+
15:24:35 js: seems to me Steve's concern with is similar to others' concern about separating ARIA integration into an extension spec
15:25:03 process-wise, nothing's fait accompli, so now is opportunity to ask about the fate of the text alternatives doc
15:25:09 ack paul
15:25:33 pc: text alternatives document has a Formal Objection against it that it can't be normative because it contradicts HTML5
15:25:42 doing it as an extension spec flattens that problem
15:25:58 sf: it already presents itself as an extension
15:26:00 q?
15:26:07 ack ju
15:26:37 jb: one question I've heard in background is implication on forking
15:27:06 hearing that this plan more clearly provides a way to address the FO on the text alternative doc
15:27:17 paulc: "This specification is an extension to the HTML5 specification [HTML5]. All normative content in the HTML5 specification, unless specifically overridden by this specification, is intended to be the basis for this specification." http://dev.w3.org/html5/alt-techniques/
15:27:19 q?
15:27:31 but also have heard that if various extensions taken at different times, the accessibility features could fragment
15:27:38 q+
15:27:40 not sure if it's a problem, but have had questions from many places on that
15:28:02 how do we keep extensions from becoming fragments?
15:28:11 ack p
15:28:22 s/many places/some places/
15:28:45 pc: speaking as Microsoft representative - we don't look at where a feature is documented, core or extension
15:29:01 i.e., RDFa vs microdata, chose to implement both
15:29:20 q?
15:29:29 should address perception that where something is documented might affect implementation
15:29:58 implementers implement features that the market demands etc.
15:30:14 +1 to "we can't resolve everything today"
15:30:29 js: note we can't resolve everything today, so we're just discussing issues
15:30:34 ack jf
15:30:36 Implementers choose features to implement that are a) well specified and b) meet market demand
15:31:00 jf: concerns about optics
15:31:19 e.g., FO that text alt document contradicts HTML
15:31:22 In my view implementers don't worry about "where" something is specified ie in a core spec or an extensions spec
15:31:24 formal objection that jf and others have referenced: http://lists.w3.org/Archives/Public/www-archive/2011May/0051.html
15:31:28 suggest we could lead to a "HTML+A11Y" variant
15:31:34 which marginalizes accessibility
15:31:55 q+
15:32:02 q+
15:32:05 in this particular example, there are conflicting viewpoints about how to handle text alternatives to best meet the needs of the customer
15:32:12 q?
15:32:17 ack p
15:32:36 pc: hear this as a concern about the "end game", is that accurate?
15:32:38 jf: partly
15:33:07 I hear there will be willful violations
15:33:26 what will ordinary implementers make of this?
15:33:35 which version will they choose/
15:33:43 s|choose/|choose|
15:34:07 the FO puts weight on a direction
15:34:13 pc: I'm concerned about the end game
15:34:28 want to get past Last Call and find path to end game that makes everyone happy
15:34:30 Q+
15:34:43 we've been discussing issues with alt and suggestions to address
15:35:05 note recent change of editors
15:35:20 and work with the new team by opening bugs etc.
15:35:40 the situation of "opposing sides casting missiles at each other" doesn't work
15:35:52 I agree with some of the concerns
15:36:02 the plan gets us to CR, takes some of the pressure and tension off
15:36:12 and gives opportunity to merge things back in later
15:36:18 ack ju
15:36:37 q?
15:36:50 jb: potential for marginalization of accessibility one of the greatest risks we saw going into this plan
15:37:07 importance of having solutions available in HTML 5
15:37:16 makes it worth proceeding along this route
15:37:20 depends on a lot of things working well
15:37:42 there have been questions about reintegration path
15:37:59 procedure is documented in the plan, and there are conditions
15:38:17 the features must meet the CR exit criteria
15:38:21 q+
15:38:27 exit criteria: http://lists.w3.org/Archives/Public/public-html/2012Sep/0215.html
15:38:35 note the "Public Permissive CR Exit Criteria" is what's meant by that
15:38:45 ^
15:39:13 q?
15:39:27 look at that, and how it might apply to extension specs, particularly ones hoped for reintegration
15:40:03 there's also questions about the consensus in the HTML spec
15:40:11 need broader consensus
15:40:28
15:40:47 ack j
15:40:59 jf: going back to optics
15:41:04 ack SteveF
15:41:13 q+
15:41:14 feel an important point judy made might have been missed: proposals may need clarifications or may need adjustment to gain wider consensus
15:41:19 I'm trying to keep an open mind
15:41:30 but prospect of HTML+A11Y variant is a non-starter for me
15:41:39 not just for impact on implementations
15:41:45 but also on authors
15:41:57 many of whom have particular requirements
15:42:15 forces them to make a choice between forks
15:42:28 q+
15:42:30 how do we avoid the perception of two standards (whether it's real or not)?
15:42:38 pc: ack p
15:42:40 ack p
15:42:46 s/pc: ack p//
15:43:13 pc: did moving RDFa to a separate spec constitute a fork?
15:43:23 in that case there was even a competitive spec, microdata
15:43:27 but there's huge adoption of both
15:43:37 understand the perception issue, but don't think the reality need lead there
15:43:53 Q+
15:43:59 have many similar examples where forking feature out didn't inhibit adoption
15:44:01 ack ju
15:44:07 jb: don't want to downplay concern about optics
15:44:23 have seen that over my years in the field
15:45:14 q?
15:45:15 there could be a tendency to grab core HTML 5 and ignore extensions
15:45:21 looking at that from a marketing perspective
15:45:38 for the plan, want to see if it's sufficiently addressed in what's here
15:45:52 in some adoption contexts, could be very important to promote as a set
15:46:03 q+ to say getting in the spec doesn't cause features to be adopted; as paul stated, what causes features to be adopted in a clear specification that addresses a clear user need
15:46:09 there are good things in the plan to try to address all this
15:46:16 welcome input to strengthen that
15:46:50 js: underlying concern isn't technological
15:46:55 it's "to ghetto or not to ghetto"
15:47:14 not just accessibility, is a common sociological concern for marginalized communities
15:47:20 q+
15:47:49 today, some of the historically severe marginalization of people with disabilities is hard to understand but it's part of our context
15:48:31 note the proposal cuts both ways
15:48:40 do recognize need to balance optics
15:48:41 ack rubys
15:48:41 rubys, you wanted to say getting in the spec doesn't cause features to be adopted; as paul stated, what causes features to be adopted in a clear specification that addresses a
15:48:44 ... clear user need
15:49:10 sr: reiterate that getting feature in spec doesn't get it adopted, JF even on record saying that
15:49:14