ヘイドンピカリングでポッドキャストエピソード4を壊す：包括的コンポーネントとは何ですか？

今日、私はヘイドンピカリングに彼の新しい本、インクルーシブコンポーネントについて話します。 Heydonは、アクセシビリティに関する研究と執筆で知られています。では、「インクルーシブデザイン」とは実際には何を意味し、コンポーネントはどこで機能するのでしょうか。 Heydonは、このエピソードでこれ以上のことを説明しています。 以下で聞くか、ポッドキャストを入手できる場所ならどこでも購読できます。

メモを表示

• SmashingMagazineの本InclusiveComponents
• HeydonのプロジェクトAndyBellによるすべてのレイアウト
• HeydonのウェブサイトHeydonworks
• TwitterのHeydon

トランスクリプト

Drew McLellan：彼はフリーランスのウェブアクセシビリティコンサルタント、インターフェースデザイナー、ライターです。 彼の仕事は、アクセシブルなユーザーエクスペリエンスのデザインと、SmashingMagazineの執筆と編集に焦点を当てています。 彼は、アクセシブルなWebアプリケーションの設計に関する評価の高い本Apps For Allの著者であり、SmashingMagazineを使用してアクセシブルなWebインターフェイスを構築する方法に関する新しい本InclusiveComponentsをリリースしました。 だから彼は明らかにアクセシブルなデザインの専門家ですが、彼がスピードボートでシドニーハーバーブリッジをジャンプした最初の男性の人間であることを知っていましたか？ 私のスマッシングの友達、ヘイドンピカリングを歓迎してください。 こんにちは、ヘイドン。 元気ですか？

ヘイドンピカリング：私は粉砕しています。 私はブランドにいます。

ドリュー：今日は、あなたの新しい本、インクルーシブコンポーネントの主題についてお話ししたいと思います。

ヘイドン：はい。

ドリュー：明らかに2語のタイトルだけですが、それらの単語のそれぞれが多くの重労働をしているように感じます。 最後から、当然のことながら、コンポーネントは、コンポーネントベースの設計のようなものですか？ それは何ですか？

Heydon：そうですね。インターフェースの作成に協力する人々、フロントエンドの開発者、設計者、そしてすべての人が、コンポーネントの観点から物事を考え始め、消化可能で再利用可能なモーゼルに分割してからしばらく経ったと思います。 そして、何らかの理由でその作業方法に慣れていない場合、それは実際には電子部品に少し似ていると思います。 私の父は電子技術者です。 彼は、回路基板やはんだなどのアナログの世界で働いています。

Heydon：実際、彼はいくつかのコンポーネント、非常に小さなコンポーネントを作成しました。これらのコンポーネントは、CERNで電磁石に流れる電流を調整するために使用されています。 そして、彼は私に子供の頃から多くの信頼を寄せていました。なぜなら、彼は私に実際にそれらのためにいくつかのビットをはんだ付けさせたからです。 バッチは廃止されたと思いますので、はんだ付けが不十分で、10代のはんだ付けが不十分で、CERNに関与していることを心配する必要はありません。 しかし、ええ、私はそれが類似していると思います…ああ、そこにはあまりにも多くの類似物があります。

Heydon：アナログ回路基板に似ています。つまり、個々の部品やコンポーネントに対して単一の責任があり、一緒になって回路を作り、回路の場合は電流を増やします。インターフェースまたは結果は、設計システムまたは設計システムを通じて明示されたインターフェースで、どのような方法でも。 つまり、インクルーシブコンポーネントは、さまざまな分野で行っていることを進めると、一般的にアクセシビリティが取り残される傾向があるという事実に対処したかったので、アクセシビリティをもたらしたいと考えました。コンポーネントやモジュール、またはあなたがそれらと呼びたいものを使用して物事を作り、考えるこの種の新しい方法に耐えるためのセンスのある包括的なデザイン。

Heydon：つまり、アイデアは両方ともデザインシステムにアクセシビリティをもたらすことでしたが、同じように、アクセシビリティに取り組むことに関しては体系的に考えてください。 アクセシビリティの観点から、ある種の1つの問題を一箇所で解決し、それが設計システム全体のパターン[inaudible00：03：16]の周りに単純に伝播することを確認することを考えてください。

ドリュー：ある種の実用的な意味で、コンポーネントベースの方法で機能することは実際にはどのように見えますか？ コンポーネントの例は何でしょうか？

