タッチスクリーンを念頭に置いた「ホバー」機能の再考
例として 次のページ を例にとります（おそらくFirefoxでのみ）：
各検索結果にカーソルを合わせると、[+ Firefoxに追加]ボタンが表示されます。
ただし、ホバリング時にボタンが表示されるという考え方は、タッチスクリーンユーザーには適用されません。この機能はどのようにタッチスクリーン用に作り直されますか？
ホバーに関係なく、ボタンは常に表示されます。ただし、ページに沿って同じ[+ Add to Firefox]ボタンの長い行が表示されます。
Luke Wroblewskiがこのトピックを彼の本で取り上げています Mobile First
彼は、サイトに最適なソリューションを使用して、ホバーメニューをモバイルに移行することの重要性を強調しています。
...デスクトップWebエクスペリエンスでマウスホバーに依存するすべてのアクションを再考する必要があります。それは良いことです。 Webでのホバーアクションの多くの使用は、あまりにも多くを想定しています。
直接アクションに置き換えます
...ホバーメニューからアクションと情報を取得し、それらを画面に直接配置することは、適切なアプローチである可能性があります。これは、Twitterが元のモバイルWebエクスペリエンスで使用したソリューションです。
ここで、彼はお気に入り、リツイート、返信がホバーボタンの代わりにアイコンボタンを介して常に表示されていることを指します。
オンタップメニューに置き換えます
...デフォルトでオンタップメニューにすることができます。これは、ホバーメニューのアクションまたはコンテンツが人々にとって論理的な次のステップである場合に適しています。しかし、ホバーメニューのコンテンツが、人々の進行を妨げる不要な追加のステップを導入する場合、それは煩わしいかもしれません。
別のページで置き換える
ホバー内のコンテンツが広範囲にわたる場合は、ホバーメニューの内容をモバイルの別の画面に移動するのが最適な場合があります。これは、Barnes＆Nobleが使用するアプローチです。
ここで彼は、製品情報とモバイルバージョンの別のページに移動する（カートに追加する）ボタンが付いたホバーパネルを参照します（プロセスに追加のオプションを追加できます）。
ホバーが覆われていることを確認してください
どちらのアプローチも適切です。移動するときは、ホバーがカバーされていることを確認してください。
リストアイテムを分割します。左側にラベル、右側にボタンのようなもの。
基本的にはあなたがすでに提案したものです。これがどのように見えるかの例です。
タッチベースのデバイスのホバー交換はありません。少なくとも、すべてのタイプのタッチベースのデバイスには対応していません。
Android=で使用しているTwitterクライアントはPlumeと呼ばれています。ホバー交換を非常にうまく処理します：
もののリスト（tweetやFirefoxアドオンなど）では、リストアイテム全体がタップを誘います。タップすると、選択したエントリで実行できるアクションのメニューが下にスライドします。シンプルで、画面の領域を有効に活用します。
厳密にはユーザーとして、「ホバー」を「長押し」に置き換えた人々は私の人生を楽にしてくれました。
タッチスクリーンにアクションアイテムが表示されると、基本的にリンクが通常どおり機能するデフォルト（タップ）の選択肢、またはデフォルト以外のアクション（長押し）があります。物事を長押しするとき、私は通常、これから何をしようとしているのかを考えているので、直感的に思えます。これにより、600ミリ秒の時間で、自分が知っていることに備えることができます。
一連のアクションを実行できるオブジェクトのリストがあるとします。これらのアクションを実行する1つの方法は、 noun-verb モデルを使用することです（つまり、最初にwhatを選択してアクションを実行し、次にwhat実行するアクション）。これはリンクされた例で行われていることです。最初に（ホバーを介して）アドオンを選択し、次にアクション（インストール）を選択します。
タッチサポートを実現する1つの方法は、たとえばphpMyAdminは次のことを行います。オブジェクトを選択可能にし、1セットのボタンを提供します（各アクションに1つ）。
（アクションは「選択時：」テキストの後に使用できます。オブジェクトを1つだけ選択できる場合は、ラジオボタンを使用できます。）
別の解決策は、マウスとタッチスクリーンの両方で機能するため、ドラッグアンドドロップを利用することです（キーボードのみの操作の明らかな制限あり-推測あなたはそれをすべて持つことはできません。）
名詞と動詞の相互作用を維持するには、名詞（オブジェクト）をドラッグ可能（動詞（アクション）にドロップ可能）にする必要があります。
[List item 1] +-------------------+
[List item 2] | Drag onto action: |
[List item 3] | [Install] |
[List item 4] | [Other action] |
[List item 5] +-------------------+
[List item …]
[List item N]
ドロップターゲット（[アクションにドラッグ]ボックス）は、スクロール中もページ上の位置を維持する必要があります（position: fixed）。これが canv.as が「ステッカー」機能を実装する方法とほぼ同じです（名詞=ステッカー、動詞=ターゲットポストを投票）：
「+ Firefoxに追加」ボタンを薄い灰色で表示し、それをタップすると、色を付けて次のページに移動できます。
または、2つのタップで作業することもできます。リストアイテム（リストボックス内の任意の場所）をタップすると、[+ Add to Firefox]ボタンの色が表示され、もう一度タブで移動して次のページに移動できます。
現在、メディアクエリを使用して、ビューポートが変更されたときにその場でスタイルを変更できます。通常のサイトの例：
<style>
a { color: #ffffff; /*Blends into the background for this example*/ }
a:hover { color: #000000; /*Shows up on Hover*/
</style>
もちろん、これはモバイルユーザーには表示されませんが...
@media
only screen and (max-width: 760px),
(min-device-width: 768px) and (max-device-width: 1024px)
{
a { color: #000000; text-decoration: underline; }
}
これで、ビューポートが小さい場合、リンクが表示され、下線が表示されるため、ユーザーはそれらを見ることができます。
スペースを節約するためにメニューのごく一部しか表示されていないサイトでこれを使用しています。ホバーすると、リンクがフライアウトします。モバイルユーザーの場合、これは機能しないため、メディアクエリを使用してすべてを変更し、要素をブロックして画面の上部に配置します。
子メニュー項目の場合、私は常に最上位項目がページに移動し、ダミー項目ではないことを確認します。多くの人が問題を抱えているのは、親リンクを単なるプレースホルダーにするという何らかの傾向を追い求めたからです。プレースホルダーを正しくホバリングさせるためだけに、IE6の：hover疑似と戦っていました。今、彼らはすべてそれを再考する必要があります。したがって、最上位のアイテムをポータルページに変換するだけで、ユーザーは子供が到着したら、そのページに移動できます。これはユーザーがダウンロードする追加のページですが、数百のページがある場合は、それが唯一のオプションとなる場合があります。