古典的なエディター機能を複製するすべてのブロックがグーテンベルクでアクセス可能であることを知っているのは本当に素晴らしいことです。

ここで行うべき正しいことは、独立したアクセシビリティ監査を受けることです。 WordPressには、アクセシビリティガイドラインをコアで満たすというポリシーが定められており、ユーザーにはそれらのガイドラインを満たす責任があります。 これが事実であるかどうかを示すことができるのは、徹底的なアクセシビリティ監査だけです。 アクセシビリティチームは多くの問題にフラグを立てており、そのうちのいくつかは処理されており、他は処理されていません。 少なくとも、これらに対処する必要があります。

WordPressは、発行者、データベース、および訪問者の間のインターフェイスです。 パブリッシャーがインターフェースの入力または操作をどの程度正確に選択するかは、そのユーザー次第です。 WordPressの仕事は、そのユーザーが選択した入力モダリティに関係なく、インターフェイスにアクセスできるようにすることです。 これは新しいことでも物議を醸すものでもありません。それはウェブが立つ基盤です。

@ mor10に同意します。 Automatticとコアチームがプロジェクトにどのように投資していて、まだ問題が発生しているのかを考えると、今後の唯一の真の有効な道は、独立した客観的な監査を受けることです。

WordPressには、コアでアクセシビリティガイドラインを満たすというポリシーがあります

はい、正確に。 @aferciaや@rianrietveldなどのより大きなw.orgプロジェクトのリードから、ここでの作業に自信を持ってもらいたいと思います。

要するに、グーテンベルクはアクセス可能だと思いますが、プロジェクトで開かれている

これが起こることを願っています！

私は、外部の独立したアクセシビリティ監査を完全にサポートします。

おっしゃるように、ユーザーテスト、特に開発が進むにつれて再テストすることに関する資料や情報の不足に関連していると私が思ういくつかの認識の問題があります。 ユーザーの結果を追跡する代わりに、バグやリグレッションを追跡しているように感じます。

ここでのあなたの誠実さに感謝し、外部/独立監査が価値があることに同意します。 しかし、これが、マウスとキーボードを使用していない可能性のあるユーザーに「より良い」エクスペリエンスを提供するのではなく、技術的な観点から（つまり、WCAG 2.x / AAのチェックボックスをオンにして）アクセシビリティにさかのぼって対処しているのではないかと心配しています。 アクセシビリティだけの場合、現在の経験（またはさらに良いことに、他の同様の製品）に関連するデータのないグーテンベルクの経験の定性的および定量的研究は、公正な話をしないかもしれません。

この情報に関する透明性は、アクセシビリティの観点とより大規模なグーテンベルクの展開の両方の観点から、コミュニティのサポートによって長くなり、多くの摩擦を和らげると思います。

他の人が外部監査に賛成していると聞いても驚くことではありません。 👍私もそれが大好きだと言うことができます。来週中にそれを促進する方法を検討します。

プロジェクトのアクセシビリティ監査を実行する時間を優先できる、WordPressに関係するアクセシビリティ専門機関/企業はありますか（おそらく4.0の時点で、これは大きなリリースです）？ グーテンベルクがクラシックエディターとどのように重なるかについてのベースライン感覚を確立することは便利だと思います。

問題があると確信しています（前述のように、100を超えるアクセシビリティの問題があります）が、グーテンベルクのアクセシビリティのマクロビューを取得しようとしています。 「バグ」というラベルの付いた問題も100をはるかに超えていることを指摘しておく必要がありますが、これは、バグが小さすぎることはないと考えているおかげです。 私たちはすべてをログに記録しようとしますが、これは100のアクセシビリティブロックではなく、100のアクセシビリティの問題を意味することを覚えておいてください。 アクセシビリティブロッカー（現時点）は、この問題が含まれているマージマイルストーンに含まれています。

監査を支援するために声を加えてくれた人々に感謝します。 テストしてMVPとしてのユーザーの作業を確認したいフローのリストを提供します。その場合、ここに投稿しますが、まだ完全には定式化されていません。

外部監査は素晴らしいアイデアです。 この監査を実施する資格のある企業の採用に財政的に貢献できれば幸いです。

私はまた、特にこの規模と重要性のあるもののために、財政的に貢献したいと思います。

私はまた、コミュニティからの資金調達を支援する方法を率先して進んでいきます。

私はこの考えが好きです。 ソフトウェアでWCAGコンプライアンスを必要とする企業にとって、監査は懸念を鎮めるのに大いに役立つ可能性があります。 監査からVPATを生成することは、契約プロセスの一部としてそれを必要とする組織への取り込みにも役立つ可能性があります。 関連情報については、テクノロジーベンダー契約へのアクセシビリティの構築を参照してください。

また、外部の独立したアクセシビリティ監査もサポートしています。 私は私の日常の仕事の優れたa11yリソースをチェックして、彼らが何を推奨しているかを確認します。 :)

それはとても親切です！ しかし、私たちはコミュニティからの財政的貢献を求めていません。 いくつかのアクセシビリティ監査人に連絡して、グーテンベルクでいくつかの監査を実行させる方法について見ていきます。

どのようなコストとタイムラインが関係しているかはわかりますが、5.0で機能するタイムラインで手頃な価格のものを入手できれば、Automatticにコストをカバーさせることができるはずです。 😊

以前のコメントを投稿したとき、Automatticから提供できる経済的サポートに少し自信がなく、コミュニティからの期待について少し不明確でした。申し訳ありません。 コメントを更新し、探していなかったものを明確にしました。 今、私は監査の手配について見るつもりです、少なくとも見積もりをまとめるのにおそらく数日かかるでしょう！ 詳細がわかり次第、報告します😊

私はこれがこれを述べる場所ではないかもしれないことを知っています、しかし私の会社はアクセシビリティ監査をします。 もっと知りたい場合はお知らせください。 最近はそれほど活発ではありませんが、私はしばらくの間WordPressに関与しており、グーテンベルクやWPの他の部分にアクセシビリティのアイデアを提供してきました。 十分に独立していない場合は、WordPressを使用したことがない信頼できるパートナーと協力します。

@tofumatt提案依頼書は、監査が何を求めているかを正確に述べ、サービスプロバイダーに彼らがどのように進むかについての一般的な概要を提供する機会を与える良い方法だと思います。 Automatticでこのタイプのプロセスの前例はありますか？

こんにちは、私はノースカロライナ州立大学のITアクセシビリティコーディネーターです。 キャンパスのウェブサイトにはWordPressを使用しており、州の機関として1973年リハビリテーション法の第508条に従う必要があります。このため、WordPressなどのオーサリングツールは障害を持つ個人が利用できる必要があります。

WordPressのブログを使用し、組織の部門に代わってWordPressサイトを編集する学生、教職員、スタッフなど、WordPressのユーザーは多種多様です。 言うまでもなく、WordPressはこれらの個人がアクセスできる必要があります。

高等教育機関として、私たちは新しいプログラムやテクノロジーを常に最新の状態に保ちたいと考えています。 グーテンベルクを進歩させて使用することができなかったり、障害のある人が古典的なエディターの使用に制限され、健常者がグーテンベルクを使用できる「分離すれど」の状況を実行できないことは、私たちにとって有害で​​す。

それは聞いてとても素晴らしいです👍

全くもって同じ意見です！ もちろん、WordPress 5.0がリリースされる前に修正できないことがわかった（またはおそらく知っている）アクセシビリティの問題があるかもしれないという明確な期待を設定したいと思います。

グーテンベルク（または外部プラグイン）が改善されている間、限られた時間だけクラシックエディタープラグインを使用したい/必要とするサイトはたくさんあります。 ソフトウェアを改善している間、Classicプラグインを数週間/数か月間必要とする、他の多くの問題とともに、アクセシビリティの問題に遭遇するユーザーがおそらくいるでしょう。

WordPressエディターの未来が素晴らしく、誰もがアクセスできるようにしたいと思っています。 なんらかの理由で、最初はひび割れに陥ったユーザーの皆様には、あらかじめお詫び申し上げます。 しかし、それがすぐに起こらなくても、グーテンベルクとワードプレスを彼らにとっても素晴らしいものにするために努力することを知っ

監査について

やあみんな！ 私はまだリリースリードになるのは少し新しいです。私は10年近く、 @ mozillaプロジェクトに取り組んでいます。そこでは、私たちもオープン、ミスステップなどで非常に多くの作業を行いました。 タイムリーな更新を行うことを含め、何が起こっているかについて可能な限り透明性を保ちます（したがって、一部の人々に確認するまで、アクセシビリティ監査の費用を支払うことができるかどうか確信が持てません）。

私が探している監査の種類は、アクセシビリティを必要とするユーザーによるWordPressの使いやすさのマクロな感覚を最初に取得しようとしているので、あまりにも合法/コンプライアンス固有のものではないかもしれません。 ただし、コンプライアンス関連のものが含まれている場合：すばらしい。

現在、私は@WordPress Accessibilityコミュニティのメンバーや知識豊富な@automatticの従業員と連絡を取り、アクセシビリティ監査について連絡する人を何人か提供してくれました。 今のところ、公平で（WordPressコミュニティの外では、偏見や過去の知識などを避けるのに最適です）、高レベルで、実用的で、やや迅速に実行できるようにしたいと考えています。 私はたくさん質問していることを知っています😆