Heydon：つまり、コンポーネントの構想とコーディングにはさまざまな方法があります。 私は、概念的なものを過ぎて、コードをどのように編成するかを考えて、その本質的な部分に直接入り込む傾向があります。 私は実際にカスタム要素に多くの焦点を当てるようになりました。カスタム要素ではない場合は、通常の要素ですが、一種の分離されたコンポーネント化された方法でJavaScriptの動作が付加されています。 相互運用可能なコンポーネントのアイデアが本当に好きです。 つまり、さまざまなフレームワークやシステム、アプローチ、技術スタックで使用できるということです。 また、カスタム要素はネイティブであるため、その点で優れています。 それらを1つの場所で定義してから、たとえば、reactアプリケーションで使用したり、viewアプリケーションで使用したり、Angularアプリケーションで使用したり、その他のより大きな状態管理テクノロジーで使用したりできます。を使用します。

Heydon：私にとって、通常、コンポーネントはおそらくカスタム要素になります。 私は最近、アクセシビリティにあまり重点を置いていないプロジェクトに取り組んでいますが、Every Layoutと呼ばれる、可能な限りアクセシビリティを実現しようとしました。これは、非常に特定の種類のアルゴリズムを分離しようとするものです。 CSSレイアウト。 そして、それらはカスタム要素として定義されており、それらは一種の展開を行い、独自のCSSを実行し、より大きなシステム内で一種のプリミティブのように機能します。

ドリュー：つまり、実際には、コンポーネントはフォームフィールドのようなものかもしれないと言っているのですか？

ヘイドン：ええ、それは入力と同じくらい単純なものかもしれません。 たとえば、テキスト入力のように、またはタブインターフェイスのように複雑なものにすることもできます。 したがって、インクルーシブコンポーネントのアイデアは、テキスト入力のように、できれば単一の目的で1つのコンポーネントの概念を採用し、さまざまな種類の人々をつまずかせて回避しようとする可能性のあるさまざまなことをすべて考えることでした。彼ら。 人々を避けないで、問題を避けてください。 人を含めることではなく、人を恣意的に排除しないようにすることです。

Heydon：それは私にとって包括的な設計プロセスにアプローチする最も簡単な方法のようです。何かの潜在的な排他的要素を特定し、それらを回避することです。 したがって、テキスト入力とラベルを使用すると、心配したいことがいくつかあります。 したがって、最初に実際に正しくラベル付けされているかどうかがわかります。 それで、label要素を使用していますか？そのlabel要素はfor属性を使用してテキストフィールドを指しているので、スクリーンリーダーユーザーが入力にフォーカスしたときに実際にラベルがアナウンスされるのを聞くことができるように2つがプログラムで関連付けられていますか？ ですから、それは正しいことの1つです。

Heydon：次に、ある種の視覚的なレベルで、ラベルが別のフィールドではなくそのフィールドに明確に関連付けられていることを確認します。これは、空白などの問題です。 また、ラベルが表示されていないことを確認してください。たとえば、仮想キーボードが起動したときに、ラベルが不明瞭になる可能性があるため、フォーム入力の下にラベルを配置するような凝ったことはしていません。 ですから、そういうことを考えています。

Heydon：入力自体にフォーカススタイルがあることを確認してください。キーボードを使用してフォーカスする場合は、キーボードを使用してナビゲートするかどうかに関係なく、フォーカススタイルからそれが明確であることを確認してください。焦点を当てている入力。 つまり、オートコンプリートのようなものを確認し、それを心配して、オートコンプリートがコンテキストで適切で役立つかどうか、そうでないかどうかを確認します。 そして、これらの多くは障害に直接対処しますが、それらの多くは、使いやすさの点で、そして物事をできるだけ理解できるようにするという点で、ある種より広いものです。

Heydon：非常に多くの場合、すべての人のユーザビリティに対処するものと障害に対処するものの間に、非常に細い線またはぼやけた線があります。 そして、認知障害を特定することをさらに困難にするために。 ですから、認知障害のない人にとって何かがあまり役に立たない場合、それは解決するのがさらに難しくなり、そのような種類の課題を抱えている人のために使うことができるようになります。

ヘイドン：つまり、それらすべてを1か所で考えようとしているだけです。 そして実際、この本は私のものであり、私がそれらのそれぞれに近づいているときの私の思考プロセスです。 そもそもブログとしてやったんです。 そして、各パターンまたは各コンポーネントはブログ投稿であり、テキストは私が行っているだけです。「では、この潜在的な問題に対処しましょう。 どうすればいいですか？ さて、私たちはそれをチェックしました。 そこは大丈夫だと思います。」 そして、それが不可能であるため、これらが完璧であり、すべてを考えてきたと言っているわけではありません。

