WAVE / WAVEの16ステップ：横スクロールの理由を画面で確かめる

狭い画面で16個を並べると何が起きるか

まず、収める・縮める・スクロールするという3つの選択肢を整理します。

• 収める：16個を画面幅いっぱいに均等に並べます。全体は一目で見えますが、1マスの幅は画面幅に縛られます。
• 縮める：マス自体を小さくして余白も削ります。見た目は収まりますが、指で狙う難しさが増えます。
• スクロールする：1マスの大きさを保ち、はみ出た分は横にずらして見ます。押しやすさは保てますが、全体を一目では見られません。

リズムを組む道具では、この選択が使い心地を左右します。ステップシーケンサー（音を並べる格子状の画面）は、全体の並びを見渡すことと、1マスを確実に押すことの両方が求められます。この2つは狭い画面では両立しにくく、WAVE / WAVEは「狭い画面ではスクロール」の側に倒していると、設計から読み取れます。

ただし、なぜ倒したのかという内部の経緯は確認できません。ここでは「画面を見て、そう読めるか」を検証する形にします。

先に計算する：1ステップの幅

作品を開く前に、収めた場合の1マスの幅を算数で出します。式は次のとおりです。

1ステップの幅 ＝（画面の幅 − トラック名などの左側の幅）÷ 16

ブラウザの開発者ツールやコンソールで試せる最小の計算式を置きます。

function stepWidth(screenW, labelW, steps = 16) {
  return (screenW - labelW) / steps;
}
console.log(stepWidth(360, 0));  // 22.5
console.log(stepWidth(360, 60)); // 18.75
console.log(stepWidth(768, 60)); // 44.25

360、60、768はすべて、計算を示すための仮の値です。WAVE / WAVEの実際のラベル幅や余白ではありません。この例では、左側を考えない場合でも1マスは22.5ほどになり、ラベル分を引くとさらに小さくなります。

比べる基準として、ウェブのアクセシビリティ指針（WCAG）には、押す対象の大きさの目安があります。WCAG 2.2の達成基準では最小24×24 CSSピクセル、より高い水準を示すWCAG 2.1の基準では44×44 CSSピクセルとされています。正確な条件や例外は、W3Cの公式文書で確認してください。

この目安に照らすと、仮の計算でも「幅の狭い端末に16個を無理に収めると、基準を下回りうる」ことが見えます。作品の実際のマスが何ピクセルかは、次の手順で自分の画面から測ります。

画面で確かめる手順

準備するもの

• WAVE / WAVEを開ける端末またはブラウザ（できれば幅の異なるもの2つ以上）
• 記録用のメモか表計算
• 定規代わりになるもの（スクリーンショットと画像の座標確認、または画面上の目盛りツール）

作品はサンドボックス付きの枠の中で動くため、外側の開発者ツールからは中身の寸法を直接読み取れない場合があります。その場合は、スクリーンショットで測るのが確実です。

手順

1. 画面幅を決めます。ブラウザの幅を変えられる場合は、広い（パソコン相当）、中くらい、狭い（スマートフォン縦相当）の3段階を用意します。実機がある場合は縦向きと横向きも加えます。
2. 各条件で、何も触らない状態の画面を表示し、一画面に見えているステップ数を左端から数えます。
3. 16に届いていなければ、スクロールが必要な状態です。16まで見るのに何回スクロールしたかを数えます。同じ指の動きで1回と数えます。
4. 見えているマス1つの幅を、スクリーンショットのピクセル数と画面の実寸から換算して記録します。換算が難しければ、「隣のマスの境目から境目まで」の画像上の長さを、画面全体の幅に対する割合で記録するだけでも比較になります。
5. 同じ条件で、マスを10回狙って押します。押したいマスと違うマスが反応した回数を記録します。10回は多くはない数ですが、条件間の差を見る目安にはなります。
6. ブラウザの拡大・縮小やプレイ画面の拡大も、条件として一段階ずつ加えて、2〜5を繰り返します。