私は今何人かの人々を念頭に置いていますそして彼らに手を差し伸べますアクセシビリティ監査を専門とするいくつかの会社に連絡しました。 ここに更新を投稿しますが、来週まで詳しくはわかりません。 今のところ、次のものがあります。

1. 財政的支援を提供する必要はありません（しかし、OMGは持っている人たちに本当に感謝しています、それはあなたのWordPressへのコミットメントを見るのはとてもクールです）
2. サービスを提供する必要はありません（WordPressエコシステムの外部に誰かが欲しいと思いますが、定期的なバグ/アクセシビリティテストを支援したい場合は行って
3. 私からたくさん❤️🙂

素晴らしい週末をお過ごしください、私はあなた全員を投稿し続けます！ 😄

監査のために、さらにベンダーを探しているなら、私はお勧めWebAIMを一般的に米国でトップのWeb a11y資源の一つとして考えられているユタ州立大学、で。 彼らの素晴らしいウェブa11yドキュメントを読む以外の方法で彼らと提携していませんが、私は彼らが監査を提供しているのを見ました。

WordPress自体はオープンソースであり、まだ多くのボランティアの労力がありますが、それは今のところ「大きな時代」にぶつかり、「しかし、私たちはただのオープンソースです」という松葉杖に頼る余裕はありません。 完全なアクセシビリティ監査と、WPが不足していることが判明した場所（グーテンベルクだけでなく）を改善するという取り組みは、WPの採用に関して前進の大きな源になると思います。 さらに、もちろん、出版の民主化などもあります。

グーテンベルク（または外部プラグイン）が改善されている間、限られた時間だけクラシックエディタープラグインを使用したい/必要とするサイトはたくさんあります。 ソフトウェアを改善している間、Classicプラグインを数週間/数か月間必要とする、他の多くの問題とともに、アクセシビリティの問題に遭遇するユーザーがおそらくいるでしょう。

この感情は私には受け入れられないものであり、WordPressの価値観を内面化した他の多くの人々を願っています...

なんらかの理由で、最初はひび割れに陥ったユーザーの皆様には、あらかじめお詫び申し上げます。 しかし、すぐに実現しなくても、グーテンベルクとワードプレスを彼らにとっても素晴らしいものにするために努力することを知っておいてください。 ❤️

Coreの他のすべての基準に達していないエクスペリエンスをプッシュすることの利点は何ですか？ 締め切りは恣意的ではありませんが、それはあなたが手抜きをするという意味ではありません。 少なくとも、私が理解しているように、WordPressの値に従っていません。 これらの値は、Mozillaが持っていたものとは異なる可能性があります。コミュニティの新参者として、これらの値を調べることをお勧めします。

一般に、ほとんど働くことで十分であるという感情は、コミュニティに不必要なリスクを生み出し、誰がそれから利益を得るのか疑問に思う必要があります。 グーテンベルクプロジェクトまたはワードプレスの利点は何ですか？ 問題を特定するための支援が必要なわけではありません。

Automatticは明らかにこの監査のパラメーターを後援し、考案しているため、バイアスが発生する可能性があり、彼らは自分の仕事を採点しているようです。 より大きなコミュニティがクラウドファンディングを進めて、実際のユーザーの観点から並行レポートのためにアクセシビリティスペシャリストを雇うことを提案します。 Automatticは技術的な監査などを行うことができるかもしれませんが、グーテンベルクのアクセシビリティは「それほど悪くない」という提案は、この分野の実際の専門家（つまり、WordCampPublishersのSinaBraham）によって激しく反対されています。 盲目のユーザーにアプリ内を移動して、もう一度使用するかどうかを言わせる、Mikeyテストに近いものが必要かもしれません。

ちなみに、これは私がこの仕事のためにアプローチしている会社に送っているものです。 それはアクセシビリティに関係する他の人々を助けるかもしれません、私にはわかりません。 少なくとも、透明性のためにここに投稿しています🙂

要件

WP-Adminを使用してWordPressWebサイトでGutenbergエディターを使用して実行される一連のアクセシビリティテスト。 これらのテストには、少なくとも次のテストフローを含める必要があります。

コアパブリッシングフロー

• 新しい投稿を作成する
• 一般的なコンテンツ（段落、画像、リスト、HTML、および表のコンテンツ。以下の「ブロックの使用」を参照）を追加します。
• すぐに投稿を公開し、意図したとおりに投稿します
• 日付ピッカーを使用して、将来の投稿をスケジュールします
• 投稿するカテゴリとタグを割り当てる
• 注目の画像を投稿に割り当てる
• 他のドキュメントレベルの設定、時間制限を試してみてください

ブロックの使用

これらはWordPress.comで最も使用されている上位20のブロックであり、アクセシビリティの問題のリストにまだ提出されていないアクセシビリティの問題を見つけるためにテストする必要が

1. 段落
2. 画像
3. 見出し
4. リスト
5. ギャラリー
6. 見積もり
7. embed / youtube
8. html
9. セパレーター
10. もっと
11. 表紙画像
12. ショートコード
13. ボタン
14. テーブル
15. スペーサー
16. 埋め込み
17. ブロック
18. 埋め込み/ twitter
19. 列
20. コード

これらのブロックは、使用を妨げるものがないこと、およびブロックレベルの設定にアクセスできることを確認するために、支援技術でテストする必要があります。

クラシックエディタ

クラシックエディタと比較して、アクセシビリティに関して顕著な回帰がないことを確認する必要があります。 ベアボーンクラシックエディターのコンテキストで作成できるのと同じ種類のコンテンツで投稿を作成することは、Gutenbergで実行できるはずです。 クラシックエディターと比較して編集エクスペリエンスの回帰がゼロであるグーテンベルクは、支援技術のユーザーのデフォルトの編集エクスペリエンスとして推奨できると言う私の究極の目標です。

考慮すべき支援技術

利用できるタイムラインが限られており、極端な徹底よりもアクション可能性が優先

• Internet Explorer / Edgeを使用したJAWS（Windows）
• Firefoxを使用したNVDA（Windows）
• Safariを使用したVoiceOver（MacOS）
• ZoomText

モバイル支援技術は、この監査の優先事項ではありません。 MacOSでのVoiceOverテストには、iOSVoiceOverユーザーとのクロスオーバーが含まれていることを願っています。 モバイルアプリの使用は、おそらくWebサイトの使用よりも焦点が当てられています。

オープンでの投稿レポートと問題

生成されたアクセシビリティレポートは、WordPressコミュニティに公開して投稿する必要があり、ゲートキーパーとして私（または他のAutomattician）を必要としないことを期待しています。 問題の原因と再現性に焦点を当てて、有用なコンテキストで問題をGitHubに投稿する必要があります。 範囲内に時間があった場合、または問題が特に複雑な場合は、修正の解決策またはアプローチを投稿できます。

@davisshaverこんにちは、私はあなたに完全に同意します。 徹底的で公平な監査は、a11yの最大レベルが遵守されていることを確認するために重要です。

エディタにアクセスできることを確認することが重要であるだけでなく、エディタへの変更も簡単にアクセスできるようにするための基盤が整っていることも重要です。 明らかに、私たちは人々が自分で行うことを強制することはできませんが、少なくとも人々がアクセス可能な実装の基盤を提供することはできます。

@tofumattまた、可能な限りの

@tofumatt更新していただきありがとうございます。 フォローアップの質問がいくつかあります。

1）5.0がリリースされる前に監査を完了する計画はありますか？
2）監査で問題が返された場合、それらに対処するための計画は何ですか？ 5.0のリリースは、対処されるまで延期されますか？
3）プロジェクトが今後どのようにアクセシビリティをテストするかについて計画が立てられていますか？

@tofumattさまざまな障害/障害を持つユーザーによるテストが必要な場合は、Hassell Inclusionという会社でいくつかの作業を行いました。彼らは、そのようなテストを整理できます。 それらはWordPressコミュニティから完全に削除されています。 同社は、BBCでアクセシビリティを担当していたJonathanHassellによって運営されています。

@tofumatt私はWordPressのアクセシビリティについても非常に心配しており、あなたの成功を支援したいと思っています。 私たちの組織に、技術テストと機能テストの両方を含む、希望する標準レベルの完全なWCAG-EM準拠のアクセシビリティ監査を実行させ、予算に合わせて必要な作業の一部を寄付することができます。

ATAGとWCAGAAの両方、そしておそらく2.0ではなくWCAG2.1を検討する必要があると思います。 また、発見されたギャップを埋めるための最善かつ最も持続可能な方法を選択するのに役立つ推奨事項とコーチングを提供することもできます。

私たちはあなたの開発コミュニティから独立した立場にありますが、WordPressを長年よく知っています。 私はすべてのIAAP認定を保持しており、WordPressプラットフォームで、民間部門と公共部門の両方で、長年にわたってそのような監査を何十回も主導してきました。 davidberman.com/aboutで善意をチェックして、最善の支援方法を決定してください。

ブロックの使用

少なくとも最初は、監査を行うチームに指示するか、「ブロック」とは何かについての知識を持っている必要があるかどうかはわかりません。 特別な指示なしに、グーテンベルクを初めて使用するユーザーと同じ初期状態である必要があります。 第二段階では、技術的になるとき、彼らはおそらくブロックが何であるかをすでに知っているでしょう🙂

コアパブリッシングフロー

