Conversation
✅ Deploy Preview for smarthr-design-system ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
kesteer
requested review from
Qs-F and
minami-70128
and removed request for
Qs-F and
minami-70128
schktjm
left a comment
schktjm
left a comment
There was a problem hiding this comment.
いろいろな気になりが合ったのでコメントしたのですが、私の意見も間違っているかもなので他の方の意見も聞きたくなりました！
|
@kesteer いくつかコメント残しました！その他、検討してほしいことを以下に書きます。 サマリー
1.ドキュメントのタイトルを「ドラッグ＆ドロップ」に変更してはどうかドラッグ＆ドロップに関する情報だけで、ある程度の量になりましたし「リッチなインタラクション」ではなく「ドラッグ＆ドロップ」で独立したページにするのはどうでしょうか？ 2.掲載する情報の順序をデザイン・UI設計→実装の順に整理するとよさそうDesign Systemのプロダクトに関するドキュメントのパターンとしては 「UIに関するルールが先にあり、それをウェブで実現する方法として実装がある」と考えると これを踏まえ、今回のドキュメントの構成は セクション「ドラッグ可能な領域」の内容も 3.「ドラッグ可能な領域」で書かれているルールについて確認現在の説明＋スクショだと、「状況にかかわらずカード全体をdraggableにするのはNG」のように読めましたが 貼ってあるスクショのように、draggableなカードが、他のintractiveなUI（ボタンなど）を内包する場合は「drag-handleのみが、dragの起点になる」で良いと思いますが これについてAtrassianのdesign systemにはこう書いてあります。
このAtrasianのルールをSmartHRとしても適用して良さそうに思います！ |
…into add-rich-interactive-elements-to-design-patterns
oti
left a comment
oti
left a comment
There was a problem hiding this comment.
ナイスな基準追加ありがとうございます！ 全体の書き口に違和感があったので多めにコメントしました！ 🙇
suggestionの内容はアイデアですのでそのまま取り込まなくて大丈夫ですので、まずはご確認ください！
| ドラッグ&ドロップが必要なUIには、ユーザーを混乱させないように操作に一貫性をもたせることが重要です。 | ||
| ただ、それぞれのUIのパターンにおいて、アクセシビリティを確保することも重要です。 |
There was a problem hiding this comment.
| ドラッグ&ドロップが必要なUIには、ユーザーを混乱させないように操作に一貫性をもたせることが重要です。 | |
| ただ、それぞれのUIのパターンにおいて、アクセシビリティを確保することも重要です。 | |
| ドラッグ&ドロップが必要なUIには、ユーザーを混乱させないように操作に一貫性をもたせつつアクセシビリティを確保することが重要です。 |
[IMO] この時点では読み手は複数のUIパターンがあることを知らないので、「それぞれのUIパターン」はトルツメしたいです。また、アクセシビリティが重要であることはいつもなので、シンプルに説明されて欲しいと思いました。
| ## ドラッグ&ドロップリスト | ||
| <Text weight="bold">ドラッグ&ドロップリスト</Text>は、ユーザーがアイテムをドラッグして順序を変更できるUIのパターンです。 | ||
|
|
||
| ### インタラクティブな領域 |
There was a problem hiding this comment.
| ### インタラクティブな領域 | |
| ### インタラクティブな領域の注意点 |
このセクションで伝えたいことは、「インタラクティブな領域内に別のインタラクティブ要素を入れないで」とうことだと思うので、それがわかる見出しになっているとよさそうです。
| インタラクティブな領域とは、<Text weight="bold">ユーザーがアイテムをドラッグできる領域のこと</Text>です。 | ||
| インタラクティブな領域は、ユーザーがアイテムをドラッグするためのドラッグ操作を開始できる要素を提供する必要があります。 |
There was a problem hiding this comment.
| インタラクティブな領域とは、<Text weight="bold">ユーザーがアイテムをドラッグできる領域のこと</Text>です。 | |
| インタラクティブな領域は、ユーザーがアイテムをドラッグするためのドラッグ操作を開始できる要素を提供する必要があります。 | |
| インタラクティブな領域とは、<Text weight="bold">ユーザーがアイテムをドラッグする操作に反応する領域のこと</Text>です。ユーザーはこの領域でアイテムをドラッグする操作を開始できます。 | |
| インタラクティブな領域はHTMLのインタラクティブな要素でマークアップしてください。 |
「ドラッグできる領域」だと、ドラッグできるアイテム自体のことなのか、ドラッグアイテムをドロップ可能なコンテナ範囲のことなのかがスッとわからなかったです。例えば suggestion のような文章でどうでしょうか。
| しかし、インタラクティブな要素を使用しているカードの中に、さらにインタラクティブな要素をネストすると、支援技術で内側のインタラクティブな要素にフォーカスできないなどの問題が起こります。 | ||
| この場合、カードの内部にインタラクティブな要素が存在するための<Text weight="bold">ハンドル形式</Text>パターンもあります。 |
There was a problem hiding this comment.
| しかし、インタラクティブな要素を使用しているカードの中に、さらにインタラクティブな要素をネストすると、支援技術で内側のインタラクティブな要素にフォーカスできないなどの問題が起こります。 | |
| この場合、カードの内部にインタラクティブな要素が存在するための<Text weight="bold">ハンドル形式</Text>パターンもあります。 | |
| このとき、インタラクティブな領域内にアクションボタンやリンクなどのインタラクティブな要素を含まないでください。支援技術が内側のインタラクティブな要素にフォーカスできないなどの問題が起こります。 | |
| こうしたカードの内部にインタラクティブな要素が存在する場合は、<Text weight="bold">ハンドル形式</Text>パターンで対応してください。 |
何が問題なのか、どう解決すればいいのかを簡潔に伝えたいです。
| この場合、カードの内部にインタラクティブな要素が存在するための<Text weight="bold">ハンドル形式</Text>パターンもあります。 | ||
|
|
||
| #### ハンドル形式 | ||
| HTMLのインタラクティブ要素をカードの中にインタラクティブな要素を配置したい場合は、カードコンポーネントとは別のドラッグ操作のためのハンドルを提供します。 |
There was a problem hiding this comment.
| HTMLのインタラクティブ要素をカードの中にインタラクティブな要素を配置したい場合は、カードコンポーネントとは別のドラッグ操作のためのハンドルを提供します。 | |
| カードの中にインタラクティブな要素を配置したい場合は、カード全体をインタラクティブな領域にはせず、ドラッグ操作のためのハンドルを提供します。 |
| ##### 補足 | ||
| どうしても、デザインがカード全体がインタラクティブな領域になることを要求する場合は、 | ||
| カード全体をインタラクティブな要素から`div`要素に変更し、正確なARIA属性とHTMLの[drag-and-drop API](https://developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API)を使用できます。 | ||
|
|
||
| <Text weight="bold">注意</Text>: この方法はアクセシビリティの支援技術の不具合と繋がる可能性が高いため推奨しません。 |
There was a problem hiding this comment.
| ##### 補足 | |
| どうしても、デザインがカード全体がインタラクティブな領域になることを要求する場合は、 | |
| カード全体をインタラクティブな要素から`div`要素に変更し、正確なARIA属性とHTMLの[drag-and-drop API](https://developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API)を使用できます。 | |
| <Text weight="bold">注意</Text>: この方法はアクセシビリティの支援技術の不具合と繋がる可能性が高いため推奨しません。 | |
| ##### やむを得ない場合の対応方法 | |
| どうしても、インタラクティブな要素を含むカード全体をインタラクティブな領域にしなければならない場合は、カードを`div`要素にして正確なARIA属性とHTMLの[drag-and-drop API](https://developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API)を使用してください。 | |
| ですがこの方法は支援技術の動作に不具合が発生する可能性が高いため<Text weight="bold">推奨しません。</Text> |
最終手段であるようなことがわかる表現にしたくなりました。
| - [WCAG 4.1.2: 名前 (name)・役割 (role)・値 (value)](https://waic.jp/translations/WCAG22/Understanding/name-role-value.html) | ||
|
|
||
| ### キーボードの操作 | ||
| すべてのユーザーがマウスやタッチ入力を使用できるわけではないため、ドラッグ&ドロップの操作をキーボードでも可能にすることが重要です。 |
There was a problem hiding this comment.
| すべてのユーザーがマウスやタッチ入力を使用できるわけではないため、ドラッグ&ドロップの操作をキーボードでも可能にすることが重要です。 | |
| すべてのユーザーがマウスやタッチ入力を使用できるわけではないため、ドラッグ&ドロップの操作をキーボードでも可能にする必要があります。 |
重要であると言うだけでは逃げられてしまうので、要求しましょう！
| ### キーボードの操作 | ||
| すべてのユーザーがマウスやタッチ入力を使用できるわけではないため、ドラッグ&ドロップの操作をキーボードでも可能にすることが重要です。 | ||
|
|
||
| これを実現する一般的な方法は、<Text weight="bold">アイテムを上下に移動するためのボタンを提供すること</Text>や、カード用のドロップダウンメニューをオプションとして提供することです。 |
There was a problem hiding this comment.
| これを実現する一般的な方法は、<Text weight="bold">アイテムを上下に移動するためのボタンを提供すること</Text>や、カード用のドロップダウンメニューをオプションとして提供することです。 | |
| 一般的な実現方法としては、<Text weight="bold">アイテムの位置を変更できるボタン</Text>や、ドラッグ＆ドロップと同じ操作を行えるドロップダウンメニューをオプションとして提供することです。 |
上下の移動となっているのはサンプル画像での話で、実際のプロダクトでは上下だけでなく左右もなくはないと思います。汎用的な説明にするのが良さそうです。
| <DoAndDont type="do" width="calc(50% - 8px)"> | ||
| <Image slot="img" src={doUseKeyboard} alt="Do" /> | ||
| <Text slot="label">ドラッグ&ドロップの操作をキーボードでも可能にする</Text> | ||
| </DoAndDont> |
There was a problem hiding this comment.
[IMO]
ドラッグ＆ドロップと同じ操作を行えるドロップダウンメニューをオプションとして提供
このサンプルも欲しくなりました。
There was a problem hiding this comment.
@oti できれば、Do/Dontに表示したかた（一番わかりやすい）が、Dontの例が両方で一緒になるからどういう概念で表示すればいいかなと思いました。この場合、デザインパターンにはどういう風に対応しますか？Dontが同じでも、Do/Dontで表示する感じですかね？
全然追加してもいいだと思っていますが、この部分だけを悩んでいます
There was a problem hiding this comment.
| ### アクションのキャンセル操作 | ||
|
|
||
| ユーザーがアイテムをドラッグしている最中にアクションをキャンセルできるようにする必要があります。一般的には、`Escape`キーを使用してキャンセルする方法が実装されます。 | ||
|
|
||
| アクションをキャンセルできない場合は、最新のアクションを元に戻す方法を提供する必要があります。これは、`元に戻す`ボタンやメニューのオプションを通じて行なうことができます。 | ||
|
|
||
| <Cluster gap={1}> | ||
| <DoAndDont type="do" width="calc(50% - 8px)"> | ||
| <Image slot="img" src={doCancelAction} alt="Do" /> | ||
| <Text slot="label">②と③の位置を変えるアクションのあとで、アクションをキャンセルをできるようにする</Text> | ||
| </DoAndDont> | ||
|
|
||
| <DoAndDont type="dont" width="calc(50% - 8px)"> | ||
| <Image slot="img" src={dontCancelAction} alt="Dont" /> | ||
| <Text slot="label">②と③の位置を変えるアクションのあとで、アクションをキャンセルする方法がない</Text> | ||
| </DoAndDont> | ||
| </Cluster> |
There was a problem hiding this comment.
キャンセル操作と元に戻す操作を混ぜているのが気になりました。
マウスやタッチでドラッグ中にEscapeを押してキャンセルできる話をまずして、次にキーボードサポートとして元に戻すボタンを提供すべし、という順番はどうでしょうか。
There was a problem hiding this comment.
綺麗にキーボードとマウスの分け方をできない
たしかに！
改めて見ると、元に戻すボタンよりEscapeとを優先して実装すべしと読めるのですが、これ自体はWCAGの方針に合っていますか？ 個人的には優先度に差はなく、どちらも実装されているのは良いが、どちらかはなくてはならない、という認識でした。
4 participants
課題・背景
やったこと
- デザインパターンにドラッグ&ドロップに関するページを追加し、想定されるパターンと説明を記載した。
やらなかったこと
動作確認
プレビューをみてください！
https://deploy-preview-1894--smarthr-design-system.netlify.app/products/design-patterns/drag-and-drop/
キャプチャ