[Kmical Lights]

現状の Snow Monkey Forms で「確認する」ボタンを押し、確認画面へ遷移した場合、先頭スクロールがしないようです。
（iPhone、またはMac Safari時…それ以外は未確認）

なので、確認画面の表示がされる際は「戻る」「送信する」の最後部が表示される形となり、縦に長いフォームになると「お前は何を確認させたいんだ（AA略）」とか、いちいちスクロールで戻らないといけないので「お前は本当に確認させる気があるのか（AA略）」な状態などになっていると思います。

各イベント発生後にフォームの先頭箇所へスクロールするようにすると、使い勝手も上がると思いますがどうでしょうか？

追記：公式のお問い合わせフォームでも先頭にスクロールしない事を確認してます

♥ 0

いいねをした人: 居ません

[キタジマ タカシ]

Android や Mac Chrome だと先頭にスクロールするので、Safari で問題があるのかもですね。確認してみます。

♥ 1

いいねをした人: 居ません

[Kmical Lights]

再度幾つかのブラウザ確認すると、確かに Safari だけスクロールしないようでした。Linux でも Chrome だと起こりませんね。
(※ なお、Windows 環境の Edge などは不明です）

公式お問い合わせフォームでも Safari だけで起こっているのを確認できています。

♥ 0

いいねをした人: 居ません

[キタジマ タカシ]

このフォーム先頭への移動、div に tabindex="-1" をつけて実現しているのですが、どうも Safari はそのような要素は無視し、フォームの要素やリンクだけが対象になるようです。

タブキーでのフォーカスの移動 – Qiita

Mac 上の Safari/Chrome では、設定によってタブキーによるフォーカスの対象が異なる。設定は三箇所Mac の「システム環境設定」「キーボード」の「ショートカット…

qiita.com

ダミーのテキストフィールドを disabled で置いてみたり、display: none で置いてみたりもしたのですが、ちゃんと送信できるものでないとフォーカスされないようです。ということでこれ結構対処難しそうだなと…。

♥ 0

いいねをした人: 居ません

[Kmical Lights]

んー、こちらでも調べてみた感じだと Safari では確かに tabindex でフォームにフォーカスを当てるの難しい感じですね。

となると…フォームの先頭に ｉｄ などを一意的に自動的に割り当てて、送信した瞬間に ｉｄ へのスクロールを発生させるとかでは駄目です？要は、先頭に行けば良いと言う考えです。
（やってみないと解らないけど、今の仕様ならフック使ってでも一意的な ｉｄ をランダム生成できるっぽいし）

入力へ戻る場合は、確かに先頭の入力にフォーカスも移動する方が良いんですが、
確認画面と完了画面って基本的には入力をする画面じゃないので…フォームの先頭にスクロールをさせるだけでも今よりはマシになるのではないかと。

何か５０１出るので、ｉｄと大文字にしといた（汗）

♥ 0

いいねをした人: 居ません

[キタジマ タカシ]

アンカーへのスクロールってことですよね。それだとドロップナビやヘッダーの高さなんかも考慮しないといけなくなるのでちょっと面倒なんですよね。今試していたのですが、フォーカスさせている .smf-focus-point を a 要素にして適当なテキストを入れておき、それを

.smf-focus-point {
  outline: none;
  height: 1px;
  overflow: hidden;
  display: block;
  font-size: 0px;
}

しておけば気にならないくらいの見え方でフォーカスも効くようにできそうでした。

♥ 1

いいねをした人: 居ません

[Kmical Lights]

なるほど。

気にならない見え方ですし、screen text のやり方と似たような方法なので SEO 的にも大丈夫そうですね。
灯台などのスコアで見えないテキスト云々と警告になる場合があるのですが、
少し試してみただけの感じでは問題なさそうでした。

いや、、ページ内検索（ コマンド + F ）した場合に 適当なテキスト が引っかからないかどうかだけ未検証なので、
そこの検証は必要そうですね…。後でチェックしときます。

このサポートフォーラム、ｃｍｄって単語だけでも 501 出るの…コード弾きが強すぎ…

♥ 0

いいねをした人: 居ません

[キタジマ タカシ]

いや、、ページ内検索（ コマンド + F ）した場合に 適当なテキスト が引っかからないかどうかだけ未検証なので、
そこの検証は必要そうですね…。後でチェックしときます。

僕も未検証ですが、多分ひっかかると思うんですよね。だから検索にかかるのもそうだし、もし表示されてもおかしくないテキストにしないとかな？と思いました。全然良いのが思いついていないですが、「フォームの先頭」みたいな。

このサポートフォーラム、ｃｍｄって単語だけでも 501 出るの…コード弾きが強すぎ…

ねー。普通の記事投稿画面だとコードも普通に書けることが多いので、フォーラム投稿でも書けるようになってほしいんですけどね…。

♥ 0

いいねをした人: 居ません

[キタジマ タカシ]

input[text].smb-focus-point にして

.smf-focus-point {
    pointer-events: none;
    outline: none;
    background-color: black;;
    border: none;
    box-shadow: none;
    width: 1px;
    height: 1px;
    line-height: 0;
    overflow: hidden;
    font-size: 1px !important;
    padding: 0;
    margin: 0;
}

.snow-monkey-form {
    position: relative;
}

.snow-monkey-form .smf-focus-point {
    position: absolute;
    top: 0;
    left: 0;
}

でも良いかも。これならテキスト考えなくても良いし。

♥ 0

いいねをした人: 居ません

[Kmical Lights]

だから検索にかかるのもそうだし、もし表示されてもおかしくないテキストにしないとかな？と思いました。

少し関連する事かもと、今少し試してましたが
WordPress の 標準でもある screen-reader-text でも、ページ内検索ではその中に記述されている文字列はヒットしていますね。
ソーシャルナビでscreen-reader-textに変更してもらいましたが、
この場合はページ内検索時じゃなく、リンクのカーソルに合わせた場合でも、リンク内文字列を音声で正しく鳴るようになっているので、むしろメリットと考えられます。
（音声ブラウザの設定にもよるんだろうけど、Twitterの鳥アイコンなら、マウスホバーすると「ツイッター」って発音してくれるようになった）

そう考えたら、文字列を入れて進行によって「この先の項目を入力してください」「この先の項目を確認してください」みたいな見えない文字列にも変わるようになれば、音声ブラウザ上では違和感がない、むしろ確認などを促せるメリット効果になる可能性も考えられるかも。

と、考えているうちに別のコードが書かれている（笑）
ちょっとコードの方はまだ試せてませんが、書かれたコードのパターンだと確かにテキスト要らなくなりスッキリしますね。

♥ 0

いいねをした人: 居ません

[Kmical Lights]

最新版 + 公式フォームで修正されている事を確認できたのでクローズします。
ありがとうございました。

♥ 1

いいねをした人: 居ません

[投稿者]

投稿