アクセシビリティチームは、グーテンベルクの主なアクセシビリティの問題は全体的なユーザーエクスペリエンスであることに同意します。 この部分を拡張することをお勧めします。_publihsing_フローに限定するのではなく、より多くのタスクを含める必要があります。通常は、UIをナビゲートし、メインセクション（トップバー、編集領域、サイドバー）をジャンプする必要があります。 、公開パネル）。 これは、さまざまなコンポーネントの技術的な実装の詳細ではなく、一般的なグーテンベルクの設計に関連しています。 実際、アクセシビリティは設計です。

いくつかのタスクを提案したいと思います。

• 多数のブロック、たとえば最低20個のブロックで投稿を作成します
• 投稿の途中にある段落の1つを編集します
• フォントサイズとフォントの色を変更してから、コンテンツを再度編集します
• インサーターを使用して新しいブロックを追加します
• リンクを挿入する
• 言及を挿入する
• ブロックタイプの変更
• トップバーの設定で何かを変更してから、編集したブロックに戻ります
• サイドバーにジャンプし、ドキュメント/ブロック設定に切り替えてから、編集したブロックに戻ります
• 投稿のパーマリンクを編集する
• 再利用可能なブロックを作成する
• 既存の再利用可能なブロックを追加および編集します

考慮すべき支援技術

@tofumatt支援技術のみ、具体的にはスクリーンリーダーのみに言及していることに少し驚いています。 アクセシビリティの評価は、スクリーンリーダーのテストだけに限定することはできません。 アクセシビリティははるかに幅広いトピックであり、障害や障害に限定されません。 それは、誰もがWebにアクセスできるようにすることです。

障害や障害へのアクセシビリティを制限したい場合でも、それらは数えきれないほど多すぎます。 ほんの数例を挙げると、音声認識ソフトウェアのユーザー、運動障害、ロービジョン、認知障害、発作障害、代替入力デバイス、注意欠陥多動性障害、失読症、短期間の記憶喪失などです。一時的な障害、環境障害、加齢など、実際の「障害」として分類されませんか？

人間の状態はかなり不安定なので、_私たちは皆一時的にできる_ことを検討することをお勧めします。

いくつかのタスクを提案したいと思います。

この拡張されたタスクリストは、ユーザーが実行する必要があることを適切かつ現実的に示しています。

WordPressコア状態の

WordPressでリリースされたすべての新規または更新されたコードは、レベルAAのWCAG2.0ガイドラインに準拠している必要があります。

したがって、監査ではそれを考慮に入れる必要があります。 具体的なこと：

1）ブラウザを200％ズームすると、すべての機能が期待どおりに機能するはずです（これによりモバイルCSSがトリガーされる可能性があることに注意してください）1.4.4
2）すべての機能は、キーボード2.1を使用した場合にのみ期待どおりに機能するはずです。

ここで私たちが探しているのは、すべてのユーザーがすべてを使用できることであるということを覚えておくことが重要です。 一部のユーザーにとっては素晴らしいエクスペリエンスではないかもしれません。それがバージョン1の目的ですが、私たちが持っている標準は、完全に使用可能であることを確認することです。 すべてのソフトウェアにはバグが付属しています。重要なことは、バグについて知っていることと、バグを修正することと修正しないことのトレードオフを行うことです。

この監査を実施するための責任を主導してくれた

監査/一連のアクセシビリティテストを調べる際に、新しいエディターでリグレッションを起こしてはならない「コア」クラシックエディター機能のリストをコンパイルすると便利でした。

1. 段落テキストの作成/編集
2. 見出しテキストの作成/編集
3. 事前にフォーマットされたテキストの作成/編集
4. 箇条書きの作成/編集
5. 番号付きリストの作成/編集
6. 見積もりの​​作成/編集（「Blockquote」）
7. パラグラフと見出しのテキストの配置
8. 段落、見出し、リストアイテムのテキストからのリンクの追加、編集、削除
9. リスト/リストアイテムのインデント/デデント
10. 段落、見出し、リスト項目のテキストの太字/斜体/取り消し線
11. コンテンツに水平線/スペーサーを追加する
12. 元に戻す/やり直し
13. WordPressの「続きを読む」コメントの挿入（グーテンベルクの続きを読むブロック）
14. 段落コンテンツからリストコンテンツへの変換
15. リストコンテンツから段落コンテンツへの変換

それだと思うので、私が送ってきたものです。

私のアクセシブルなテクノロジーのリストはごくわずかで、同意しました。 その一部はスコーピングに関するものですが、それは私が時間とともに追加したいと思っていた少し不完全なリストだったためです。 そのリストに

@aferciaのタスクリストを確認したところ、同意します。これはすばらしいリストです。 そのリストからできるだけ多くをプロジェクトに含めるように取り組んでいきます。 今のところ元のリストを更新するつもりはありませんが、監査/テストが開始されたら、タスクの最終的なリストを投稿します。 ありがとう！ 👍

いくつかの質問に答える

@bamadesigner ：

現在の計画では、監査をできるだけ早く開始し、5.0リリースの前にできるだけ多くの情報を入手して、見つかった問題に対処し、そのアクセシビリティに関するコンテキストをリリースに追加することです。 リリースを遅らせるという点では、問題、修正する時期、およびその影響によって異なります。 私の見解では、リリースが遅れる可能性は低いと思いますが、その橋を渡る必要があります。 推測したくない。

今後のアクセシビリティテストの計画に関しては、これはより大きな問題であり、リリースやこの問題とは関係がないため、ここでは取り上げません。 今のところ、私は5.0のリリースリードであり、そこで焦点を当てます。 繰り返しますが、私は推測したくありません。 しかし、WordPress 5.0から息を呑んだ後、それを調べてうれしいです😄

@LukePettway

アクセシビリティテストを行った経験がある場合は、グーテンベルクをテストするか、既存のアクセシビリティの問題を優先順位付けして、まだ問題があり、何に焦点を当てる必要があるかを把握しておくとよいでしょう。 マージの問題に取り組む

@tofumatt回答ありがとうございますが、がっかりです。

Gutenberg / 5.0は、監査が完了し、見つかった問題が解決されるまでリリースしないでください。 うまくいけば、監査が戻ってきて、問題はわずかしかないということですが、5.0のリリースは、その発見と解決に必要な時間に依存しているという決定が必要です。

私はこの11月の締め切りを推進しているものについては何も知りませんが、アクセシビリティは非常に重要です。 これらの基盤がカバーされていることを確認する前に起動すると、コミュニティ全体、およびWeb全般に危険な前例が設定されます。そのアクセシビリティは最優先事項ではなく、後で待つことができます。

WordPress 5.0は、アクセス可能になるまで準備ができていません。 他の期限はこれ以上重要ではありません。 アクセシビリティのコア標準に違反しているという事実は言うまでもありません。

WordPress 5.0は、アクセス可能になるまで準備ができていません。

@bamadesignerは真実を話します。

WordPressが表明した目標は、「出版を民主化する」ことです。 それは、文字通りの意味で、誰もが公開できるようにすることを意味します。 アクセシビリティはこの約束の中心です。

目標と約束が同じではなく、そのように扱われるべきではないと言うのは、曖昧ではないことを願っています。 😄

前に述べたように、私はアクセシビリティの問題、特にMerge：Accessibilityマイルストーン（
https://github.com/WordPress/gutenberg/milestone/43）。

リリース時にアクセシビリティを壊す問題があると判断された場合は、Tracでの@rianrietveldの提案を再検討して、グーテンベルクの特定の問題に関する支援技術についてユーザーに、グーテンベルクが提示する場合はクラシックエディターを使用することを提案します。使いやすさの問題。 特定の既知の問題とそれらが誰に影響を与えるかを強調したいと思います。

いずれにせよ、それが私の呼びかけになるかどうかはわかりませんが、たとえそうであったとしても、Classic Editorがフォールバックとして存在する場合、アクセシビリティの懸念から5.0リリースを遅らせることは良い決断ではないと思います。 5.0の目的/主な機能は、新しい編集エクスペリエンスであるグーテンベルクです。 私はむしろそれを使用可能だと思うユーザー（支援技術のすべてではないが多くのユーザーを含むべきである）のためにそれをリリースし、誰もが初日にグーテンベルクを使用できるわけではないことを受け入れる。 これは、互換性のないプラグインを使用している非常に多くの人にとってすでに現実です。 5.0のリリース時に誰もグーテンベルクの使用を強制していません🙂

クラシックエディタは存在しますが、 WordPressの一部では

非常に良い点

私はむしろそれを使用可能だと思うユーザー（支援技術のすべてではないが多くのユーザーを含むべきである）のためにそれをリリースし、誰もが初日にグーテンベルクを使用できるわけではないことを受け入れる。

これは信じられないほど冷静なコメントであり、この立場はせいぜい貧弱なデザインであり、最悪の場合は積極的に障害者差別的です。 これが解決策ではないことを心から願っています。

@tofumattあなたが

いずれにせよ、それが私の呼びかけになるかどうかはわかりませんが、たとえそうであったとしても、Classic Editorがフォールバックとして存在する場合、アクセシビリティの懸念から5.0のリリースを遅らせることは良い決断ではないと思います。 5.0の目的/主な機能は、新しい編集エクスペリエンスであるグーテンベルクです。 私はむしろそれを使用可能だと思うユーザー（支援技術のすべてではないが多くのユーザーを含むべきである）のためにそれをリリースし、誰もが初日にグーテンベルクを使用できるわけではないことを受け入れる。