ドリュー：インターフェースの個々の部分での作業方法にコンポーネントベースのアプローチを採用することで、その特定のアイテムを深く掘り下げて、最良の方法でそれを本当に大幅に最適化したことを確認できます。誰もがアクセスできるようにすることができます。 それを実行し、多くの異なるコンポーネントで実行してから、それらをすべて1つのページにまとめるのは危険ですか？ 一緒にではなく個別にテストしているために、気づかなかった問題が発生する危険性はありますか？

ヘイドン：それは本当に良い点です、そして私はそれを実際に早く提起するつもりでした。 あなたがそう言ってくれてうれしいです。 ですから、多くの点で、哲学的には、物事をこれらの個々のコンポーネントに分離する必要があると判断したと思います。 そして、それを行うことには利点があります。なぜなら、それが分離されていると、一種のテストと一種の単一のものとしての扱いがより簡単になるからです。 そして、あなたは私たちの働き方の観点から、物事を管理しやすくすることができます。 これらのものが最終的に同じスペースを共有し、より大きなシステムに結合する必要があるという事実も考慮する必要があります。

Heydon：実際、私たちの努力と考えは、おかしなことに十分ではないと思います。 エンジニアとしての生活を楽にするために、物事をより細分化して、いつ何に取り組んでいるのかを知ることができると思います。 そして、しかし、私たちはしばしば、これらのものが動的システムに存在し、それらが…でなければならないという事実を無視します。

Heydon：つまり、Every Layoutプロジェクトは、ビジュアルデザインとレイアウトに関するものですが、アルゴリズムで自己管理できるように、これらの小さなCSSプリミティブ、これらの小さなレイアウトプリミティブを作成しようとすることです。 これは、狭い列から取り出して広い列に配置できるようにするためです。コード自体が、並んでいるアイテムの数や、他の方法で再構成する必要があるかどうかを判断します。 常に介入する余裕はなく、自己認識型でインテリジェントなシステムでなければならないのではないかと思います。

ヘイドン：忘れることができることは常にあります。 したがって、タブインターフェイスを作成し、タブの行を作成し、タブを選択すると、タブがタブパネルに対応し、何かが開きます。 次に、誰かがやって来て、「タブインターフェイスをタブインターフェイス内に配置したい場合、または他のコンポーネントをタップインターフェイス内に配置したい場合はどうすればよいですか？」と言うでしょう。

Heydon：もちろん、それが可能かどうかについては部分的に技術的な懸念がありますが、そうです、できる限り柔軟にするかどうかを選択する必要があります。複雑な方法で物事を分類したり、「コードの複雑さのレベルが高すぎる可能性があるため、ここに何かを入れることはできませんが、おそらくユーザーが物をどのように認識して使用できるか。」 私はすべて、「複雑な機能を大量に内部にネストしないでください」というルールを作成することに専念しています。なぜなら、人々が実際に頭を悩ませることはほとんどないからです。

ドリュー：アクセシビリティの設計に完全にアルゴリズム的または自動化されたアプローチを取ることは可能ですか？

ヘイドン：そうは思わない。 いいえ。自動化されたツールがあります。自動化されたツールを軽蔑したくありません。 とても便利だと思いますが、早めの警報システムのように使って、問題のあるところがどこにあるのかを感じさせてもらいます。 したがって、製品をよりアクセスしやすくする方法についてアドバイスを求めている組織の監査を行っていた場合。 したがって、問題のある領域がある場合は、一種の資金調達の良い方法ですが、つまり、技術的に100％アクセス可能なインターフェイスを使用できます。おそらく、いくつかのツールによれば、WCAGに対してそれを判断するための優れたツールですらあります。 、Webコンテンツアクセシビリティガイドライン、またはその他の受け入れ仕様。 また、チェックされているすべてのボックスが100％ソートされている場合でも、さまざまな理由で完全に使用できなくなる可能性があります。

Heydon：たとえば、前に言ったことに戻ると、それは完全に複雑すぎる可能性があります。 リンクで誰かを圧倒することができ、彼らがそれを通り抜けることができる方法はありません。それは、非常に暗黙のことであり、特定するのが難しいことですが、それは単に人々を疎外することになります。 しかし、誤検知などを簡単に取得できることもあります。 先日何かあった、先日言った、先月、私は組織で働いていた、そしてもちろん彼らは100％アクセシビリティの灯台学校を望んでいた、そしてそこに動的にドロップされたiframeがあった分析スクリプトか何かによって。 あなたはそれがある種の少し粗雑なコードであるようなものを知っています、それはちょうどそのようないくつかのタスクを行うためにページにチャックされているようなものです。

