- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Fri, 13 Jun 2008 11:31:28 -0400
- To: "public-html@w3.org WG" <public-html@w3.org>, "wai-xtech@w3.org WAI-XTECH" <wai-xtech@w3.org>
- Cc: Chris Wilson <Chris.Wilson@microsoft.com>, "Michael(tm) Smith" <mike@w3.org>, Michael Cooper <cooper@w3.org>, wai-liaison@w3.org
** teaser PFWG sent HTML WG a deliberated and consensed opinion that @alt should be reinstated as a required attribute in HTML5, for now (until, etc.). Discussions on this point have tended to go around the same circles without convergence. Provoking authors into stuffing garbate in @alt is bad. That is agreed on all sides. Being able to say "@alt is required" is simple and productive in accessibility training for authors. That should be agreed on all sides. But when these two things appear to conflict, how does W3C make a decision? Find something we can all live with. On the advice of the WAI CG, I'm under an action item to organize a consultative process to try to reduce the heat:light ratio in discussions on this issue, so we can get on with the business of developing an HTML5 that W3C Recommends, that is what people actually use, and that supports accessibility. I'm looking for a few people from different walks of the Web who would be willing to put some time into a search for objective, agreeable reference points for the HTML WG decision on how to support WCAG as regards images and text related to those images. ** background: There have been a number of threads dealing with "should @alt be a required attribute in the HTML5 specification" and related issues. There has been discomfort on various sides with the tendency of these threads to rehash the same arguments repeatedly without converging toward a consensus that all can live with. One of the process patterns that we often invoke in chairing W3C groups is that if people seem to be talking past one another in asynchronous communication; to up the interaction bandwidth, and bring up the issue in a real-time context, in a telecon or F2F meeting. On the advice of the WAI Coordination Group, I (acting as PFWG chair) propose to organize a telecon or telecons to explore these issues with an attempt to discover areas of agreement and clarify areas of disagreement. The HTML WG leadership has graciously agreed to join in organizing this ad-hoc process. ** macroscopic outline of the plan The general logical flow is that of a W3C workshop without the Face-to-Face element or lead-time constraints. This activity will develop information for action by the several Working Groups, not make decisions on their behalf. This message serves as a call for expressions of interest. Expressions of interest will take the form of a position paper. A position paper is in concept an up-to-two-print-page review of the issues with recommendations as to resolution. You are welcome to encourage notable contributors to the past threads to participate. I may do some of the same. Position papers should be "on the product" that is to say on the issues affecting the HTML5 specification and the WAI/HTML coordination process supporting the development of that specification. They should be sent to <wai-xtech@w3.org> with [alt workshop] at the beginning of their subject line. Positions will not be recognized for the purposes of participation unless the author permits their [re-]posting and archiving there. Note that "on the product" in this case may include process arrangements for how HTML5 manages accessibility- related decisions and coordinates with representatives of the WAI Domain. On the other hand, submissions of a purely procedural nature may fail to be recognized for purposes of participation. Comments on this process outline are also welcome. See in particular the issues mentioned in notes below. These may go to the XTECH list identified above or just to me with Cc: <wai-liaison@w3.org>. The panel of known provisional participant (see note about size and distribution goals) will then be polled to set date/time particulars. The baseline proposal is a series of up to three meetings separated by one week between meetings (also up for comment). I, or a convenor or convenors that I designate, will prepare an agenda from the submitted position papers. The chairs of the HTML and PFWG groups may inject additional subtopics if the see gaps in the agenda. Scribing rotation and editing duties for the meeting record will be negotiated with participants in advance of the meeting date/time. These special meetings will not make any formal Working Group consensus decisions. The special meeting(s) may suggest next steps that will be dealt with as determined by the Chairs of the affected groups for decision under the W3C Process. ** Notes (issues) * size and distribution goals It it is desired that the participation in the meeting not get so large that we can't use polling of the participants at times during the process. Anything over 12 - 15 participants is at risk of being too large. On the other hand, we would prefer if most people reading the meeting record will feel that their opinion was presented and was listened to in the conduct of the meeting. I may, as organizer, invite some groups of provisional participants (those who have volunteered to participate by submitting a position paper) who appear to represent a common perspective to self-down-select and propose a subteam of representatives for real time participation. * communications channels As these issues demonstrate, listserv communication can get old. Internet technology has evolved over the years. There are now blogs, Wikis, IM and podcasts. The experience in the HTML WG is that real-time meetings are lightly attended and the de-facto process seems largely unaffected by what happens there. What do we have to do to make the sessions I am proposing merit participation? The baseline proposal is that meeting time uses one voice teleconference channel and one IRC channel for logging. The agenda and the meeting report will be in accessible hypertext. The real-time and record communications will be visible to the public. But can we do better? Should we use a two-channel chat pattern? One for logging to the meeting record, and one permitting general chat? Should we use a blog or Wiki to gather the position papers, rather than a listserv? Do we have any hope of getting generally-agreeable summary or index to read-ahead materials, or should the organizers have to do this as an facilitator duty? Are there discussion spaces that are already set up with these issues in scope that we should use, rather than spawning ad-hoc resources just for this meeting? Should we plan for and set process patterns for asynchronous discussion between the sessions? Is it possible/positive/necessary that we provide readonly access to the meeting audio as it happens? To the meeting log in real time? Should we ask Participants to refrain from private conversations during the meeting times? Or are side-conversations a necessary evil and we need to make it clear that this may go on? Should we publish to WikiPedia rather than w3.org? The idea would be that WikiPedia has a mature capability in enforcing an objectivity ethic. ** notes (general) * template for the meeting report as an issue paper [strawman for reference]. A good outline for an issue paper breaks the information into these five sub-topics: 1. what squeaks -- perceived points of pain in the present situation 2. what works -- what in the present situation should be recognized as successful and constructive 3. blue sky -- in the best of all possible worlds, how would things work 4. baby steps -- what are low-risk incremental steps that would with confidence improve the situation 5. the plan -- what to do. Intermediate in risk and performance between 4. and 5. Naturally, that outline would serve well if used in a position paper. Position papers that are all about 'the plan' and not about 1. - 4. may be disqualified. * template for meeting process [strawman for reference] A common and likely meeting flow would be as follows. a. Information/stipulation -- what can be agreed w/o discussion review the read-ahead identify points that are unarguable or generally agreed in the position papers b. Outcome possibilities preview review what could result from the meeting. What forms can 'the plan' action proposals take? .. where do they go for action? c. Discussion -- group discussion of issues that have implications for b. and lack the broad support of what was already available in a. Record provisional decisions on the fly. d. Recap: Review/confirm resolutions (real-time, at end of meeting and non- real-time in minutes approval cycle) Review/expand the updated read-ahead basis (a plus b). (in minute approval). Each session may start and/or end with brief review and recap sessions where the meeting is not just starting or finally ending. The consideration of each topic may begin with a polling pass or two: each Participant asked to make an opening statement on the issue. Later phases could include queue- ordered turns to speak, the offering of proposed resolutions, and voting on proposed resolutions. [sample issue: should we take advantage of non- real-time means such as the W3C WBS system for polling out of real time?] * references Here are some links. You probably know more. A position paper without at least 3 - 9 useful links to related material may be disqualified. earlier PFWG finding: http://lists.w3.org/Archives/Public/public-html/ 2008Feb/0082.html HTML5 editor request: http://lists.w3.org/Archives/Public/wai-xtech/ 2008Apr/thread.html#msg30 LauraC request: http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/ thread.html#msg195 JimJ review: http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/ thread.html#msg177 AlG thoughts: http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/ 0367.html format should enforce universal access: http://lists.w3.org/Archives/ Public/wai-xtech/2008Apr/0411.html clear away nonsense, then decide: http://lists.w3.org/Archives/Public/ wai-xtech/2008Apr/0399.html SteveF action item: and so on: http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/ subject.html http://lists.w3.org/Archives/Public/wai-xtech/2008May/ subject.html
Received on Friday, 13 June 2008 15:44:19 UTC