あなたはすでに疎外されているユーザーの人口に、WordPressを彼らが使えるようにすることに取り掛かることを伝えています...最終的には。 あなたはそれがどのように疎外されているか分かりますよね？

しかし、おそらくもっと重要な一連の質問はこれです：

• 新しいエディターを正式にコアにマージする準備ができているかどうかを判断するのは誰の呼びかけですか？
• 彼らはその決定を下すためにどのような要因を検討していますか？
• コミュニティとして、アクセシビリティをその意思決定プロセスの中心にするために何をする必要がありますか？

明確にするためにhttps://core.trac.wordpress.org/ticket/44671にあり、終了しました🙁

私はむしろそれを使用可能だと思うユーザー（支援技術のすべてではないが多くのユーザーを含むべきである）のためにそれをリリースし、誰もが初日にグーテンベルクを使用できるわけではないことを受け入れる。

ここでは、クールで素晴らしい、素晴らしい障害者差別があります。 @briandeconinckが言ったように、ユーザーがキーボードとマウス（またはディスプレイ）を適切に使用できないという理由だけで、ユーザーのグループ全体を疎外していることになります。 私たちの大学は、WordPressエクスペリエンスをアクセシブルにするために多大な労力と労力を費やしてきましたが、現在も取り組んでいます。 このように大きくて重要なWordPressコアを起動する可能性があり、そうでない場合は非常に残念です。

@aferciaああ、私はそれを完全に知っています！ 私は確かに、アクセシビリティチームの立場がリリースを遅らせることであったことを意味するつもりはありませんでした。 ここのコメントの何人かの人々はそれについて尋ねていましたそれがすべてです。 間違えてチームに入れてしまったら本当にごめんなさい。 ❤️

その問題は解決されました（部分的には「試行」の呼び出しがなくなるため、その意図について何らかの誤解があった可能性があります）が、ここで述べたように：ユーザーに支援を警告するという概念を実装しても問題ありませんグーテンベルクが彼らのために働くつもりがないならば、技術。

私はこのスレッドの他の人たちが5.0より前にアクセシビリティの改善を推進していることに同意します。 また、5.0のリリースは、グーテンベルクが実際に使用する準備ができているWPエコシステムの残りの部分によって青信号として解釈されることを付け加えておきます。 その時点で、グーテンベルクを拡張し、グーテンベルクが独自の開発の青写真として提示した標準に依存するプラグインとテーマの流入が見られます。

WPエコシステムの開発者として数年間、私は常にWordPressコアに目を向け、自分のプラグインのアクセシビリティ、スタイル、動作がコアのものと一致していることを確認しています。 アクセシビリティの問題が解決される前に5.0がリリースされた場合、WordPressコミュニティは、独自の開発のモデルとして、アクセスできない青写真を探します。 ブループリントが、これまでに設定した他のすべての基準を満たしていることを確認しましょう。

@tofumattコアエディターがインストールする必要のあるプラグインになり、ユーザーがそのプラグインをインストールする能力/知識？ 私はこれを誤解していると思いますが、明確にしていただけますか？

いつものように、お時間をいただきありがとうございます！

Classic Editorプラグインは、グーテンベルクに切り替える準備ができていない人のための一時的なオフランプとして構築されました。 それはせいぜい数が少なく、2人の異なるエディターにソリューションを提供しなければならない開発者にとってすぐに問題になるでしょう。 Classic Editorプラグインは、文字通り障害に基づく劣ったエクスペリエンスを提供するため、アクセシビリティを必要とする人々にとって一時的なオフランプになることはできません。 WordPress管理者の最小要件はWCAG2.0AAです。 エクスペリエンスを低下させるプラグインを含むその他のものは、当社独自のポリシーに違反します。 ルールがあるので、私はこれについて厳しい方針を取っています。 独自のコーディング基準を満たしていないコードは出荷していません。 アクセシビリティも同じです。

ここにいる他の多くの人たちと同じように、コミュニティと人々がグーテンベルクに時間と労力を注ぎ込んで、5.0に対応できるようにする努力に感謝しています。 それは完全にはアクセスできないため、単純に、グーテンベルクの準備ができていません。 話の終わり。

グーテンベルクがアクセス可能になるまで、コアにマージしないでください。 グーテンベルクを「それを使用できる人」のコアにリリースするという概念は、近視眼的であるだけでなく、ひどく排他的です。これにより、WordPressユーザーに「個別であるが同等の」エクスペリエンスが作成（および正規化）されると言えます。 それはひどい前例であり、ひどく傲慢です。

コミュニティが普及し、コアチームが完全にアクセス可能になるまで5.0のリリースを差し控えるように説得することを願っています。 そのためには、独立した監査を行うことをお勧めします。

この問題は、アクセシビリティ監査に関する私の作業を公表し、それを実行したいことを伝え、ブログ投稿でその監査の共有を追跡するために提出されました。 これは、WordPress5.0のリリースブロッカーと見なすべきものに関する議論のポイントを意味するものではありません。 この件に関する人々の意見を書き留めたので、WordPress5.0のリリースリードである@mにそれらを伝えます。 私の理解は：

1. 5.0を超える配送には拒否権がありませんが、持っていたとしても：
2. リリースを妨げる十分なアクセシビリティの問題があるとはまだ確信していません

2番目のポイントが変更された場合は、その情報を中継します。 私は提唱者になるつもりですが、タイムラインを設定しておらず、アクセシビリティに関する確かなデータもありません。 それが監査のポイントです。つまり、ハードデータの場所から話すことができます。 🙂

すべてのご意見に感謝しますが、この議論は意図された範囲からかなり外れたものになっているため、今のところこの問題の会話をロックしています。 開いたままにして、監査に関する最新情報を投稿します。

Slackでこの問題について少し余分な議論がありました： https ：

これまでこの問題をフォローしてきたすべての人が何が起こっているかについて最新情報を入手できるように、ここで対処する価値があったと思います。 @ mor10はまた、監査の結果が明確に伝えられていないと感じていると指摘しました。 この投稿での私のコミュニケーションには多くの誤解があったようです。それについてはお詫びします。 私は今できる限り最善を尽くして答えようとします。

クローズドチケットの混乱の多くは、リリースタイムラインに間に合うように監査を完了できない場合、または監査が戻ってきて修正が必要な重大な問題を指摘した場合にどうなるかについての明確さの欠如に起因すると思います。 あなたのコメントに基づいて、あなたが考えるかどうかは不明です：

• a）すべての問題は現在のタイムライン内で修正されます
• b）期限内に修正できない問題は5.0.1にプッシュされます
• c）重大な問題が提起された場合、タイムラインはシフトされます。

これまでに、aまたはbのみを示すように言ったことはオプションですが、私が言ったように、それは不明確です。 リリース期限に間に合うようにアクセシビリティがパントされるという考えは、人々が1年以上心配してきたことであり、それらの懸念は緩和されていません。

• @ mor10 in Slack（https://wordpress.slack.com/archives/C02RP4X03/p1539303342000100）

マイルストーンの現在の問題に基づいて、私の目標はすべての問題を修正することですが、それらすべてがリリースブロッカーを構成するとは思いません。 最終的なタグ付けの近くでそれらをトリアージする方法をよく知っているので、今はそれに多くを追加することはできません。 今のところ、5.0より前に最も重要な問題の現実的なリストだと思います

修正できない問題は、次のWordPress / Gutenbergリリースに移動する必要があります。

現在、リリースを遅らせることを正当化するものは何もないと思います。

この問題を作成する際の私の目標が次のとおりだったため、この問題はロックされました。

1. 監査を委託する私の仕事を共有する
2. その投稿を取り巻くMake / Accessibilityに関するブログ投稿を作成する私の仕事を共有する

監査をどのように実施できるかについての意見に感謝します。また、アクセシビリティがグーテンベルクで深刻な問題になっている場合に、クラシックエディターの「バックアップ」推奨を取り巻く問題について聞いていただきありがとうございます。 グーテンベルクを評価し、アクセシビリティの理由でそれに対して推奨していることを指摘する報告は今のところありません。 私はそれを見たことがなく、ここでは誰もリンクしていません。 ここでの感情は、投機的な失敗に関するものです。 その種の言語は、一生懸命働き、想定された善意の欠如を見るグーテンベルクの開発者に意欲をそそります。

アクセシビリティリリースリードの役割は新しく、先週私に渡されたかったのです。 同時に、2018年11月19日のリリース日が確定しました。 リリースリードの役割が割り当てられたときの私の最初の本能は、Automatticの資金を使って、アクセシビリティへの取り組みのしるしとして監査を作成し、支援技術の使用に関してグーテンベルクが直面している実際の問題を具体的に理解しようとすることでした。 私は制約のあるタイムラインに取り組んでおり、可能な限り適切に情報を共有していますが、話し合っている企業を公に評価したくないという警告があり（専門家ではないと思います）、 Automatticを使用したものの調達側（私が知る限り、この監査のその側面は公開できません）。

私はリリースの最終決定者ではありません。 この問題については@mをCCで

はい、全体的にアクセシブルなデザインのより大きな問題がありますが、開発チームとデザインチームはこれらの問題を考慮しています。 私は、大部分が非常に有能なユーザーのチームであるため、私たちが認識し、テストするものが少ないことに関心があります。

