2021年6月15日
アクセシブルなフロントエンドコンポーネントの完全ガイド - 後編
本記事は、原著者の許諾のもとに翻訳・掲載しております。
目次
- icon links
- inputs
- keyboard navigation
- navigation menu
- modals
- prefers-reduced-*
- “skip” links
- SVGs
- tabs
- tables
- toggle switches
- tools
- tooltips
- video/audio players
アクセシブルなインプット
2019年、WebAIMは上位100万件のWebサイトのアクセシビリティを分析し、エラーがないページの推定割合は1%未満というショッキングな結論に到達しました。アシスティブテクノロジー（支援技術）に頼っている人にとってインクルーシブで使いやすいサイトを作成するには、セマンティックHTMLの基礎を正しく理解する必要があります。Oscar Braunertのインクルーシブなインプットに関する記事は、彼の「小さく始めて共有・協力する」という信条に基づいており、セマンティックHTMLを理解するための優れた出発点となります。
インクルーシブなインプット（プレビューを拡大）
この記事では、WAI、ARIA、WCAGの基礎から始めて、インプットをよりアクセシブルにするための方法を探求しています。記事で紹介されているTipsは、ユーザインタフェースを変更せずに実装することができます。Oscarが述べるように「もし疑問があったら、まずはやってみましょう。一部のユーザを除いて誰も気づきません。そして、気づいたユーザはあなたに感謝するはずです」。
アクセシブルなアプリ全体のキーボードナビゲーション
よく考え抜かれたコンセプトのキーボードナビゲーションは、あらゆる人にとってプラスになります。マウスをうまく使用できない人にとっては操作が可能になり、スクリーンリーダのユーザはアプリケーションとのインタラクションがしやすくなり、パワーユーザは可能な限り効率的に業務を進めるためのより多くのショートカットを利用できるからです。通常、キーボード対応は特定のショートカットに限られていますが、Discordのチームは同社のアプリケーションを一歩先に進め、キーボード対応をあらゆる機能へと拡大することを決断しました。
Discordがアプリ全体のキーボードナビゲーションをどのように実装したか（プレビューを拡大）
「How Discord Implemented App-Wide Keyboard Navigation」というケーススタディは、Discordのチームがこの課題にどのように取り組んだか、そして当然ながらチームがその過程で直面した課題についても、貴重な知見を共有しています。この取り組みで特に困難だったのは、ページ内のフォーカスの場所を一貫した方法で表示することでした。フォーカスリングのための既存のソリューションは機能しなかったため、チームは独自のソリューションを一からビルドしなければなりませんでした。チームはこのコードをオープンソースとして公開しています。あなたが同様の課題に直面しているなら、ぴったりの解決策になるでしょう。
アクセシブルなタップ/クリックメニュー
巨大なドロップダウンメニューをマウスオーバーで表示するデザインは、今も良いデザインと言えるでしょうか。恐らく言えないでしょう。マウスオーバーメニューは一貫性がなく、分かりにくいうえ、当然ながらモバイルデバイスには別のソリューションが必要なため、ユーザビリティとアクセシビリティに関する大きな課題があります。実際Mark Root-Wileyは、そろそろマウスオーバーメニューを止めて、明確でアクセシブルなクリックメニューに変えるべきだと提案しています。
（プレビューを拡大）
Markは自身の記事で、アクセシブルなクリックメニューをビルドする詳細な方法と、自らのリサーチに基づく有用な指針と参考資料を紹介しています。基本的な考え方は、まずはメニューをCSSオンリーのマウスオーバーメニューとしてビルドし、li:hover > ulとli:focus-within > ulを使用してサブメニューを表示するようにします。次にJavaScriptを使用して<button>エレメントを作成し、aria属性を設定し、イベントハンドラを追加します。最終的な結果は、CodePen上のコード例とGitHubリポジトリとして提供されています。これはあなたのメニューにとって良い出発点になるでしょう。
アクセシブルなモーダル
あなたは顧客の入力内容を確認するため、またはギャラリーでいくつかの写真を表示するため、あるいは単にユーザ設定を確認するために、ページ上にシンプルなモーダルやオーバーレイを設置しているかもしれません。これらのケースのすべてで、アクセシブルなモーダルのビルドは大きな冒険となります。これはフォーカストラップ※としても知られています。
※訳注: キーボードを用いたフォーカスの移動を自由に行えないようにすること。キーボードトラップとも呼ばれる。
Eric Baileyが詳細に説明しているように、フォーカストラップの対象となるコンテンツの境界（モーダル内でフォーカス対象となる最初と最後のアイテムなど）を特定し、（モーダルの出現中は）その範囲外にある要素は全てフォーカスの対象から削除し、ユーザーのフォーカスをトラップ対象であるモーダルの中に移動させます。モーダルを閉じる際はそのイベントをリッスンし、モーダルを出現させるトリガーとなったインタラクティブな要素にフォーカスの位置を戻す必要があります。
アクセシブルなモーダルのビルドは簡単ではありません。Eric Baileyはその仕組みを詳しく説明しています（プレビューを拡大）
理想的にはHTMLのdialogエレメントくらいシンプルなものを使用したいのですが、残念ながらアクセシビリティに非常に大きな問題があります。Shadow DOMでも、フォーカスを管理するのは容易ではありません。inert属性を使用すれば、インタラクティブなエレメントを発見・フォーカスすることを不可能にしたり、その後に再び可能にしたりすることができます。比較的古いブラウザにはGoogle ChromeやWICGのinertポリフィルを使用することが可能です。
- Scott O’Haraのaccessible-modal-windowは、信頼性の高い完全にアクセシブルなスクリプトとして使用できます。
- Kitty Giraudelは間もなくa11y-dialog Nextをリリースする予定です。これは軽量（1.6 KB）なスクリプトで、フォーカスをトラップ・復元すること、
aria–*属性を切り替えること、ダイアログをオーバーレイ上のクリックとEscapeキーで閉じることが可能です。ただし、前バージョン（6.1.0）は依然として実装サポートがない<dialog>に依拠しており、アクセシビリティ上の問題が残っているため、本バージョンと前バージョンを混同しないことが重要です。 - Parvusを利用するのもよいでしょう。これはシンプルでアクセシブルなオープンソースの画像ライトボックスで、外部との依存関係がありません。よくあるケースとして、画像を同じ画像のより大きなバージョンにリンクすることがあります。Parvusでは、画像を取り巻くリンクに
.lightboxクラスを追加するだけで、スクリプトが他の仕事をすべて自動的にこなしてくれます。
prefers-reduced-*でユーザ設定をサポート
ユーザーは様々です。アニメーションを好むユーザもいれば、医学的な問題から（コンテンツの）モーションを負担に感じるユーザもいます。prefers-reduced-motionメディアクエリは、アニメーションのオンとオフを切り替えることを可能にするものですが、他にもユーザ設定に応じてアニメーションを管理するためのソリューションは数多く存在します。Elijah Manorは、ブログの記事で@media、matchMedia、カスタマイズしたReactフックなど、CSS、SVG SMIL、JavaScriptのアニメーションを管理するさまざまなテクニックを紹介しています。
prefers-reduced-motionメディアクエリを使用して、CSSとJavaScriptのアニメーションを切り替える（プレビューを拡大）
コンテンツを誰にでもアクセシブルなものにするための他のprefers-reduced-*メディアクエリとしては、prefers-reduced-dataが挙げられます。このメディアクエリは、ブラウザではまだサポートされていませんが（PolypaneとChromiumブラウザでエミュレートすることは可能）、それでも知っておく価値があります。prefers-reduced-dataは、ユーザが可能な限り小さなデータを使用したいと考えていること（例えば接続が遅い場合やデータが限られている場合など）を示します。
- Tatiana Macは「Taking a no-motion-first approach to animations」という記事で極めて詳細な説明をしており、すべてのアニメーション固有のスタイルをアニメーション固有のスタイルシートに配置することや、訪問者が「モーションを減らす」を選択しなかった場合のみこれらのスタイルを機能させることを提案しています。
- Kitty Giraudelは「Implementing a reduced-motion mode」という記事で銀行機能のUIを例として指針を提供しており、コード例も紹介しています。
- Polypaneチームは、今のうちに将来に備えてサイトを整えるために、メディアクエリについて知る必要があることをまとめています。
アクセシブルな「スキップ」リンク
特に大量のナビゲーションがあるページでは、セクション間やページ内を移動するのが面倒でイライラすることがあります。このような場合、「スキップ」リンクは非常に便利です。しかし残念ながら、「スキップ」リンクが実装されているにもかかわらず、display: noneによって非表示になっており、そのため（スクリーンリーダやキーボードのユーザなど）誰も利用できないことが少なくありません。
（プレビューを拡大）
Paul Ryanは「How To Create a “Skip content” Link」という記事で、コンテンツをスキップするためのアクセシブルなリンクを実装する方法を順番に説明しています。基本的には、CSSのtransformによってスキップリンクを画面外に押し出した後に、:focusで画面上に再び戻すという方法を使用します。この記事のコメントで、Eric Baileyは、大量のインタラクティブなアイテムや読み進むのが困難なアイテム（目次やiframeなど）を含むコンテンツのセクションの前にスキップリンクを設置することも可能だと指摘しています。
アクセシブルなSVG
SVGと言えば、現在のSVGにできることは、昨年のような基本的な図形の描画からはるかに進化しています。SVGアイコンを描画するだけでなく、スタイルやアニメーションを設定することができるのです。もし真のインクルーシブネスがパターンの先にあるなら、アクセシブルなSVGのデザインと開発に当たって他にどんな要素を考慮すべきでしょうか。
Carie Fisherの「Accessible SVGs: Inclusiveness Beyond Patterns」という記事は、まさにこの問いに対する回答となっています。Carieはこの記事で、SVGの配色とコントラスト、ライトモードとダークモード、SVGアニメーション、モーションの削減、アクセシビリティに重点を置いた多くのツールについて詳しく検討しています。記事にはデモとコード例に加え、詳細な説明や参考資料の紹介もあります。
（プレビューを拡大）
SVG関連に限らず、アクセシブルなコンポーネントの複雑な世界について深く知りたいなら、当サイトが最近掲載したばかりのアクセシブルなコードパターンに関するCarieの記事をご覧ください。
アクセシブルなタブ
あなたのサイトのインタフェースではタブパネルを使っているかもしれません。しかし、これらのタブの内容を、キーボードやスクリーンリーダのユーザにとって常にアクセシブルに維持するには、視覚的なデザインやARIAのセマンティクスの提示について非常に慎重に考える必要があります。Heydon Pickeringは「Tabbed Interfaces」という記事で、キーボードの挙動とフォーカス管理を考慮した最適なソリューションを解明することを目指し、詳細な検討を行っています。彼はセクションを段階的にタブパネルへ展開することを（コード例付きで）提案しています（このTipsを教えてくれたDaniela Kubeschに感謝します）。
ユーザが矢印キーで新たなタブを表示するか、あるいはタブキーを押してタブパネルに入り、リンクにフォーカスするかを選べることを示した図（プレビューを拡大）
Adam Silverが書いているとおり、あまりITに詳しくないスクリーンリーダのユーザは、タブを切り替えるのに矢印キーを使えることを知らない可能性があります。そのため、開発者がほとんど介入することなく、通常のタブシーケンスですべてのタブをフォーカス可能にし、キーボードを通じたタブの挙動を変えるべきだという意見もあります。
他にも、レスポンシブでアクセシブルなタブのソリューションとしてはTabPanelWidgetが挙げられます。このソリューションはプレーンで古いセマンティックHTMLに依存しており、タブが完全に適合しない場合はいつでもアコーディオンに変換することができます（この機能はResizeObserverによって実現されていますが、これをサポートしていないブラウザ向けのポリフィルも存在します）。
アクセシブルなタブ（プレビューを拡大）
このスクリプトはセマンティックでアクセシブルであるのみならず、Web向けのタブパネルとアコーディオンウィジェットの作成に役立つレスポンシブで柔軟なソリューションです。キーボードフレンドリーで、Vanilla JavaScript（またはVue、React、Angular向けのウィジェット）として利用できます。
アクセシブルなテーブル
テーブルに関連するアクセシビリティの問題は数多く存在しますが、最大の課題は、重要な情報を省略することなく、視覚的な表現を、スクリーンリーダによって読み上げられる意味ある内容の線形の文字列に変換することです。幸運なことに、Adrian Roselliはアクセシブルなテーブルの課題と解決策の追求に多くの時間を費やしています。
（プレビューを拡大）
Adrianはアクセシブルなテーブルに関する記事で、テーブルをrole="region"、aria-labelledby、tabindex="0"を有する<div>でラップすることによって、キーボードのみを利用するユーザがタブによってコンテナに移動し、テーブルがフォーカスされるようにすることや、テーブル内の<caption>によってスクリーンリーダによる適切な読み上げを可能にすることを提案しています。Adrianは、レスポンシブなテーブルや、行を拡張可能なテーブル、ソート可能なテーブル、見出しが固定されているテーブルのコード例も提供しています。
スクリーンリーダはどのようにデータテーブルを読み取るか
スクリーンリーダでテーブルを読み取ろうとしたことはありますか。もしなければ、Léonie Watsonの「How screen readers navigate data tables」という記事をチェックすべきです。この記事では、貴重な知見を共有し、誰もがストレスを溜めずに使用できるテーブルを作成するために重要なことを紹介しています。
紅茶とコーヒーの毎日の平均消費量を示したデータテーブル（プレビューを拡大）
Léonieの記事ではテーブルへの移動、コンテンツの読み取り、特定の情報の発見にNVDAを使用しています。適切なHTMLエレメント（またはARIAロール）によって、テーブルの特徴に関する情報を取得し、テーブルのコンテンツの読み取り専用のキーボードコマンドにアクセスすることができます。
興味深いことに、キーボードフォーカスとスクリーンリーダのフォーカスは同じではありません。あなたが過去に聞いたこととは逆かもしれませんが、読み取りを支援するためにテーブルの各セルをキーボードでフォーカス可能にする必要はないのです。しかし、セル内のコンテンツがインタラクティブではない場合、キーボードユーザはあなたが思うよりもはるかにテーブルの読み取りに苦労することとなるでしょう。LéonieのSmashing TVビデオ「How A Screen Reader User Accesses The Web」（73分）もご覧ください。
アクセシブルなトグルスイッチ
フォームでオン/オフ、ダーク/ライトモードなどの二択を顧客に提供する場合はいつでも、トグルスイッチを使用する可能性があります。スイッチはいくつかの目的を果たすことが必要です。まず現在どちらが選択されているかを明確に示し（明確に示されていないケースが少なくありません）、2つの選択肢があることを説明し、両者を切り替える方法を顧客が理解できるような十分に分かりやすいものでなければなりません。Sara Soueidanによるトグルスイッチをビルドする方法についての記事では、当然ながら、アクセシブルなトグルスイッチをビルドする方法についても相当の時間をかけて説明しています。
Mediumアプリのテーマカスタマイザはシンプルなポップアップパネルで、ライトモードとダークモードを相互に切り替えるためのシンプルなスイッチが搭載されています。Saraの記事より抜粋（プレビューを拡大）
Saraの解決策は、2つのラジオボタンを使用すること、それぞれに独自のラベルを付けること、アシスティブテクノロジーが別個の2つのオプションとして読み上げられるようにすること、キーボードによってアクセシブルにすること、そして動作にARIAやJSの追加要件が必要ないようにすることです。Saraはこの解決策に従ったテーマ切り替えトグルのコード例を公開しています。Scott O’Haraのコード例も参考にすることができます。
重要な点として、Saraのラジオボタントグルスイッチは2つのラベルによってアクセシブルとなっています。そのため、トグルスイッチに2つのラベルがなければ、使えるパターンにはなりません。Scottのレポではトグルスイッチのマークアップパターンが紹介されています（このTipsを教えてくれたScott O’Haraに感謝します）。
アクセシブルなツールチップとトグルチップ
アイコンボタンと密接に関連するコンポーネントはツールチップです。ツールチップは文字どおり「ツールのためのチップ」であり、コントロールやビジュアルの意味が誤解されないように説明する小さな情報を指します。チェックアウト時になぜ特定の個人情報が必要なのかを毎回説明する際に、おなじみのツールチップを使うことが多いでしょう。では、これらを適切に設置するにはどうすればよいのでしょうか。
左の例はNotifications（通知）と書いてあり、キャプションはPrimary label（プライマリーラベル）となっています。右の例のテキストはより長く、View notifications and manage settings（通知を確認し、設定を管理する）と書いてあり、キャプションはAuxiliary description（補足説明）となっています。Heydon Pickeringの「Inclusive Tooltips and Toggletips」より抜粋（プレビューを拡大）
Heydon Pickeringの「Inclusive Tooltips and Toggletips」は、アクセシブルなツールチップをビルドするために必要なほぼすべてのことの概要を非常に徹底的に解説しています。具体的には、チップのコンテンツをラベルと説明のどちらとして提供すべきかを決定し、それに従ってARIA属性を選択すること、title属性に頼らないこと、ツールチップ内に閉じるや確認のボタンやリンクなどのインタラクティブなコンテンツを設置するのを避けることです。
- もちろんSara Soueidanも、完全にアクセシブルなヘルプツールチップをビルドするための詳細で複雑な方法について説明しており、完全にアクセシブルでインタラクティブなコンポーネントの作成にはJavaScriptが不可欠であると結論づけています。
- Sarah Higleyもツールチップの複雑性について説明しており、コード例を公開しています。このコード例による実際の信頼性の高いパターンも紹介されています。
- Scott O’Haraはツールチップに関するGitHubレポを紹介しています。
- Adrian Roselliも、無効化されたツールチップやRTLダイレクションのデモなど、トグルのコード例を豊富に提供しています。
アクセシブルなビデオ/オーディオプレーヤー
最近では、視聴者が短い動画や長い映画を見るときに字幕をよく使うのは珍しくありません。私たちはうるさい環境でビデオを視聴するかもしれず、あるいは書かれた文字のほうが理解しやすい場合や、別のことで忙しくて、ヘッドホンに頼らずに何かを急いで調べなければならない場合もあります。それ以外にも<space>キーでの一時停止や、矢印キーで巻き戻しや早送りをすることは多いはずです。しかし、多くのビデオプレーヤーとカスタムソリューションは、こうした機能をすぐに利用できるようにはなっていません。
（プレビューを拡大）
「Accessible HTML5 Media Players」という記事では、アクセシブルなオーディオプレーヤーとビデオプレーヤーの概要を説明しています。この分野には優れたオープンソースの選択肢が多く、例えばAblePlayerは信頼性が高いプレーヤーの1つと思われます。このプレーヤーは、キーボードでアクセス可能なプレーヤーコントロールを完備している、スクリーンリーダのユーザにとって適切なラベル付けがなされている、音声認識のユーザにもコントロール可能、配色のコントラストが高い、クローズドキャプション、字幕、チャプタ、テキストベースの音声解説、インタラクティブなトランスクリプト機能、自動テキストハイライトをサポートしているといった特徴があり、YouTubeとVimeoにも対応しています。ただし、jQueryに依存しています。
あるいは、Vime.jsに注目してもよいでしょう。Vime.jsは完全オープンソース、低容量、完全カスタマイズ可能で、サードパーティへの依存性もありません。その他の優れた選択肢であるPlyrや、PayPalが提供するAccessible HTML5 Video Playerも同様です。後者はキーボードのみを使用するユーザやスクリーンリーダのユーザにも完全にアクセシブルで、バニラJavaScriptで書かれており、Reactコンポーネントとして追加的に提供されているうえ、JavaScriptが使用できない場合はブラウザのネイティブコントロールへフォールバックする仕組みになっています（このTipsを教えてくれた@jamsandwichに感謝します）。
スクリーンリーダのユーザをいら立たせるWebサイトの機能
画像代替キャプションの欠如、自動再生されるビデオ、ラベルがないボタン、うまく活用できていない見出し、アクセシブルでないWebフォーム――視力があるユーザにとっては小さな問題に思えるかもしれませんが、目が見えない人や視覚障害がある人にとっては、自力で利用できるWebサイトとそうでないサイトを分ける違いとなる可能性があります。Holly Tukeは、このことを自身の経験からよく知っています。
見出しの階層。見出し1から見出し5まで（プレビューを拡大）
Hollyはよくあるアクセシビリティに関する問題への意識を高めるために、彼女がスクリーンリーダのユーザとして毎日直面するWebサイトの5つのいら立たしい特徴と、当然ながらその解決策についてまとめています。Chris Ashtonも、スクリーンリーダのユーザにとってよくある問題を説明した記事を公表しました。こうした問題は、セマンティクスやキーボードのアクセシビリティのみに重点を置いた議論では忘れられがちです。小さな細部にこだわることが大きな違いを生み出します（このTipsを教えてくれたAlex Chudesnovに感謝します）。
まずはアクセシビリティ対応を
アシスティブテクノロジーは多様な形でブラウザやコードと相互に影響を与え合っています。しかし、スクリーンリーダや音声コントロールソフトウェアを完全に自動化することは依然として不可能であり、手作業でテストをする必要があります。そこで役に立つのがa11ysupport.ioです。
アクセシビリティ対応（プレビューを拡大）
このコミュニティ主体のWebサイトは、元々Michael Fairchildが作成したものであり、アクセシビリティ対応とは何かを開発者に伝えることを目的としています。このプロジェクトは現在もアクティブで、コントリビューションを常に歓迎しています。ですから、ぜひテストをしてみましょう。またWAI-ARIAのオーサリングプラクティスは、一般的なコンポーネントやパターンに必要とされる非常に重要なセマンティクス、ロール、ARIAについて説明しており、いつでもチェックに値します（このTipsを教えてくれたStephanie Ecklesに感謝します）。
アクセシビリティに関するリソースとチェックリスト
アクセシビリティは極めて重要ですが、残念なことに、往々にして見落とされています。A11Y Projectは、デジタルアクセシビリティをより簡単なものにすることを目的としたコミュニティ主体の試みであり、デザイナーや開発者が美しく、アクセシブルでインクルーシブなユーザ体験を構築するために必要なノウハウを提供しています。
A11Y Project（プレビューを拡大）
アクセシブルなデザインを支える基本原則、アクセシビリティ監査の実施からコミュニティの育成に至るまで、A11Y Projectはアクセシビリティに関するトピックを全方位にわたってカバーしています。記事のテーマは、簡単なTips、読むべき書籍についてのヒント、フォローすべきニュースレター、便利なツール、アクセシビリティにコミットしているグループなど多岐にわたります。
アクセシビリティツールのリポジトリ
プロジェクトを完了する前に、何かを忘れているようで落ち着かない気持ちになったことはありませんか。やるべきことをざっとチェックし、最終的な公開の前に確認するには、チェックリストが重要であることが知られています。アクセシビリティに関しても、見落としを防ぐためのツールやリソースの掲載を増やしているリストがあります。それが「A11y Resources」です。
アクセシビリティに関するツールとリソース（プレビューを拡大）
Hannah Milanがまとめたこのリストは、元々200以上の精選したアクセシビリティプラグイン、ツール、記事、ケーススタディ、デザインパターン、デザインリソース、アクセシビリティ基準や、さらにチェックリストを追跡するために作成されたものです。もちろん、足りないものがあれば常に自分でツールを提出することも可能です。
まとめ
アクセシビリティのコミュニティには間違いなく、有能な人々による数十・数百もの重要なガイドラインが存在します。例えばSteve Faulknerはセマンティクスとアクセシビリティについて、Léonie Watsonもアクセシビリティ全般についての記事を大量に執筆しています。全員を列挙するのは不可能ですが、私たちはアクセシビリティへのあらゆる貢献に心から感謝しています。
恐らく、私たちが見落としている重要で貴重なテクニックやリソースも存在するでしょう。ですから、ぜひコメントでそうした情報を教えてください。皆が信頼性とアクセス性の高いコンポーネントをより迅速にビルドするための支えとなるように、私たちはこの記事を積極的にアップデートし、最新の状態を維持したいと考えています。
こうしたツールとテクニックが、皆さんの日常業務のためになること、そして最も重要な点として、時間がかかるルーチンのタスクを回避するのに役立つことを心から願っています。
これからもアクセシビリティを追求していきましょう！
THANK YOU! ❤️
@jamsandwich、Courtney Heitman、Stephanie Eckles、Adam Silver、Daniela Kubesch、Tanisha Sabherwal、Manuel Matuzović、Vadim Makeev、Kitty Giraudel、Ian James、Juha Lehtonen、Heydon Pickering、Shivani Gupta、Jason Webb、Alex Kallinikos、Scott O’Hara、Sara Soueidan、Sasha Chudesnov、Adam Liptrot、Holger Bartel、Kim Johannesenおよびアクセシビリティに関して情熱的に取り組んでいるすべての人に、この記事に貢献いただいたことを心から感謝します。重要なのはコミュニティです。
アクセシビリティについての関連記事
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
- Twitter: @yosuke_furukawa
- Github: yosuke-furukawa
関連記事