Heydon：分析をまったく使用しないことをお勧めします。また、人々がオプトアウトできるように、少なくとも追跡禁止プロトコルをサポートすることをお勧めします。 残念ながら、そのプロトコルは一種であり、実際には適切にサポートされていなかったため、実際には機能しなくなりました。 しかし、このiframeには、タイトルがないと言っていました。 つまり、iframeを使用している場合は、タイトル属性を指定する必要があります。これは、スクリーンリーダーユーザーにとってiframeの目的を識別するための長年にわたる最良の方法だからです。 しかし、これも何も表示しないように設定されたiframeでした。したがって、スクリーンリーダーで視覚的に物事を隠すのと同じように、何も表示しないため、そもそもスクリーンリーダーには認識されませんでした。インターフェースなので、遭遇したり発表されたりすることはありません。

ヘイドン：それは誤検知でした。 つまり、そもそも認識されないiframeを特定するように求められていたのです。 したがって、自動テストでは常にこの種のエラーや問題が発生します。 しかし、最終的には、それはプログラマーが関与しているとは思わないようなものであり、少し厄介だと思うことですが、それは人間の行動と人々が物事をどのように理解するか、そしてそれは、ある種のバイナリの種類、またはブール型の種類のルールを持っているだけでは非常に難しいことです。

Heydon：つまり、私が以前にこれについて相談していたときに開発者に話しかけたところ、彼らは次のように言い続けました。 ただ、それなら私たちは前進することができます。」 そして私は言いました ｢あなたはまだ手動でテストしなければなりませんキーボードによるインターフェースの使用が何らかの形で不可能かどうかを実際に判断できる自動テストはありません。」 あなたが探すことができるある種の個別のものがありますが、全体的な経験はまだ人間によって判断される必要があるものです。 うん。

ドリュー：自動化されたツールの危険性は、アイテムを個別に見たり、1つのインターフェースを個別に見たりして、より広いコンテキストを見ないことです。

ヘイドン：はい。

ドリュー：確かに、パフォーマンス監査に灯台を使用することで、開発者として含めることを決定することがあります。その1ページで使用されるCSSよりもはるかに多くのCSSが存在する可能性があり、厳密に言えば、CSSをダウンロードしすぎていますが、実際には、そのファイルがロードされると、ユーザーが次のページを参照するまでに、CSSを既に取得していることを私は知っています。 したがって、これは複数のページにわたって行われている最適化であり、ツールは1つのページを個別に見て、エラーと見なします。

ヘイドン：はい、もちろんです。 あなたは先を考えて判断を下しているのですが、高度なAIに到達してそれを予測するまでは、そうです、人間がそれを見て、それを通り抜けて進む必要があります…つまり、自動テストを行う必要があります私が言うように、一種の早期警告システム、診断システムを導入する必要がありますが、組織が本当に思いやりがあり、物事をより包括的でアクセスしやすいものにすることに関心がある場合は、トレーニングも必要です。 。 Q＆Aが必要です。

Heydon：ですから、「キーボードを使ってこのコンポーネントを操作するときの動作は次のようになります」、または「スクリーンリーダーを操作するときに実際にステップスルーしない場合の動作は、このようになります」というスクリプトを作成します。それ。 したがって、これを行うと、これが発生するはずです。 これを行うと、これが発生するはずです。 これを行うと、これが表示されるはずです」またはそのようなもの。 ですから、あなたが言うように、自動化されたツールはそれを認識していません。 彼らはただ「ああ、これには代替テキストがここにない」と見るだけです。 そして実際には、多くの場合、代替テキストを含めるべきではないかもしれません。 また、代替テキストをうまく書いたかどうかを判断することもできません。 したがって、すべての代替テキストがない画像は、誤解を招くような、または単に悪い代替テキストがある画像よりもおそらく優れていると思います。 そして、それはまた判断の呼びかけですよね？

Drew：歴史的に、アクセス可能な方法で物事を構築する際に苦労してきたことの1つは、ベストプラクティスに関する知識を最新の状態に保つことです。これは、ドキュメントやあらゆる種類の推奨事項を参照するたびに、それが私がやっていたことのようで、私は正しいことをしていると思っていました。推奨事項は進んでおり、今は別のことをしているはずです。 そして、それはWebでの作業のすべての分野でおなじみの話です。 しかし、もちろん、アクセシビリティの問題があると危険だと思います。ベストプラクティスに従わない場合、現在は適切ではないものをインターフェイスに残しておくと、ユーザーに悪影響を与える可能性があります。仕方。 インターフェイスまたはサイトを構築するためのコンポーネントベースのアプローチは、何らかの形でそれを助けますか？