Slackの何人かの人々は、この問題はフィードバックとより広範な議論を求めているように見えるという彼らの観察を私に表明しました。 これは、この問題を提出する私の意図ではなく、単にすべてをオープンに保つことでした。 GitHubは主にこのプロジェクトに取り組んでいる場所なので、そうするのに最適な場所だと思いました。 議論はプロジェクト全体に有効である可能性がありますが、気が散っていたため、問題をロックしました。

1. 手元にある問題（および監査と結果を含むブログ投稿）
2. 問題のコメントによって通知されるチーム全体

問題のコメントは、実用的で個別であり、できれば新しい情報を提供する必要があります。 ここでのコメントはこれらの基準を満たしていないように感じたので、議論を目前の問題に限定したいと思いました。

この問題はWordPress5.0でも発生させたいので、マイルストーンで提出しました。 それが不可能な場合、悲しい結果はそれを移動する必要があるということです。 私は限られたリソースで制約されたタイムラインの下で働くために最善を尽くしています。 誰もが「パッチを歓迎する」わけではありませんが、アクセシビリティが重要な場合は、未解決のアクセシビリティの問題のリスト、特にマイルストーン：アクセシビリティリストのリストに注意を向けていただければ幸いです。

監査の進捗状況を追跡したいので、この問題を開いたままにしておきたいと思います。 アクセシビリティに関連して他に話し合いたいことがある場合は、[新しい問題]ボタンが常に表示されます。 このコメントを書いているときに、新しい問題がすでに提出されていることに気付きました（＃10537）：それはクールです😄

みなさん、ありがとうございました。素晴らしい金曜日をお過ごしください。 ❤️

@tofumatt監査に関する情報を更新できますか？

まず最初に、私はこの1週間、監査の実施についていくつかの企業と話し合い、それらの企業から提案を受け取りました。

私は非常に詳細な提案を以下から受け取ったと言います：

• レベルアクセス
• Deque Systems

そして、詳細ではありませんが、それでも素晴らしい回答があります。

• パシエログループ
• ヘイドンピッカリング

彼らは皆自分たちのことを知っているようだった。 適切ではないと思うので、提案の詳細を共有するつもりはありませんが、監査の面で残念なニュースがあります。 😢

Automatticは、少なくとも当面の間、グーテンベルクでのアクセシビリティ監査の実施を控えることを決定しました。 主な理由は次のとおりです。

1. リリースタイムラインを考えると、監査は実行可能ではありません。理由は…
2. 監査はリリースのタイミングに影響を与えないため、...
3. 将来的には、急いでいないタイムラインで監査を検討する方が賢明です。

今後、監査を検討していきたいと思いますが、残念ながら、マージ提案の前には監査が行われないため、修正されないため、この問題をクローズします。 グーテンベルクのアクセシビリティの状態について、良い面と悪い面の両方についてブログを書きたいと思います。 今週は、キーボードナビゲーション、色のコントラスト、フォーカスの動作、日付/カラーピッカーにいくつかの改善を加えています。

希望を持って、これでコミュニティを失敗させてすみません。 😞

5.0以降に発生した場合でも、これが継続されることを望んでいることを簡単に説明します。
それを開いたままにして、別のマイルストーンまたは将来に割り当てない理由はありますか？

私たちは最近、少し感情的なジェットコースターに乗っていることは確かですよね？ 🎢

まず第一に、皆さんの仕事に感謝します。 💖アクセシビリティの擁護者になるのは簡単ではない場合があることを私は知っています、それは絶え間ない上り坂の戦いのように感じることができます。 あなたが影響を与えていることを知ってください：個人的なもの（WordPressのアクセシビリティチームを構成する人々からアクセシビリティについて多くを学びました）から、基本的なもの（人間中心のデザインは現代のデザイン実践の本質的な側面です） ）。

私はプロの監査のアイデアが本当に好きですが、WordPressでこれらのいずれかを行ったことは覚えていませんが、リリースの条件ではありません。 いつかそういうことが起こるのを見たいです。 WordPressは常に、共通のパターンとセマンティクスに固執することでアクセシビリティのほとんどを実現しようとしてきましたが、その違いは、アクセシビリティチームの全員がテストを行い、実用的なバグレポートを提出するボランティアの主要な取り組みによってカバーされています。 グーテンベルクが完全にJavaScriptベースのアプリケーションに移行したことで、これらのパターンを適用することが難しくなりましたが、協力して新しいパターン、新しいベースラインを確立することができます。

グーテンベルクにはまだまだ磨きが必要であり、これは私たちが行っていることです。他のすべてと同様に、今後数か月から数年にわたって繰り返し続ける問題があります。 多くの会話に基づいて、最も重大な問題はすでに提出されているようであり、それらの多くは修正されており、問題が発生したときに修正を続けます。

まだマイルストーンされていない問題が

これについては前に説明しましたが、繰り返しになります。WordPress5.0はフィニッシュラインではなく、スターターピストルです。 このスレッドの私たちの多くは、グーテンベルクが始まる前に何年もの間WordPressで一緒に働いてきました、そして私たちは今後何年もの間WordPressで一緒に働くことを願っています。 何年にもわたって多くの新機能がWordPressに登場するのを見てきましたが、それらのどれも最初にリリースされたときと同じままではありませんでした。 私たちは、他のほとんどのプロジェクトが乗り越えられないものとして取り消すであろう課題に直面しましたが、私たちはそれらを機能させました。

WordPressの使命は、出版を民主化することです。 アクセシビリティとは、歴史的に信じられないほど疎外されてきた人々のために物事を機能させることです。 これらは単なる補完的なものではなく、WordPressの使命は本質的にアクセス可能である必要があります。

WordPress 5.0でリリースするものは決まっていないので、引き続き修正し、作り直し、そこから学び、改善していきます。 グーテンベルクは、次世代のWebを構築するための基盤であり、Web全体のアクセシビリティを向上させる可能性もあります。 すべてのコンポーネント、すべてのブロック、すべてのインターフェイスに完全にアクセスできる必要があり、すべてのプラグインとテーマが最終的にそれを利用できる必要があります。 グーテンベルク世代は、_デフォルトで_アクセシブルなエクスペリエンスを提供する必要があります。 それだけでなく、色のコントラストチェッカーと見出し階層の警告は、グーテンベルクがアクセシブルなコンテンツの作成をデフォルトの動作にする方法の良い例でもあります。

この号のロックを解除して再度開き、将来に向けてマイルストーンを作成しましたが、後で簡単にマイルストーンに近づけることができます。 私たち全員がトピックにとどまり、生産的な会話に集中するように努めることを特別に要求します。 ここで始めたものを取り入れて、質の高いアクセシビリティ監査のフレームワークを見つけてもらいたいと思います。これは、グーテンベルクのフェーズ2以降の範囲にまで拡張できるものです。 私たちはまだそこにいないかもしれませんが、そうなるでしょう。 ❤️

関連＃10537。

WordPress 5.0はフィニッシュラインではなく、スターターピストルです。

しかし、最終的には、そのスターターピストルは能力の異なる人にしか機能しないようです。 スターターピストルは実際に機能します。これは、聴覚障害者が感じることができる空気中の航跡を作成するのに十分な大きさの音であり、彼らが見ることができるフラッシュ/煙を作るためです。 目の不自由な人に聞こえる音を出します。 スターターピストルは誰でも利用できます。 グーテンベルクはそうではないようです。

a11y監査が実行されるまで、グーテンベルクのリリースを一時停止することを検討することさえ拒否することで、WordPressコミュニティにとって重要ではないことを_物理的に_グーテンベルクを使用

アクセシビリティの知識を持った人がチャイムを鳴らす必要がある問題のために「NeedsAccessibilityFeedback」ラベルを作成しましたが、この問題に対処できるものがないため、ラベルを削除します😄

@cgrymala、誰もそのようなことを言っていません。 私が述べたように、プロのアクセシビリティ監査は、WordPressの歴史に統合される機能の要件ではありませんでした。 確かに監査が行われることを望んでいますが、監査の欠如が「無責任...恥ずかしくて危険」であると書くことは、建設的な対話の邪魔になる一種の誇張です。

以前のコメントからのリクエストを繰り返します。トピックに生産的な会話に集中してください。

さらに重要なことは、監査がなくても問題の修正が妨げられることはありません。 アクセシビリティが重要である場合、あなた（またはあなたが知っている誰か）が支援技術を使用している場合、今がバグをテストして報告する絶好の機会です。

@pento 、監査が先例であると誰もが主張していることに気づきませんでしたか？ それはストローマンの議論のように思えます、そしてこのスレッドに基づいて、先例は単に監査アイデアの起源ではありませんでした。

監査は@tofumattによって提案され

認証のハードルを考えると、これをコアに取り入れることで、コミュニティがプラグインから得られる以上のメリットがWPにもたらされるとは思いません。 現在の状態では、メリットがコストを上回っているとは思わないので、単純さの面で誤りを犯す必要があります。

それは、 @ mがWPAPIの討論中に言ったことです。 これは、このリサイクルサイクルを明らかにする偽善のさらに別の例です。「期限は恣意的ではない」会社が、5.0のリリース日を設定することを拒否したという事実から始まり、気に入ったものが見つかるまで、議論の余地はありませんでした。 。 私はグーテンベルクが大好きで、毎日使っています。 それはプラグインとして大きな価値を提供し、マット自身のヒューリスティックによれば、それが本当に準備ができるまで、単純さの側で誤りを犯すべきです。