記録表の例

• 広い、向き：横、拡大：標準、見えるステップ数：、16までのスクロール回数：、1マスの幅：、誤タップ（10回中）：
• 中、向き：縦、拡大：標準、見えるステップ数：、16までのスクロール回数：、1マスの幅：、誤タップ（10回中）：
• 狭い、向き：縦、拡大：標準、見えるステップ数：、16までのスクロール回数：、1マスの幅：、誤タップ（10回中）：
• 狭い、向き：縦、拡大：拡大、見えるステップ数：、16までのスクロール回数：、1マスの幅：、誤タップ（10回中）：

表の空欄は、読者が自分で埋める部分です。

作品を開いて確かめる項目

次の点は確認済みの仕様に書かれていないため、作品を開いて観察します。表の下にチェック欄として添えてください。

• スクロールしても、トラック名やミュートの操作は見え続けているか。
• ループ再生中、いま鳴っているステップの位置は画面内に見えているか。見えない位置を再生しているとき、何が手がかりになるか。
• 4ステップごとなどの区切りは、視覚的に分かるか。
• 3つのお手本を読み込んだとき、パターン全体を把握するのに何回スクロールが必要か。

結果の読み方と起こりやすい誤り

記録がそろったら、次の3つの視点で読みます。

視点1：1マスの幅が、条件によって変わるか。 画面幅が変わってもマスの幅がほぼ一定なら、「大きさを保ってスクロールで対応している」と読めます。画面幅に比例して変わるなら、縮めて収める設計の部分があると読めます。

視点2：誤タップが増える条件はどこか。 幅が狭い条件で誤タップが目立つなら、スクロールが押しやすさを支えているかもしれません。反対に、スクロール量が多い条件で操作が煩雑だと感じたなら、「全体を見渡せない」という代償が見えている可能性があります。どちらの感触も、書き留める価値があります。

視点3：見えない範囲の再生位置の扱い。 ループ再生中に画面外のステップが鳴るなら、耳で拍を取れるかどうかが重要になります。画面の見えかたと音の聞こえかたのどちらに頼って組むのが楽か、自分の感覚を書いておくと、設計の判断を想像する手がかりになります。

読み違えやすい点も挙げます。

• 試行回数が少ないことを忘れない。 10回の誤タップ数は、指の位置や持ち方で揺れます。差が1〜2回なら、有意な差とは読まず、傾向のメモにとどめます。
• 条件を一度に複数変えない。 画面幅と拡大を同時に変えると、どちらの影響か分からなくなります。1回に動かす条件は一つにします。
• 見えるステップ数の数え間違い。 端が途中で切れているマスは、完全に見えているものだけを数えると決めておきます。
• 実寸と画面ピクセルの混同。 画面の拡大率や端末の画素密度で、画像上のピクセルと見た目の大きさはずれます。CSSピクセルとの比較は目安として扱います。
• 目安の基準を絶対視しない。 24や44は押しやすさの目安で、作品の良し悪しを決める数字ではありません。指の太さや、使う人の状況によって適切な大きさは変わります。

もう一つ、動きを抑える設定にも触れておきます。作品は「動きを抑える」設定に対応しています。スクロール時の動きや再生位置の見え方が変わる場合があるので、設定を切り替えて同じ手順を繰り返すと、位置の手がかりが動きに頼っているかどうかも確かめられます。

次の行動

画面幅を2つ決め、見えるステップ数と16までのスクロール回数を数えるところから始めてください。そのうえで、お手本を一つ読み込み、ループ再生しながら再生位置を目で追えるか確かめます。自分の作品に横長の格子を置く場合は、同じ表の形で記録して、収めるのか、スクロールさせるのかを決める根拠にしてください。

参考資料

• W3C「Web Content Accessibility Guidelines (WCAG) 2.2」達成基準 2.5.8 ターゲットのサイズ（最小）
• W3C「Web Content Accessibility Guidelines (WCAG) 2.1」達成基準 2.5.5 ターゲットのサイズ