Heydon：純粋に、1つのコンポーネントがあるので、アクセシビリティだけでなく、すべての場合において、このコンポーネントを1つの場所で定義し、それを別の場所で使用するという考え方だと思います。場所、少なくともアスペクトやブラウザのサポートなどが変更され、コンポーネントを更新したい場合は、1つの場所でそれを実行するだけで、使用する場所に関係なく、その機能強化または変更が感じられます。 その点で、物事をコンポーネントに分割する方が確かに便利だと思います。

Heydon：でも、そうですね、私が言っているように、それはアクセシビリティに影響を与えるだけでなく、変化するものすべてに影響を与える可能性があります。 しかし、実際には、その変更がどれだけあるかはわかりません…つまり、HTMLアクセシビリティの種類に関しては、明らかに非常に狭い領域であるという点で、重大な変更はほとんどありません。 しかし、コードの品質やコードの動作の観点から、物事はHTML仕様に導入されます。明らかに、非常にゆっくりで、それほど遅くはありませんが、ARIA仕様にもかなりゆっくりと導入されます。 そして、ARIAの多くは、とにかく基礎となるベースラインHTMLの内容を反映しているだけです。

Heydon：テクノロジーよりも、これらのことに対する認識と理解は時間とともに変化する傾向があると思います。 つまり、最近のWebAIM調査では、ARIAを使用しているサイトは、使用していないサイトよりもアクセスしにくいことがわかりました。 したがって、人々がWebサイトをよりアクセスしやすくするために特別に考案されたこのテクノロジーは、それをさらに悪化させていました。 つまり、それは実際には単なる知識のギャップであり、テクノロジーのギャップやテクノロジーの欠点ではありません。 残念ながら、テクノロジーがどのように機能するのかを実際に理解していなかったため、テクノロジーを利用して誤用しているだけの人々です。 うまくいけば、私の執筆のいくつかはそれを助けることができるかもしれません。 とにかく、いくつかの地域では。

ドリュー：しかし、ある種の適切に構造化されたコンポーネントベースのシステムを使用すると、何かが古くなっていることに気付いたり、下手な決定を下したりして、よくわかった場合に、より簡単にアクセスして修正できるようになります。アプリケーション全体。

ヘイドン：そうだね。 ええ、ええ、絶対に。 つまり、効率がすべてですよね？ そして、この乾いた原則、またはあなたが持っているもの、そしてそれが、私がこの機会に元々非常に興奮していた理由だと思います。 ですから、こう言う機会のようなものでした。 作成しているその1つのコンポーネントのアクセシビリティをそこに入れれば、時折の仕様の変更や更新、または何を持っているかを除けば、アクセシビリティについて心配する必要はありません。」

Heydon：または、おそらくほとんどの場合、反復は単にユーザーのフィードバックと進行中の調査に基づいて行われることを意味します。明らかに、可能な限り、多様な人々のグループと協力する必要があります。 したがって、さまざまなデバイスを使用し、さまざまなブラウジングの習慣を持ち、さまざまな支援技術などを使用する人々を獲得する必要があります。 そして、あなたが知っている、物事は常に浮かび上がるはずです。 私は実際にコンポーネントを特定し、それが本当に堅実であると思います。それから少し調べてみると、かなり悪い仮定をしていることがわかりました。 しかし、ええ、コンポーネントシステムを使用すると、1か所で修正するだけで済みます。

ドリュー：コンポーネントは完全に包括的である可能性がありますか、それとも包括性に向けてこれまで以上に取り組んでいるスペクトルですか？

Heydon：ええ、たとえばWCACエラーがないという点で、コンポーネントがすべてのWCAC基準を満たしている可能性はありますが、私が言ったように、それはあなたをここまでしか連れて行かず、それでも完全に使用できないか、それらの技術的基準を満たしても理解することは不可能です。 そうそう、これは私がよく話すことです。 私は、アクセシビリティは他のデザイン分野と同じであり、デザインプロセスの一部にすぎず、完全にアクセスできるものがないのと同じように、完全にデザインできるものはないことを人々に納得させようとしています。 残念ながら、多くの人がスクリーンリーダーとの互換性を確認するという観点から考えていると思います。これは、アクセシビリティと一般的な包含の点で明らかに非常に狭い範囲です。

Heydon：では、Paciello Groupのように、私が一緒に仕事をした善良な人々の中には、「実際、私はアクセシブルなUXパーソンとして知られていたい」と言う人がいるでしょう。 つまり、このボックスティックの演習だけでなく、実際に、より多くの人々にとってエクスペリエンスをより良く、より価値のあるものにし、より広範な原則やバイナリではないものに移行しようとすることです。 しかし、最終的にはそれだけであり、WCACやその他のそのような基準では、「これは間違っている」という本当のハードで高速なものしか識別できないと思います。