アクセシビリティは、この行き詰まりを乗り越えるための時間、サポート、およびお金を提供してくれたこのスレッドの多くの人々にとって重要です。 私たちが本当に気にかけていれば、問題を修正するだろうとあなたが提案するのは不誠実です。

監査を取り消す理由について：

リリースタイムラインを考えると、監査は実行可能ではありません。理由は…
監査はリリースのタイミングに影響を与えないため、...
将来的には、急いでいないタイムラインで監査を検討する方が賢明です。

サードパーティの監査のアイデアが死んでいたとしても、 https：//github.com/WordPress/gutenberg/issues/10537のアイデアに暗黙のうちに含まれているのは、アクセシビリティ手段に関するグーテンベルクの監査です。 Automatticがアクセシビリティの自主基準なしでGutenbergをCoreにリリースする用意があるという事実は、非常に問題があります。 結局のところ、グーテンベルクの開発とリリースに関しては、Automatticの利益がコミュニティの利益よりも促進されているように見えることを思い出して、最終的にはがっかりしました。

このスレッドについて：

1. 監査の実施
2. 監査に基づくファイリングの問題
3. 結果をレポートとしてMake / Accessibilityブログに投稿する

私たちは監査の有用性を認識しており、人々は監査の実施を望んでいます。 以下のプロセスに関連するコメントを保管してください。

1. 監査の実施
2. 監査の範囲
3. 監査の結果

私は、言われたことを再ハッシュし、監査の重要性を強調しているトピック外のコメントを隠しています。 実施していただきたいと思います。 私たちは皆、そこで合意しています。 トピック、生産性についてコメントを残し、目前の問題に新しい情報を提供したり、問題に追加したりしていることを確認してください。

@davisshaver特にWordPressのエチケットを覚えておいてください：

WordPressオープンソースプロジェクトへの貢献は、特定の企業や個人ではなく、WordPressコミュニティ全体の利益のためです。 貢献者としてとられるすべての行動は、コミュニティの最善の利益を念頭に置いて行われるべきです。

WordPressオープンソースプロジェクトは、ボランティアが運営するコミュニティです。 寄稿者が企業によって後援されている場合でも、その時間はオープンソースコミュニティ全体の利益のために寄付されます。

@pento、@tofumatt、@m等がオートマティックから寄贈されているが、それらはプロジェクトの改善のために働いています。 Automatticは、グーテンベルクがいつリリースされるかを決定しているものではありません。

@pentoが指摘しているように、監査は継続でき

今こそ、バグをテストして報告する絶好の機会です。

そのテストとレポートのプロセスに貢献するためにできることは何でも有益です。 テストをできる古い問題がいくつかあります。 そうすることは大きな助けとなり、部分的には独立監査が提供したであろうものです。

WordPress.orgのリリースリーダーであることが、マットがAutomatticに受託者責任を放棄することに関係していることを私は知りませんでした。 対立は最小限である、またはマットは対立を緩和するために積極的に取り組んでいると主張することもできますが、引用したWordPressのエチケットは推奨事項であり、世界の説明ではありません...最終的に対立は存在します。

現在、多くの人がこのトピックを潜んでいると確信しています。興味があり、支援したいが、（スクリーンリーダー）がhttps：// makeでディスカッションに参加する前に、支援技術を使用したことがない場合は.wordpress.org / chat / 。 私にもDMで遠慮なく連絡してください。 NVDA / Voice Over / JAWSを使用してセットアップを簡単に行うことができ、テストを開始できることに驚かれるかもしれません。

それ以外にも、WCAG要件のテストに利用できるツールがたくさんあります。
Chrome aXe：
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd

WCAGのコントラストチェッカー： https ： = en

Chrome A11yツール： https ：//chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb？hl = en

現在開いているアクセシビリティラベルには113の未解決の問題があります。
https://github.com/WordPress/gutenberg/labels/Accessibility

現在の決定に同意するかどうかにかかわらず、解決に向けて手を貸すために参加できる作業がまだたくさんあることに同意できると思います。 公式の監査がない場合でも、コミュニティには、よりアクセスしやすいエクスペリエンスの提供を支援する力があります。

この問題は、アクセシビリティ監査に関する私の作業を公表し、それを実行したいことを伝え、ブログ投稿でその監査の共有を追跡するために提出されました。 これは、WordPress5.0のリリースブロッカーと見なすべきものに関する議論のポイントを意味するものではありません。 この件に関する人々の意見を書き留めたので、WordPress5.0のリリースリードである@mにそれらを伝えます。 私の理解は：

1. I don't have have veto over 5.0 shipping, but even if I did:

2. I'm still not convinced there are sufficient Accessibility issues that prevent a release

2番目のポイントが変更された場合は、その情報を中継します。 私は提唱者になるつもりですが、タイムラインを設定しておらず、アクセシビリティに関する確かなデータもありません。 それが監査のポイントです。つまり、ハードデータの場所から話すことができます。 🙂

すべてのご意見に感謝しますが、この議論は意図された範囲からかなり外れたものになっているため、今のところこの問題の会話をロックしています。 開いたままにして、監査に関する最新情報を投稿します。

文字通り、最近と最初の両方でグーテンベルクをテストしたすべての障害者は、なぜそれがアクセスできないのかについて、ブロッキングの問題にフラグを立てています。 また、ユーザーテストは、WCAG2.0レベルのAA準拠と同様にアクセシビリティにとって重要です。 おそらくこの時点でWCAG2.1 AAと言うべきですが、WCAG 2.0を使用すると、必要な場所にかなり近づくことができます。 あなたがデータを持っていないと言うことはせいぜい不正確です。

この場合の監査の欠如は無責任です。なぜなら、初心者にとっては、過去のWordPressとは異なり、すぐに利用できるコンポーネントが付属していないフレームワークが選択されており、過去のWordPressとは異なり、ドキュメントを大幅に変更しているからです。グーテンベルクを使用したオブジェクトモデル、およびアクセシビリティツリーからの削除、ブラウザの場合、DOMとアクセシビリティツリーは、文字通り、支援技術が解釈する情報を取得する方法です。 グーテンベルクが現在立っているように、これから支援技術を除外しても、認知的負荷は膨大です。 古典的なエディタプラグインは完全に受け入れられない代替品です。 手始めに、それはサイト全体です。 したがって、サイトがグーテンベルクを使用していて、コンテンツを使って何かをする必要がある場合、ユーザーごとにそれを行うことはできません。また、クラシックエディタープラグインをインストールして作業を行ってからアンインストールすることもできません。グーテンベルクへの復帰が行われると、すべてが正常に動作することを期待します。 そして、はい、私はこれをテストしました。 アクセシビリティが後付けとして残されているという事実は、文字通り、WordPressがアクセシビリティチームが最初に軌道に乗った2011/2012年に混乱した方法です。 そして、このプロジェクトは文字通りまったく同じ過ちを犯しており、最終的にはこれが再び正しくなると信じるように求めています。 申し訳ありませんが、障害を持つ人々は、より大きな利益のために何回バスの後ろに送られなければなりませんか？ アクセシビリティについて、次回はもっとうまくいくと約束する方法について、たくさんのかわいい言葉に満足しなければならないことが何度もありますが、真鍮の鋲になると、アクセシビリティは実際にはそうではないことがわかります。優先？

Automatticは、少なくとも当面の間、グーテンベルクでのアクセシビリティ監査の実施を控えることを決定しました。 主な理由は次のとおりです。

1. リリースタイムラインを考えると、監査は実行可能ではありません。理由は…
2. 監査はリリースのタイミングに影響を与えないため、...
3. 将来的には、急いでいないタイムラインで監査を検討する方が賢明です。

@tofumatt @pentoここに記載されているタイムラインが、提案されているWordPress 5.0の範囲とスケジュールに記載されているように、2018年11月19日または2019年1月22日のリリース日を参照しているかどうかを明確にできますか？

2019年1月22日の日付では、本日から5.0のリリースまでの間に3か月以上、監査を完了してアクションを実行することができます。 上記の理由は、監査を完了できず、3か月以内にアクセシビリティを大幅に改善できないことを示唆しています。 trueの場合、それがプロセスを今すぐ開始し、5.0リリースの前にできるだけ多くの問題を修正することで監査に対応する理由です。

5.0以降（最も必要としている実際のユーザーの手に渡ったとき）にタイムラインが急がなくなるという考えは、まったく意味がありません。

WCAG 2.0レベルのAAに準拠していたが、Gutenbergで編集された新しいコンテンツは、5.0がリリースされたときに準拠しなくなり、法的な悪夢が解き放たれます。

これまでここにコメントして、トピックについて議論を続けてくれた皆さんに感謝します。 私は本当に感謝しています。WordPress5.0の周りで多くのことが起こっているので、この問題に値する時間を取っておくことができて本当に助かります。 🙂

@amandarush ：あなたはいくつかの懸念について言及しました、私はそれらすべてに答えようとします、しかし私が何かを逃すならば私に知らせてください。

文字通り、最近と最初の両方でグーテンベルクをテストしたすべての障害者は、なぜそれがアクセスできないのかについて、ブロッキングの問題にフラグを立てています。

これらの問題にフラグを立ててくれたすべての人に心から感謝しています。 これらの問題が発生したときに、それらに対処するための合理的な仕事をしたと思っていましたが、明らかにやるべきことがまだあります。 @tofumattが「データがない」と物事の現状を完全に把握していないので、残りの問題の重大度をより明確に把握します。

