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

** 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