Drew：それで、私が開発者である場合、コンポーネントの設計、計画、および構築の方法にアプローチするときに、別の方法で何をすべきでしょうか？ そのコンポーネントが可能な限り包括的になることを確実にするために、私の仕事で考慮すべきことはありますか？

Heydon：つまり、構築しているものに応じて、満たす必要のあるさまざまな基準が存在するということです。 したがって、たとえば、すべてのコンポーネントが代替テキストを含むアクセシブルな画像を持っているわけではありません。これは、画像をまったく使用しない可能性があるためです。 それは単にテキストベースか、あなたが持っているものかもしれません。 一部はインタラクティブではない可能性があります。 したがって、特定の要件に関しては、コンポーネント間で変化しますが、うまくいけば、私の執筆の一部と包括的コンポーネントの本があなたに役立つことは、包括的に考えるという規律に陥るか、または採用することです。

Heydon：それで、あなたがこのようなことに取り組んでいるとき、考えているだけでなく、基本的には、「それが私のために働くなら、それはおそらく他のすべての人のために働く」という考え方から抜け出すだけです。あなたや私が物事を閲覧する方法、つまり、私たちはおそらく完全に異なることをするでしょう、私たち2人だけですよね？

ドリュー：そうだね。

Heydon：そして私たちは第一言語の人々として西洋人、白人、英語です。 つまり、これを消費する人々の多様性の量です。つまり、パフォーマンスの人々は常にこれについても話します。つまり、より良いパフォーマンスを提唱することに関心のある人々です。 あなたは優れたネットワーク上で設定されたハイスペックを使用することに慣れており、多くのユーザーまたは多くの潜在的なユーザーは確かにそうではなく、アクセシビリティと同じです。 それは、基本的に、自分自身について考えることから抜け出すことの問題です。 文字通りそれだけです。 そして、明らかに、あなたの直接の同僚やあなたの同じ社会集団の人々だけでなく、手を差し伸べようとしています。

Heydon：うまくいけば、それは本当に「これが私がこの問題のために解決したこと」であり、その時に私が考えていたことです。 それらのアイデアのいくつかを再利用して、私が適用したものを正確に適用することができます。 うまくいけば、この本は、「包括的に考えようとする人の事例研究です。 ほら、彼らが考えていたようなものです。まったく異なるものを設計するときは、おそらく同じ種類の考え方を採用して、ユーザーの多様性と彼らが物事をどのように進めるかについて心を開いてみてください。」

ドリュー：それで、本自体、どのようにそれを構成するかを決めましたか？ 私が本で好きなように、それは非常に非常に実用的であるように見えますが、どのようにそれを構成しましたか？

Heydon：前の本と非常によく似ていて、実際にはインクルーシブデザインパターンでした。その本は、ある種の抽象的な基準で整理しようとしたため、そもそも多くの問題を抱えていました。 それで、私はキーボードのアクセシビリティに関する章を始めましたが、それは非常に困難でした。なぜなら、異なるタイプのキーボードのアクセシビリティやあなたが考えなければならないことについて話すたびに、私はある種のことをしなければならなかったからです。ある種のコンポーネントを想起させ、そのコンポーネントを捨てて、別のコンポーネントに移動する必要がありました。

Heydon：それで、コンポーネント自体の観点から物事を整理する方が理にかなっています。 つまり、インクルーシブデザインパターンはこれを実行し、インクルーシブコンポーネントは実際には単なる継続であり、さまざまなコンポーネントをカバーするだけです。 それは、機能の点で、以前の本ではあまりしなかったライブコードの例なども含まれているため、少し異なります。 しかし、ええ、それは文字通り「このコンポーネントを実行します」であり、タップインターフェイス、折りたたみ可能なセクション、テーマスイッチャー、通知フラッシュカード、トースターなど、それらが呼ばれるものすべてです。次に、そのコンポーネントを中心に編成されます。

ヘイドン：それは、「これが私たちがしていることであり、より包括的にするために私たちがそれをしている間に考慮すべきことです」ということです。 そして、私がそのようにそれを始めたとたんに、それは私が働いている間、本当に私が働いて、メモを書いているだけでした。 それで、そのようなものはそれ自体を書きました、そしてそれからすべての努力は実際に私がそれらのものにアクセスできないようにするというまともな仕事をしていることを確認することだけでした、と私は推測します。