この場合の監査の欠如は無責任です。なぜなら、初心者にとっては、過去のWordPressとは異なり、すぐに利用できるコンポーネントが付属していないフレームワークが選択されているからです。

ここでReactについて言及していますか？ 私の理解では、Reactで構築されたアプリケーションは、DOMを動的に更新する他のライブラリからも同様にアクセスできます。 aria-*属性を適切に使用する（および予測可能なキーボードフォーカスを確保する）場合は、支援技術で使用できるはずです。 これは正しくありませんか？

古典的なエディタプラグインは完全に受け入れられない代替品です。 手始めに、それはサイト全体です。 したがって、サイトがグーテンベルクを使用していて、コンテンツを使って何かをする必要がある場合、ユーザーごとにそれを行うことはできません。また、クラシックエディタープラグインをインストールして作業を行ってからアンインストールすることもできません。グーテンベルクへの復帰が行われると、すべてが正常に動作することを期待します。

このユースケースを提示していただきありがとうございます。これは、ClassicEditorプラグインが現在失敗している良い例です。 ユーザーごとのオプションを追加することはできます。

そして、このプロジェクトは文字通りまったく同じ過ちを犯しており、最終的にはこれが再び正しくなると信じるように求めています。 申し訳ありませんが、障害を持つ人々は、より大きな利益のために何回バスの後ろに送られなければなりませんか？ アクセシビリティについて、次回はもっとうまくいくと約束する方法について、たくさんのかわいい言葉に満足しなければならないことが何度もありますが、真鍮の鋲になると、アクセシビリティは実際にはそうではないことがわかります。優先？

申し訳ありません。 グーテンベルクチームの全員の最善の意図にもかかわらず、私たちは十分なことをしていません。 正直なところ、アクセシビリティは常に優先事項であったと言えますが、それは十分に高い優先順位ではなく、アクセシビリティが改善された場所でのコミュニケーションは不十分でした。 以前のコメントでこれらの改善のいくつかについて言及しましたが、ベースラインのアクセス可能なエクスペリエンスに到達していなければ、これらの改善は役に立ちません。

もちろん、謝罪はそれを正しくするための行動なしでは役に立たないので、これが私が提案していることです。 現在のところ、可能な限り多くのアクセシビリティの問題に優先順位を付けて修正することを目的としています。 すでに数百を修正しており、未解決の問題のいくつかについてはすでに修正が進行中です。 もちろんテストは行いますが、バグを発見するために支援技術を使用する人々の経験が必要です。 あなたが時間を作ることができるどんなテストとバグ報告も大いに感謝されます。

5.0がリリースされるまでに、ブロックエディタを支援技術ユーザーにとって許容できるUXになる状態にできると思いますが、それができない可能性があることは認識しています。 あなたが提案したユーザーごとの設定とは別に、クラシックエディタープラグインがブロックエディターの状態に満足するまで人々が使用するための合理的なオプションであることを他にどのように保証できますか？

独立したアクセシビリティ監査が行われることを望んでいますが、5.0リリースの急いでいるタイムラインはありません。 ここで、この問題を使用して、包括的な監査のフレームワークを作成できます。 問題が発見されたので、5.0.xリリースで修正できるので、5.1を待つ必要はありません。

@kevinwhoffman ：タイムラインは、11月19日（または遅くとも11月27日）のリリース日を示しています。 リリース日を1月22日に延期しても、余計な時間はありません。WCUS（およびそれに至るまでに必要な準備）からWordPress 4.9.9のリリースを整理する必要があり、その後、クリスマスと新年に休暇をとる人々がいます。リリース日を2か月延期することで、さらに2週間の完全な作業が得られる可能性があります。 余分な3か月は多額のように聞こえますが、実際の結果はほとんど得られず、迅速な監査が必要であるため、11月に対処することができます。

@rcemory ：コメントはちょっとオフトピックですが、このディスカッションは、サイトのフロントエンドに表示するために生成されるコンテンツではなく、ブロックエディターインターフェイス自体に関連していることに注意してください。 現在のWordPressと同様に、ブロックエディターで作成されたコンテンツにアクセスできます。 多くの場合、ブロックエディターは適切なaria-*ラベルを追加するのに優れているため、以前よりもアクセスしやすくなっています。WCAGに準拠していない色の組み合わせを使用している場合、または使用している場合に警告が表示されます。見出し要素を間違った順序で配置します。

古典的なエディタプラグインは完全に受け入れられない代替品です。 手始めに、それはサイト全体です。 したがって、サイトがグーテンベルクを使用していて、コンテンツを使って何かをする必要がある場合、ユーザーごとにそれを行うことはできません。また、クラシックエディタープラグインをインストールして作業を行ってからアンインストールすることもできません。グーテンベルクへの復帰が行われると、すべてが正常に動作することを期待します。

このユースケースを提示していただきありがとうございます。これは、ClassicEditorプラグインが現在失敗している良い例です。 ユーザーごとのオプションを追加することはできます。

これは素晴らしいことですが、これは1年以上前に提起された懸念事項であり、これまで対処されていませんでした。 現在の状況では、投稿がGBになると、すべての関連情報を保持したまま、「プレーン」に戻してから再びGBに戻すことはできません。
そのため、GBをオプトアウトする編集者は、GBを使用して作成者が作成したコンテンツを編集するのに苦労するため、ユーザーベースのオプションを使用する計画は現実的ではありません。

@amandarushからのコメントは強力で心からのものです。 そして、WordPress内でアクセシビリティを向上させようとした過去の経験に基づいて、私は知っています。

私がアクセシビリティチームに参加して以来、管理領域で4つの（私が思うに）主要な機能のアップグレードがありました：カスタムメニュービルダー、メディアマネージャー、カスタマイザー、そして現在はグーテンベルク。

当初考えられて構築されたように、これらのコンポーネントはすべて、スクリーンリーダーユーザーと目の見えるキーボードユーザーがほとんど（または完全に）アクセスできませんでした。 私の見解では、これはグラフィックデザインとUXの段階でアクセシビリティがまったく考慮されていないためです。 アクセシビリティチームがファウルを叫んだ後、4つすべてにアクセシビリティの改善が行われましたが、基本的なデザインとUXはほぼ同じままです。

だから私はWordPressが同じ間違いを何度も繰り返しているという彼女の見解を共有します。 そして悲しいことに、「アクセシビリティは私たちにとって本当に重要だ」と聞いたとき、私は彼女の懐疑論を共有します。 それは非常に苛立たしいことであり、私がWPに貢献することがほとんどなくなった理由の1つです。

アクセシビリティの懸念により、11月にWP5.0をリリースするプッシュが停止する可能性は低いようです。もちろん、今年の春にアクセシビリティの「ブロッカー」のリストが最初に作成された後、これは大きな失望です。 そして、WPがWebを民主化することを望んでいること、およびWCAG2.0に準拠していない機能をリリースしないことを約束することはよく言われます。

しかし、WCAG2.1のテストだけでなく、適切なユーザーテストも含む、独立したアクセシビリティレビューは、今やるべき賢明なことだと思います。 少なくともそうすれば、私たち全員が自分の立場を知ることができ、将来のリリースでアクセシビリティの欠陥/問題に優先順位を付けて修正することに適切な焦点を当てることができます。

@pentoからのこれに応えて

ここでReactについて言及していますか？ 私の理解では、Reactで構築されたアプリケーションは、DOMを動的に更新する他のライブラリからも同様にアクセスできます。 aria- *属性を適切に使用する（および予測可能なキーボードフォーカスを確保する）場合は、支援技術で使用できるはずです。 これは正しくありませんか？

はい、それは本当ですが、開発者は、設計、セマンティクス、操作、フォーカス管理、およびARIAの正しい使用においてコンポーネントにアクセスできるようにする方法を理解する必要があります。 悲しいことに、これは私の経験ではめったに起こりません。

Automatticが監査の道をたどる場合、重要なフロー/ユーザージャーニーだけでなく、レビューする一般的なウィジェットも特定する価値があるかもしれません。 これらのウィジェットを単独で識別および監査できる場合は、アクセス可能なパターンライブラリの基礎を形成することもできます。 これらのパターンを使用してより多くの機能が構築されるため、これはアクセシビリティのリスクを軽減するのに役立ちます。

重要なフロー/ユーザージャーニーを特定するだけでなく、確認する一般的なウィジェットも特定する価値があるかもしれません。 これらのウィジェットを単独で識別および監査できる場合は、アクセス可能なパターンライブラリの基礎を形成することもできます。 これらのパターンを使用してより多くの機能が構築されるため、これはアクセシビリティのリスクを軽減するのに役立ちます。

@aardrianこれは、監査に必要となる可能性のある興味深い出発点であり、今すぐ行動に移すことができます。グーテンベルクのユーザージャーニーは見たことがありません。おそらく、これが最も明白な出発点です。上記の監査の範囲を開始します。

@karmatosed @ jwold-グーテンベルクを使用するための上記のフロー/ジャーニーがすでに存在するかどうか知っていますか？ おそらく、ここで説明されている「ウィジェット」または「パターン」のリストですか？

この一般的なスレッドには多くの感情がありますが（そしてグーテンベルクはすべての人が使用でき、準備ができたら出荷する必要があることに同意します）-共通点と次のステップを見つけたいと思います。 会話の場所を、行動を起こす準備ができている場所を特定する場所に移したいと思います。

