（1）モバイルユーザビリティとは
（2）モバイルユーザビリティ上の問題点
（3）問題点に対する対応
ビューポートが設定されていません
コンテンツの幅が画面の幅を超えています
テキストが小さすぎて読めません
クリックできる要素同士が近すぎます
（4）その他気になった点
画像が中央に揃わない
表組みが崩れる
翻訳しますか？ と聞かれる
（5）参考ホームページ、本
参考ホームページ
モバイルフレンドリーテスト
参考図書
（6）終わりにあたって
目次に戻る
多くのインターネット利用者がお世話になるのが、検索サービスです。インターネット草創期は、ヤフーなどが人手で登録したサイト名やカテゴリー、キーワードなどからインデックスをコンピューター上に作成し、検索利用者に提供していました。その後、主流となったのが、データの収集から検索、検索結果の提供までを、すべて、コンピューターが処理して行う機械検索です。機械検索では、Googleなどのコンピューター（のソフトウェア）がインターネット上のHPに対し、定期的に『クロール』と称する巡回を行い、文字や画像を中心にデータを収集し、膨大なインデックスを作成します。このため、私たちが入力したキーワードに対して、あんなに短時間で、キーワードを含むHPの一覧が戻ってくるわけです。
Googleのクロールの間隔は、一般に約0.5～1ヶ月程度ですが、TV局や新聞社など更新頻度の高いサイトは、日～時間と短くなっています。なお、クロールによるデータ収集範囲を制限したい場合、あるいは、一部の検索エンジンの巡回を拒否したいという場合は、『robots.txt』に詳細を記述します。たいていのサイトには、このテキストファイルが置かれています（必須というわけではありません）。また、特定のページのインデックスを拒否したい場合は、ページ冒頭に『<meta name="robots" content="noindex">』というメタタグを書いておけば、Googleは、閲覧はしますが、インデックスの作成は、行いませんので、ユーザーがキーワードで検索した際、ページは、検索結果リストに表示されません。しかし、ブラウザソフトで、直接、URLを入力すれば、そのHPを閲覧することは、可能ですので、注意が必要です。
Googleが機械検索において、一頭地を抜きん出た理由は、『ページランク』というWebページに対する評価方法の概念及びそれをコンピューターで機械的に求められるようにしたアルゴリズム並びにアルゴリズムの実行を可能にしたコンピューターリソースにあったことは、よく知られています。Googleの検索結果では、同一のキーワードを含むサイトが複数個ある場合、ランクの高いサイトほど上位に表示されます。ランクが高いサイトは、重要なサイトであり、他のランクの高いサイトから、リンクされていることが必要です。
ヤフーの登録サイトなどは、申請のあったサイトを人手により、評価していましたが、サイトの数が爆発的に増加すると、人手による登録や評価自体が困難になりました。Googleに先行したNTTのgooなど、他の機械検索サービスもサイトの重要度を機械的に判別しようとしたとは、思いますが、ページランクほどの概念、アルゴリズム、コンピューターリソースに対する投資を行うことができず、（中国を除いて）Googleに席巻される結果になりました。
さて、スマートフォンなどのモバイル機器が登場した後も、Google検索の収集データは、PCでの表示ページが対象となっていました。それが、急速なモバイル機器の普及に伴い、モバイル機器での表示ページが中心となるように変更されたとのことです。（2019/4）
上のグラフは、2019/4末～2019/7まで、本サイトをGoogleで検索したデバイスの割合。ブルーがPC、オレンジがスマホなどの携帯機器で、約1/4を占めています。なお、グレーは、タブレットです。
Googleは、モバイル機器での表示品質をページランクと結びつけることにしており、検索結果で上位にページを表示したいと考えるWeb制作者（筆者がこのように称するのもおこがましい限りですが）は、モバイル機器で自サイトが適切に表示されるか否かに関し、これまで以上に注意を払う必要に迫られています。
一方、Googleでは、Webmaster Search Consoleに『モバイルユーザビリティ』なる評価項目を追加しました。制作者は、定期的にこの項目にアクセスして、自サイトのモバイル機器での表示に問題がないかどうかをチェックできるようになりました。
https://www.google.co.jp/webmasters/
Googleによる『モバイルフレンドリー』に関する説明は、上図のページの「Search Console」リンクから表示されるページにあります。
https://support.google.com/webmasters/answer/9063469?hl=ja
以下では、ホームページビルダー（以下「HPB」という）でHPを作成している筆者が、2019/6にGoogleより指摘された複数の問題を解消するために、とりあえず、行った対策を心覚えとして、まとめたものです。
目次に戻る
前述のSearch Consoleからモバイルユーザビリティ上の問題点について、調べてみた結果です。
2019/6/18以前は、何の対策も取っていなかったため、エラーとして、150ページ程度が指摘されていました。それが、7月末で、ほぼ、ゼロとなりました。（図を新しいものに差し替えました。2019/8/17
）
指摘された問題点は、以下の4つでした。
・ ビューポートが設定されていません
・ テキストが小さすぎて読めません
・ クリックできる要素同士が近すぎます
・ コンテンツの幅が画面の幅を超えています
次節以降で、これらの問題点の意味と対策を記載します。
目次に戻る
このエラーについて、上述のGoogleのQ&Aから引用しますと、
『ページに viewport プロパティが定義されていません。このプロパティは、画面サイズに合わせてページのサイズとスケーリングを調整する方法をブラウザに指示します。サイトにアクセスするユーザーは、大きなデスクトップ
モニター、またはタブレットや小型のスマートフォンなど、画面サイズの異なるさまざまな端末を使用しています。そのため、ページでは meta viewport
タグを使用してビューポートを指定してください。詳しくは、レスポンシブ ウェブデザインの基礎をご覧ください。』とありました。
この対策は、以下のメタ文をHPの冒頭部分（<Head>タグの後）に貼り付けます。（GoogleのHPに下記がある）
<meta name="viewport" content="width=device-width,initial-scale=1">
単純なコピー&ペーストですが、ページが多いと手作業では、無理でしょう。HPBでは、サイトを開いた状態で、サイト⇒サイト内置換とたどり、以下の図のように<head>タグを<head><meta・・・>で置換します。『HTMLソース』にチェックすることが大切です。また、作業前にHPBのサイト全体をバックアップコピーしておき、単純ミスに備えてください。なお、<head>の次に改行がなくても差し支えありません。このように置換を使うと既存の他のメタ文より上位に来ますが、特に気にする必要は、ないでしょう。
この対策により、以下に示すように6/18を境に一挙に問題は解消されました。その後、修正し忘れたページが1つ程度、検出されましたが、それらは、手作業でソースを修正しました。
目次に戻る
コンテンツとは、文字や画像などです。これは、前節のようには、簡単には、解決できませんでした。GoogleのQ&Aから要点を引用しますと、『語句や画像を表示するために水平スクロールを必要とするページが示されます。このエラーは、ページの CSS 宣言で絶対値を使用している場合や、ページの画像が特定のブラウザ幅（980px など）で最適に表示されるように設計されている場合に発生します。このエラーを修正するには、ページの CSS 要素に対して相対的な幅と位置の値を使用し、画像も同様にスケーリングできるようにします。詳しくは、コンテンツのサイズをビューポートに合わせる方法についての記事をご覧ください。』とありました。昔に作成したページを除いて、スタイルシートを利用して、文字の大きさ、文字揃え、<H1>タグなどの色や高さなどを変更してはいましたが、要は、その程度でした。当初、エラーがあるページには、いくつかの大きな画像がありましたので、そのせいかと思い、画像サイズを小さくしたところ、結果は、変わりませんでした。画像の大きさのせいではなかったからです。大きい画像があっても、前節のビューポートの設定により、画面幅に収まるように縮小されるので、このエラーにはなりません。
今回、何らかの方法で、スタイルシートを編集する必要がありました。また、スタイルシートを利用してないページは、可能な範囲で、利用することにしました。
HPBからスタイルシートを編集するためには、HPBのツールバーの『スタイルシートマネージャの表示』を起動するのが分かりやすいです。新規にスタイルシートを追加するのもここから可能です。
上の図のように、既存のスタイルシートを選択後に、『CSSエディタで編集』をクリックすると、CSSエディタが起動します。
メモ帳などのテキスト編集ソフトでも編集はできますが、エディタの方が便利です。ただし、HPB付属のCSSエディタは、最新のCSSに対応していません。そのため、ツールから文法チェックを行うと、エラーと指摘されることがありますが、実用上、特に差し支えありません。
今回、問題となったのは、列幅をピクセル値で指定している表、改行されない文字列を含んでいる表でした。
表の列幅をピクセルで指定している表は、パーセントに修正しました。あるいは、表のサイズを100%にして、列幅の指定を削除しました。列幅の指定がない場合は、列幅が均等になります。それでは、見にくいものは、面倒でも、パーセントで指定しました。
しかし、これでも、直らない表がありました。以下のような感じに表示されてしまうページです。
おかしい表示は、上の図のように特定の表が画面の幅全体に広がるにもかかわらず、その表以外の文字列は、その幅よりも狭い幅で自然改行しているのです。上の図の文章の右側が空いているのがその様子を表します。これが極端になると、次節以降の、テキストが小さい、リンクが近すぎる問題の原因にもなります。PCやタブレットの画面では、こうは、表示されず、スマホでのみ、こうなるので、なんでだ！、という気がしましたね。
しつこいエラーの原因は、『改行されない文字列』がある場合でした。改行されない文字列とは、URLアドレスのように半角の英数字のみの文字列です。これが表の中にあるとその文字列だけが改行せずに突出して表の幅を広げてしまいます。なお、通常、セル内で改行するに設定されていてもこうなります。URLだけではなくて、A123456789BBBBAAA のような単純な英数字の羅列でもこうなります。（数字のみの場合は、改行されます）
スタイルシートの表の部分に次のように強制改行するように指示する命令を追加しました。
/* 表 */
table{
/* 文字列の折り返し（強制） */
word-break:break-all;
}
また、画像のスケーリングについては、下記をスタイルシートに追加しました。画像は、自動縮小されます。また、画像の拡大は、原寸（100%）までです。
/* 画像 */
img{
/* 画像幅 最大100%まで自動、高さ自動 */
width:auto;
max-width:100%;
height:auto;
}
これらにより、エラーは、下図のようになくなりました。
文字の大きさは、以前は、ピクセルやポイント単位で絶対値を指定していました。これを画面幅で相対的に変化するように変更しました。
body{
/* 文字の大きさ、書体、色など */
font-size : 1.25rem;
}
一般的に、文字サイスは、1rem = 16px = 12pt、という感じだそうです。（PC画面の場合）
これを参考に、標準＝20px＝1.25rem、やや大きい＝24px＝1.5rem、大きい＝28px＝1.75rem、やや小さい＝16px＝1rem、小さい＝14px＝0.875rem、極めて小さい＝10px＝0.625rem、程度としました。
これらは、スタイルシートのbodyなどの中に記述しました。下記は、その一部の例です。重要なポイントである『文字列の改行』は、地の文であることを考慮して、適切な位置での改行を指示する、『word-wrap:break-word;』を利用しています。これでだめな場合は、前出の『word-break:break-all;』を使ってみてください。また、画面幅が500ピクセルより小さい機器では、文字サイズ等を変更するようにしています。
body{
/* 文字の大きさ、書体、色など */
font-size : 1.25rem;
font-family : Verdana, "ＭＳ Ｐゴシック";
font-weight : normal;
font-style: normal;
color : #361503;
/* 文字間、単語間 */
word-spacing : normal;
letter-spacing: normal;
/* 文字揃え、行高、インデント*/
text-align : justify;
line-height : 2.5em;
text-indent : 1em;
/* マージン、パディング */
margin-top: 0.25em;
margin-left: 0.25em;
margin-right: 0.25em;
margin-bottom: 0.25em;
padding-top:0em;
padding-bottom:0em;
padding-left:0em;
padding-right:0em;
/* 背景色・背景画像 */
background-image : url(images/wallppr008.gif);
/* 文字列の折り返し */
/* word-wrap:break-word 適切な個所で改行 */
word-wrap:break-word;
/* 画面幅500以下の場合 */
@media screen and (max-width: 500px) {
font-size : 1rem;
line-height : 2em;
text-indent : 0em;
margin-left: 0.1em;
margin-right: 0em;
}
}
これらにより、下図のように、ようやく、エラーがなくなりました。
これは、原因が前節と重なっている部分があります。GoogleのQ&Aによれば、『ボタンやナビゲーション リンクなどのタップ要素同士が近すぎるために、モバイル ユーザーが隣接する要素をタップせずに指を使って目的の要素をタップすることが容易にできないサイトの URL が示されます。これらのエラーを修正するには、ボタンやナビゲーション リンクのサイズやスペースをモバイル ユーザーに適するように正しく設定します。詳しくは、タップ ターゲットのサイズを適切に調整するをご覧ください。』とありました。
画面幅に比して、何らかの理由により、リンクが設定されている文字を含めて、文字部分の幅が狭くなってしまっているなどによるものです。文字列の改行の制御により、大部分は、解消します。あとは、改行の高さ（行間）を文字の高さの2～2.5倍程度と広くするなどにより、ほぼ、解消しました。
更に、目次があるページは、目次部分を本文とは、別の書式に変更するため、bodyの子クラスとして、mokujiを作りました。
CSS側
/* 目次 bodyの子Class */
.mokuji{
/* 文字の大きさ、書体、色など */
font-size : 1rem;
font-family : Verdana, "Meiryo UI";
color : #361503;
/* 文字揃え、行高、インデント*/
text-align : left;
line-height : 2.5em;
text-indent : 0em;
/* マージン */
margin-top: 0em;
margin-left: 0em;
margin-right: 0em;
margin-bottom: 0em;
/* 文字間、単語間 */
word-spacing : 0.1em;
letter-spacing : 0em;
/* 画面幅500以下の場合 */
@media screen and (max-width: 500px) {
font-size : 0.6rem;
line-height : 2em;
word-spacing : 0em;
}
}
HTML側 赤字の文字列を目次ソースに追加
<h3>目次<a name="a0" id="a0"></a></h3>
<p class="mokuji"><a href="#a1">（1）</a>モバイルユーザビリティとは<br>
これらの対策により、エラーは、下図のように、ほぼ、なくなりました。
Googleから指摘された問題は、前節までに述べた4点でしたが、あらためて、自サイトのページを手持ちのスマホで確認していくと、どうも気持ちの悪いことに気がつきました。それは、今月のご挨拶でページの冒頭に表示している（中央に揃えたつもりの）画像がスマホ画面の中央に表示されないことです。やや、右に寄るのです。場合によっては、画像の右の一部が切れてしまいます。スマホでも横置きにした場合やPCやタブレットでは、気になりません。
これは、次のように画像の子クラスに強制的に中央に揃えるスタイルをスタイルシートに登録して、併せて、HTMLソースの方も修正しました。後者では、サイト内の置換が役立ちました。
CSS側
/* 画像 */
img{
/* 画像幅 最大100%まで自動、高さ自動 */
width:auto;
max-width:100%;
height:auto;
}
/* 中央揃えにしたい画像 画像の子クラス */
.img-center{
display: block;
margin-left:auto;
margin-right:auto;
}
HTML側の例 赤字の部分を追加
<p><img class="img-center" src="images/201907.jpg" width="1009" height="359" border="0"></p>
なお、画像でも、中央揃えにしない画像は、そのままにしてあります。
目次に戻る
HTMLで表組みを利用して、画像を並べたりしていました。そのような場合、思うようにコントロールできない問題が発生しました。今では、表は、文字通り、データを並べた構造であり、それをブロックのように利用するのは、推奨されていません。
表の中の画像は、前節までの自動伸縮で小さくなりますが、表との整合性が崩れてしまい、表中の文章とのバランスが悪くなる場合がありました。根本的に手直しするのが本来ですが、とりあえず、CSSとHTML側とで対策を施しました。最初に例として、『情報検索リンク集』を挙げましょう。
CSS側 table
/* 表のレイアウト */
table-layout:auto;
HTML側 kensaku.htm
実際の見え方
HPBの表の設定
この表では、空きセルはあるものの、すべて、同じサイズの画像を並べてあるので、CSSのテーブルレイアウトをautoにしておくと幅の小さい画面では、画像と表が同様に縮小してくれ、違和感がなくなりました。しかし、文字と画像が混在していると難しくなりました。それがトップページでした。
トップページのCSS側
/* 表 */
table{
/* 文字サイズ、書体等 */
font-size : 1rem;
font-family : Verdana, "ＭＳ Ｐゴシック";
/* 文字揃え、行高、インデント */
text-align: left;
line-height : 1.5em;
text-indent : 0em;
/* 文字列の折り返し（強制） */
word-break:break-all;
/* 表のレイアウト */
table-layout:auto;
/* 枠線 */
border-style : none;
border-collapse : separate;
border-width : 0px;
border-color : blue;
/* 空セル */
empty-cells : show;
/* 画面幅500以下の場合 */
@media screen and (max-width: 500px) {
line-height : 2em;
font-size : 0.875rem;
}
}
実際の見え方 index.html
HPBの表の設定
画面幅が狭い場合、表も画像も縮小します。ただ、1行で表示されていた文字列は、2行に折り返して表示されます。当初のデザインのままでは、このあたりの画像と文字列との折り合いがうまくいかずに、最終的には、デザインを一部変更しました。
目次に戻る
これは、モバイルユーザビリティの問題と直接の関係は、ありませんが、スマホ等で自サイトのページを閲覧している際、たまに、『翻訳しますか？』と吹き出しが出てきて、尋ねられることへの対策です。
この原因は、Google Chrome等が、HPの文字の種類によって、中国語（繁体字）のページか日本語のページかを判別しているためのようです。タイトルなどにカタカナやひらがながある場合は、日本語と判断しますが、漢字だけですと、判断できずに、『翻訳しますか？』と聞いてくるのでしょう。
これへの対策は、日本語のページであることを明確にします。htmlソースの冒頭の<HTML>を次により置き換えます。
<HTML lang="ja">
もし、これでだめな場合は、下記を挿入すると良いとのことでした。
<meta http-equiv="content-language" content="ja">
前者のlang="ja"は、以前は、挿入していたのですが、何時の日からか、忘れていたようです。そのため、今回、全ページを検索し、入っていない場合は、置換により挿入しました。これにより、翻訳しますか？、と聞かれることがなくなりました。
目次に戻る
今回は、インターネット上の下記のページに大変助けられました。ここに記して、感謝申し上げます。
・ レスポンシブWebデザインについて知っておきたいこと【作り方入門編】（2017/6/13）株式会社アーティス
https://www.asobou.co.jp/blog/web/responsive
・ モバイルフレンドリーとは？対応できていないページ7つの特徴 （2018/4/19）橋本直子 氏
https://ppc-master.jp/labo/2018/06/mobile-friendly.html
・ 【HTML】imgタグの使い方と意味を解説【CSSでの画像の配置の仕方も】 （2018/9/14）田中陽介 氏
https://creive.me/archives/13212/
・ CSSのfont-sizeが%とかemとかremとかvwで指定されてると、ビビっちゃう君と僕を救う2分（2018/5/8）@39_isao
氏
https://qiita.com/39_isao/items/e8242901ba1aadb75676
・ CSSのwidth（幅）とheight（高さ）の指定方法をマスターしよう （2019/2/21） サルワカくん 氏
https://saruwakakun.com/html-css/basic/width-height
・ 【コピペでOK】レスポンシブ対応！画像の切り替え （2019/2/2） SACHI 氏
https://traffic-lab.co.jp/blog/160
・ 長いURLが折り返してくれない！URLを折り返させるCSS （2015/12/22） 竹中文人 氏
https://www.iscle.com/web-it/long-ulr-css.html
・ スマホ対応するならCSSでword-wrap:break-wordを指定しよう （2013/3/19） kudox 氏
https://kudox.jp/html-css/word-wrap_break-word
下記のGoogleのページでモバイルフレンドリーの度合いが分かります。
https://search.google.com/test/mobile-friendly/
Googleの説明では、『モバイル フレンドリー テストツール
モバイル フレンドリーなウェブサイトは、オンラインでの存在感を高めるうえで欠かせないものです。現在では、多くの国でスマートフォンのトラフィックがパソコンのトラフィックを上回っています。お持ちのウェブサイトがまだモバイル
フレンドリーでなければ、ぜひモバイル フレンドリー サイトにしましょう。Search Console のモバイル フレンドリー テストツールでは、サイト上のページがモバイル
フレンドリーかどうかをすぐにテストできます。』とあります。使い方は、簡単です。テストしたいページのURLアドレスを貼り付けるだけです。（アクセスしているのが人間かどうかをテストするために、複数の画像の中に信号機などが写っている画像を複数個選択させてテストするなどの画面が現れる場合があります）
目次に戻る
CSSで手元にあったのは、『HTML & CSS』（HTML 4.01 & XHTML 1.1/1.0 ｜ CSS 2 対応）（できる大事典） インプレスジャパン
2006/5/1初版。さすがに、古かったです。これを機会に、新しい版を購入するつもりです。
Google検索については、こちらも少し古い本ですが、『Google の謎』（水野貴明 著：ソーテック社：2004年4月）を参考にしました。
今回もご覧いただきありがとうございました。 関東地方では、7月28日まで、弱い雨の日が続き、気温も低めでした。薄手とは言え、7月にセーターを着た記憶は、無かった気がします。しかし、梅雨が明けたとたんに厳しい暑さが訪れました。皆さま方には、くれぐれも熱中症にご注意くださいますようお願い申し上げます。
次回も、本欄で元気にお会いできますことを願っています。
※旧ドメインは、2017/6/1で閉鎖いたしました。お気に入り、スタートページ等の変更をお願い申し上げます。
目次に戻る
作成日 2019/8/1、一部語句を加除訂正 2019/8/3、（2）の図を差替え 2019/8/17