ドリュー：はい、目次は実際にはほとんどドキュメントのように、またはセルフヘルプマニュアルのように読めます。 第1章でまっすぐに、ボタンを切り替えます。 いくつかのトグルボタンを実装したい場合は、この章に移動して読んでください。そうすれば、その方法について知っておく必要のあるすべての情報が得られます。これは、私が本当に気に入っているアプローチです。 折りたたみ可能なセクション、タブ付きのインターフェイス、テーマスイッチ、データテーブル、私たち全員が毎日構築している実際の実際の実用的なものの負荷などが表示されます。おそらく、私たち全員がより良く構築できると思います。

Heydon：ええ、それは完全にアイデアでした。なぜなら、それは私がコンポーネントを作成することだけではなく、ケースであり、そこで触れてくれたからです。私たち全員が使用するパターン。 つまり、タブインターフェイスはいたるところにあり、それらはすべて異なる方法で実装されており、さまざまな方法で非常にひどく実装されています。 つまり、私はひどいタブインターフェイスを実装し、それらが人々にとってどれほど悪いかについて少し学び、それからそれらを少し良く、少し良く、そして少し良くしようとしました。 私はおそらく私の時代に15または16の異なるバージョンのタブインターフェイスを作成し、この種のことを何年も行ってきました。

Heydon：そして、あなたが知っているように、彼らは、うまくいけば、毎回少し良くなっています。 しかし、それは一般的なことです。 異なるWebサイト間で頻繁に使用することはよくあることで、私は使用し、誰もが使用します。 ですから、アイデアの一部は、「実際には、Web用のアクセシブルなデザインシステムのようなデザインシステムをやってみましょう」と言うことでした。 今、人々は枝分かれし、これらのことの独自のバージョンを実行するつもりですが、コアのものをダウンさせるために、アクセシビリティは物事にあるべきコアなものです。 アドオンであってはならず、どちらかまたは両方であってはならず、機能であってはなりません。 それは核心的なものでなければなりません。 そして、もしあなたがその核となるものを組み合わせれば、そうです、うまくいけば、人々は章を見て、「ああ、わかりました、私はそれらを作りました。 私はそれらを見てきました。 可能な限り包括的にそれを行う方法を見てみましょう。」そして、うまくいけば、彼らはそれから何らかの価値を得るでしょう。

Drew：ええと、私が気に入っているのは、確かに、過去に実装する必要のあるいくつかのインターフェイス機能があり、アクセシビリティの観点からは注意が必要であることを知っています。 、ある種のフライアウトメニュー、ドロップダウンメニューなどを言います。 「さて、ここにアクセシビリティの観点からドラゴンがいます。 私はこれを正しく行うようにする必要があります。」 それで、私はそれを行う方法についてグーグルで検索し、「この方法を使用してください」と言っている評判の良い情報源を見つけました。私はその方法を使用し、それを実装して次に進みますが、実際には何も学びませんでした。 なぜ解決策がそれだったのか私は知りませんでした。 そして、あなたが本の中でそれに入る方法について私が本当に好きなのは、私が一度に2つのことをすることができるということです。 私はそれをどのように行うべきかを理解することができ、それがすべて非常に注意深く説明されているので、なぜ私がそのようにそれを行うべきかを理解することができます。 ですから、そういう意味では本当に成功していると思います。

ヘイドン：ああ、すごい。 それが私が目指していたものでした。 いいですね。 しかし、ええ、それは私のことのようです。 I mean, I've been working with the BBC for some months and we've kind of made a thing a bit like Inclusive Components but for the BBC, so we've done this sort of technical implementation with a through the lens of accessibility version of their design language called GEL. And yeah, it explains the why as well as the how and it's not a pattern, really. The idea is that the individual departments at the BBC, because there's so many of them, because it's such a large organization, so there'll be BBC Sport, BBC Weather, BBC News, they're the ones who would be taking care of the kind of technical stack and making their pattern library. And what we've really provided is just, we've just tried to exemplify the best practices. So it was really much more of a learning resource than a simple plug and play pattern library. うん。

Drew: Was it difficult deciding what patterns to include in the book? Was there anything that you left out?

Heydon: The only ones I really had problems with or second thoughts about were the ones where, the tab interface, for instance, I wasn't going to include, because I really hate tab interfaces, but then I had folks saying, “Could you please do a tab interface? Could you include a chapter of that?” Because I get asked to put them in my interface all the time by clients or whoever. So, I ended up doing one. But it's full of caveats. And the main caveat is, probably don't use a tab interface. Use maybe an accordion, it's a simpler interaction paradigm. It's easier to make responsive, it's easier to make compatible with screen readers, et cetera, et cetera.