このユーザーフローは、開発者、テスター、バグハンターが分割して報告するものを探し始めるための監査場所のタスクリストも提供します。

@ postphotos 、 @ aferciaは、 https： //github.com/WordPress/gutenberg/issues/10318#issuecomment-428957684で上記の一連の優れたフローの概要を説明したと思います。

@aardrian同意しました、それは始めるのに最適な場所です！ 👍それを思い出してくれてありがとう。

私の質問はまだ残っています-最初の重要なフローを超えて、ここで行っている作業の検証に役立つ機能に関連するため、ユーザージャーニーにすでに投入されている追加の作業があるかどうかを知りたいと思います。 私たち（このグループ）が@aferciaの初期リストを追加したい、または初期監査を過ぎたシーケンスを追加したい他の項目があるかもしれません。 😄

たとえば、コンテンツ構造機能の呼び出し、元に戻す/やり直しなど、投稿の表示は行っていません。同意する可能性のあるタスクは、ユーザーが使用できるようにするために重要で役立ちます。同意することで、グーテンベルクが作成されます。信じられないほど便利で、アクセスできるはずです。 できれば積極的にコンセンサスを見つけるのは素晴らしいことです。

監査を行うことの追加の利点は、より大きなReactプロジェクトへの貢献です。 Reactには独自のアクセシビリティの問題があり、Gutenbergの監査により、Reactコアに関連し、Reactコアを支援できる問題と解決策の両方が特定される可能性があります。

さて、これはエキサイティングなニュースです： https ：

リージョンとブロックのナビゲーション用のキーボードショートカット、スラッシュコマンド、改善されたARIAランドマークと役割によるフォーカス可能なツールバーとサイドバーの改善、自動化されたエンドツーエンドテストなど。

ICYMI：WPCampus組織は、グーテンベルクのアクセシビリティ監査を組織しています。

RFPを

ただし、ほとんどの人がおそらくよく知っているように、専門的なアクセシビリティ監査は、WPCampusのような小さな非営利団体にとって大きな出費です。

この重要な研究が確実に完了するように、監査に資金を提供するためにあなたの助けを求めています。

イニシアチブの詳細を読み、当社のWebサイトで寄付を行うことができます： https ：

こんにちはレイチェル、

監査への寄付をお願いしているようです。
私が書いたこのスレッドへの私の投稿に何か考えを持っているかどうか疑問に思います
数ヶ月前、このようにアクセシビリティ監査を寄付することを申し出た
資金調達に残っているギャップを完全に解決しますか？
私たちは世界のトップ政府やフォーチュン500に信頼されています
そのようなプロジェクトで！

2018年10月11日に投稿したものは次のとおりです。

==========================

@tofumatthttps ：//github.com/tofumatt私も非常に心配しています
WordPressのアクセシビリティとあなたが成功するのを手伝うことを熱望しています。 私は私たちを持つことができます
組織は、完全なWCAG-EM準拠のアクセシビリティ監査を実行して
技術的および機能的の両方を含む、あなたが好む標準レベル
テスト、*そしてあなたがあなたに合うように*あなたが必要とする仕事のどんな部分でも寄付する
予算。

ATAGとWCAGAAの両方を検討する必要があると思いますが、おそらく
2.0ではなくWCAG2.1。 推奨事項を提供することもできます
あなたが何かを閉じるための最良かつ最も持続可能な方法を選択するのを助けるためのコーチング
ギャップが発見されました。

私たちは便利なことにあなたの開発コミュニティから独立企業間距離にありますが、それでも知っています
WordPressは何年もの間よく。 私はすべてのIAAP認定を保持しており、
何十年にもわたって、WordPressプラットフォームでのそのような監査の両方
民間および公共部門。 で私たちの善意をチェックしてください

davidberman.com/aboutは、私たちが最善の支援を行う方法を決定します。

考え？

• デビッド

2018年11月28日水曜日10:10、レイチェルチェリー[email protected]
書きました：

ICYMI：WPCampus組織は、のアクセシビリティ監査を組織しています。
グーテンベルク。

RFPを終了しました
https://wpcampus.org/2018/10/gutenberg-a11y-audit-rfp/そして今
ベンダーの選択。

しかし、あなたのほとんどがおそらくよく知っているように、専門家
アクセシビリティ監査は、WPCampusのような小さな非営利団体にとって大きな出費です。

監査に資金を提供し、この重要性を確保するためにあなたの助けを求めています
研究が完了しました。

イニシアチブの詳細を読み、当社のWebサイトで寄付を行うことができます。
https://wpcampus.org/2018/11/fundraising-for-wpcampus-gutenberg-accessibility-audit/

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/WordPress/gutenberg/issues/10318#issuecomment-442480511 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABz4pIgVSgZmWJRL2n3Uy-i8Ov7NXnj1ks5uzqdcgaJpZM4XG_WQ
。

-
デビッドバーマン、RGD、FGDC、CPWA
デビッドバーマンコミュニケーションズ| [email protected] | @davidberman
+ 1-613-728-6777 https://dialpad.com/launch?phone=%2B1-613-728-6777 | 340
セルビーアベニュー、オタワK2A 3X6

国連ハイレベルアドバイザー| 招待エキスパート、W3C | Ico-D
サステナビリティチェア| カールトンU.アクセスネットワークチェア

今後の予定：トロント| ニューオーリンズ| モントリオール| ブエノスアイレス| タンパ| テルアビブ
アクセシビリティコース：オンラインで参加www.davidberman.com/next

このメッセージには専有情報が含まれている場合があります。 許可されていない
コンテンツの開示・複製・配布は禁止されています。

@ tofumatt 、11月29日のMattMullenwegの個人ブログでこれを見ました。

最後に、Automatticは、WordPress、Gutenbergのアクセシビリティ調査、およびWeb全体のベストプラクティスの評価に資金を提供し、WordPressが完全にアクセス可能であることを確認し、Web全体の新しい標準を設定します。

Automatticの担当者であるため、Automattic監査が再開されたので、これがWPCampus監査とは別になるのか、それともAutomatticが代わりにWPCampus監査に資金を提供するのかを教えてください。

一方では、WPCampusがクラウドファンディングをしなければならないのを見たくありません。 一方、私は2つの会社からの2つの監査を比較対照するというアイデアが好きです。

マットは彼のブログで

2つ持っていても大丈夫だと思います。資金調達がどのように進んでいるかについてレイチェルに話します。

それに続く人々のために、レイチェルのプロジェクトがWPキャンパス側で、そしてAutomatticが後援するもののためのベンダー選択段階で必要とするものは何でも完全に資金を供給することを約束しました。 後者の目標は、最新のWeb全体で他のブロックエディタースタイルのインターフェイスのアクセシビリティアプローチのベストプラクティスを確認することでもあります。

@m更新していただきありがとうございます。 これが進むのを見るのは非常に励みになり、それがどこにつながるのかを見るのが本当に待ちきれません。 いつの日かWordPressがアクセシビリティの扱い方の例になることを望んでいます。

@m

続く人々のために、レイチェルのプロジェクトがWPキャンパス側で必要とするものは何でも完全に資金を供給することを約束しました

これは素晴らしく、価値があります。 今日、あなたがそれを合計で賄わない理由はありますか？ 関係なく完全に資金が提供されることがわかっているときに寄付を続けるように人々に求めるのは奇妙に思えます。

@aardrianそれは私たちがやっていることの精神ではありません。 これをコミュニティプロジェクトにし、可能であれば、人々や組織が参加してサポートを示す機会を提供したいと考えています。

2018年後半、WPCampusは、Gutenbergとしても知られるWordPressブロックエディターのアクセシビリティ監査を実施するための提案依頼書をリリースしました。 2019年の初めに、監査を実施するために、31,200ドルの費用でTenon、LLCを選択したことを発表しました。

本日、新しいエディターのアクセシビリティに関するTenonのレポートをリリースできることを嬉しく思います。

詳しくはhttps://wpcampus.org/2019/05/gutenberg-audit-results/をご覧ください。

この問題はこれで終わりだと思います🎉🎉🎉🎉🎉

報告されたすべての問題は、このプロジェクトで追跡されます。
https://github.com/WordPress/gutenberg/projects/25

報告されたすべての問題は、このプロジェクトで追跡されます

完全に正しいわけではありません。 WPCampus / Tenonレポートには、GitHubの問題のリストに含まれていない追加の重要な考慮事項が含まれています。 より具体的には、エグゼクティブサマリーとユーザビリティレポートは、グーテンベルクには、小さくて実用的なGitHubの問題では対処できず、代わりにより高いレベルのソリューションを必要とする、より広範な構造的アクセシビリティの問題があることを示しています。

これは、報告されたすべての問題が解決されたとしても、まだ解決すべき重要なアクセシビリティの問題があることを明確にするためです。 これらは通常、エディターの一般的な設計に関連しています。

参考までに、 https：//wpcampus.org/2019/05/gutenberg-audit-results/で公開されている2つのドキュメントをここに添付し

テノンのユーザビリティテストを説明する要約文書
Gutenberg_UX_Report.pdf

エグゼクティブサマリー
Gutenberg_Executive_Summary.pdf

レポートで明らかになったユーザビリティの問題を処理するために、新しい問題、またはプロジェクトを開くことをお勧めします。