要点

  • W3Cは9月8日のFixed Layout Accessibility Task Force会合と、その定例シリーズを中止と表示した。作業そのものは終わらず、Accessibility Task Forceで継続する。
  • 8月20日の議事録では、文書によってCommunity Group ReportとWorking Group Noteの可能性が分かれ、二つの会合が混乱を生んでいたと説明されている。
  • CG参加者はWG案件の議論に加われるが、その判断を行う資格はなく、タスクフォースの成果にはWGの承認が要るという境界も確認された。
  • Daniel Kadeは、各議題に担当グループ、決定参加資格、対象文書、承認手順、最終処理を示す「権限タグ」を付けるよう提案する。

カレンダーから消えても、仕事は消えない

9月8日のイベント情報には、会合の中止だけでなくシリーズ全体の取り消しが記されている。その下の説明が重要だ。FXLタスクフォースはAccessibility Task Forceに再合流し、新しい考えのインキュベーションと文書の保守を続ける。従来のメンバーには別の会合の招待が届くという。

これは固定レイアウトEPUBのアクセシビリティを断念する告知ではない。二重になっていた作業場所を一つにする運用変更である。限られた専門家が二つの予定、二つの議題、二つの記録を追う負担は小さくない。議論を一本化すれば、支援技術、読み順、画像説明、リフローといった論点を連続して扱いやすくなる。

一方、イベント情報はFXLをPublishing Community GroupとPublishing Maintenance Working Groupの共同作業と説明している。「共同」は専門知識の接続を意味するが、二つの団体の制度上の身分まで同一にする言葉ではない。

発言できる範囲と決定できる範囲

8月20日の議事録では、会合統合の理由が率直に語られた。一部の文書はCG Reportであり、別の文書はWG Noteになり得るため、二つの会合が混乱を招いていた。参加者は、CGのメンバーがWGの問題を議論することはできるが、WGの問題について決定権を持つわけではないと確認した。タスクフォースの成果もWGによる承認が必要である。

そこで採択されたのは、PMWGとPublishing CGのアクセシビリティ・タスクフォース会合を今後共同開催するという運用上の決議だった。参加資格や文書制度を統合する決議ではない。

議事録の「vote」という言葉だけから、W3Cの判断をすべて多数決と理解するのも正しくない。W3C Processは合意形成を原則とし、実質問題の投票は、技術的対話と妥協で行き詰まりを解けない場合の手段としている。判断に参加できる集合は、原則としてそのグループの参加者である。合同会合の議長が区別すべきなのは、誰が話してよいかではなく、誰の支持や反対がWGとしての合意判断を構成するかだ。

PMWGの現行憲章は、会議中の結論をさらに限定する。電話会議や対面会合での決議は暫定扱いとなり、5～10営業日のCall for Consensusに付される。不参加者や所属組織が非同期に検討でき、異議がなければWGの決議として確定する。

この二段階は、開かれた知見を排除する仕組みではない。CGから来た専門家は問題を発見し、解決案を磨ける。WGはその貢献を受け取ったうえで、憲章に基づく責任を引き受ける。技術的な影響力と制度上の決定資格は、同時に尊重できる。

文書の行き先が権限を変える

Publishing Community Groupは自らをインキュベーションの場と位置付ける。公開リポジトリによれば、W3C会員でなくても参加でき、出版技術の提案、文書化、試作に関われる。アクセシビリティと固定レイアウトの各タスクフォースも掲載されている。

PMWGは承認済み憲章の下で、出版分野のRecommendationとNoteを保守し、インキュベートされた機能を取り込み、固定レイアウトが抱えるアクセシビリティ課題に取り組む。憲章は、保守対象のWorking Group NoteとしてEPUB Fixed Layout Accessibilityを明記している。現在のタスクフォース一覧には、独立したFXL名ではなく、包括的なPublishing Accessibility Task Forceが載っている。

Fixed Layout Challenges and Best PracticesはEPUB Accessibility 1.1を補う指針であり、新たなアクセシビリティ標準ではないと明示する。さらに別のFixed Layout Techniquesを参照する。8月の議事録は後者の編集担当を決め、支援技術で利用可能にする課題とリフロー可能にする課題を分けている。

同じ論点でも、CGでの試作、タスクフォースの勧告、WGが保守するNote、Recommendationに関わる変更では状態が異なる。リポジトリへの反映は編集上の事実であり、それだけでWG承認を証明しない。逆に、初期段階の成果がCG Reportであることは、その技術的価値が低いという意味でもない。

議題ごとに「権限タグ」を置く

必要なのは会議を再び分けることではなく、議論の入口で制度上のレーンを表示することだ。

権限タグには、まずCGインキュベーション、WG保守、WG Note候補、Recommendation関連のどれかを記す。次に、その判断に参加できるグループと、議論のみ参加する人を区別する。対象のissue、リポジトリ、文書の版を直接示し、予想される成果を「探索的見解」「編集作業」「タスクフォース勧告」「WG暫定決議」「確定したWG決定」のように表す。

WGの承認やCfCが残っているなら未完了と表示し、レーンをまたぐ場合は受け渡した版と受領主体を議事録に残す。最後に、採用、延期、却下、統合、公開のどれに至ったかを結び付ける。

確認した資料には、資格のない人がWGの判断を行った証拠も、会合統合が規則違反だという証拠もない。この提案は違反への制裁ではなく、共同作業が成功するための予防的な来歴管理である。

情報源