Heydon: So I put all those caveats in. But yeah, and some of them were ones where I just thought, “Oh, I haven't written about this before and I could do with having sort of thought about it so that I could actually use it in my design work.” And others were people requesting, saying, “I know this is a gnarly one, I just don't know how to go about it. Could you give it a go?” And so I gave it a go as best as I could. That is going to be the last time I write a book about accessibility because I've done three now.

Heydon: So if anyone wants to know any more and if they think of any other components that they might want doing, just DM me on Twitter or something and I'll try and deal with it in that way rather than writing a whole article, because those articles are quite long and they take up quite a lot of time and I'm kind of doing other things at the moment. But I'm always happy to chat with anyone who has any questions about this stuff. They might be working on something similar to what I've covered and there was just something that they were unsure about or which I, for whatever reason, I hadn't made as clear as they'd liked it. Yeah, then just contact me because I'm always happy to talk about the stuff because it helps me to sort of ruminate over things and try to, it might challenge my assumptions and help me to do a better job as well.

Drew: So, the book, Inclusive Components, is available right now from Smashing Magazine, smashingmagazine.com/books, and I'd recommend everybody check it out.

Heydon: Thank you.

Drew: So I always like to ask people, I mean, Smashing is all about learning, right, with the books, the conferences, the magazine, we're all about learning. What is it that you've been learning lately?

Heydon: So, recently, well, a couple of years ago I made something, I made a drum machine using the web audio API called Beads and it's still available as a PWA, it's a progressive web app. If you Google search Beads GitHub or something like that, you should get the GitHub page which has it on there. But that was a alpha version and I'm now working on doing a much more advanced version of this. And it's a different kind of drum machine because it's polymetric, it has different, you can have different tracks of different lengths. So you can have a track which has seven beats and a track which has nine beats, a track which has four beats. And then, the rhythm evolves over time because of the changing syncopation. You've got these, it's multi-threaded.

Heydon: That was the main reason that I wanted to build it, because, as someone who's interested in kind of experimental music, that's something I wanted to play with. Obviously, I'm trying to make this drum machine as accessible as possible. And that's been interesting from the point of view now that I'm working with, I'm turning it into an Electron app. So, for those of you that know Electron allows you to kind of wrap a sandbox version of Chromium browser and create a desktop application but using web technology, which was really great because it makes things, for this projects anyways, because it gets around a lot of performance problems.

Heydon: But also, although I've been doing cross browser testing for 12 years now, it's really nice to have a break and just to design stuff for one browser. And it's got some, so there's a flag in Chromium. It's a, what's it called, an experimental web platform feature for focus visible. So I've been able to make this drum machine completely keyboard accessible with these really nice, big focus outlines without those appearing for mouse users, because focus visible uses this heuristic where it detects whether or not you're using a keyboard. So that's been nice, to be able to incorporate that.

Heydon: But the thing recently that I've been learning about, just I've, I guess, been learning about some of the more advanced things you can do with the web audio API itself. So I had this problem where I have, you can put multiple sounds on one track so you can load in an array of audio files and it places them one after the other, and by default they overlap, so they'll always play out out, the audio buffer will play until it finishes. So if the next sounds comes before the end of that, it just overlaps, which is fine. It's kind of like a reverb or something. But sometimes if you're doing an arpeggio, like a baseline or something, you don't want them to open up. That's not how a bass guitar works, right? If you're on the same string, you press the next note, the first one has to finish.

Heydon: So, I was stopping a note as the next one started and there was always an audible popping sound and it's not the web audio API having a problem or anything like that. It's just the human ear will hear a kind of a nasty popping sound where you kind of sever away from. You just cut it, stop it dead, it's going to sound nasty. And then, so I found that there's a function as part of the web audio API, which allows you to choose a point where you can taper off the sound. And so I was able to detect where the sounds should end because the other sound is beginning, then taper it off very quickly, but it is a taper, like a fade out, rather than a hard cut off thing.

Heydon: So I solved that problem after it annoying me for ages. So it's basically been web audio API stuff and messing around with sounds because I've always been into, as I say, into experimental music and messing about with that sort of stuff. And I'm trying to write a talk about this. And in the talk, I'm using Billy Jean by Michael Jackson because it's a very straight, fall to the floor rhythm and I'm going to kind of warp it in various different ways. So I've actually had to learn the parts for Billy Jean to kind of sequence that and stuff. So, weirdly enough, that was what I was doing before doing this podcast.

Drew: That sounds like a lot of fun. So if you, dear listener, would like to learn more about Heydon or hire him to consult on your projects, you can follow him on Twitter, where he's @heydonworks, or visit his website at heydonworks.com. Thanks for joining us, Heydon. Do you have any parting words?

Heydon: Goodbye.