[html4all] FW: [CfP] process proposal for a special meeting or meetings for fact-finding on issues related to @alt in HTML5

[John Foliot]

*** Standard Top Post apology ***

Interesting, very interesting.  While I will spend some time this weekend
putting together my own personal ideas/proposal, methinks my history of
applying large amounts of heat may come back to haunt me... (although I also
hope that my history of documenting my points with references will hold me
in good stead)

I hope that all of the html4all-ers submit an application so that we can
maximize our representation as best possible... Knowing full well that Al
knows who we all are.  Here is hoping that this process resolves to real,
positive outcomes - I for one have always kept the faith.

JF


Al Gilman wrote:
> ** 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 at 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 at 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