モバイルコンテンツ作りに於ける推奨事項(参考資料)。
- 平成19年 5月27日 更新
モバイルコンテンツ作りに於ける推奨事項について解説します。
現在、モバイルコンテンツに於ける推奨事項を纏めた文書としては、ウェブ技術標準化団体・W3Cが策定中のモバイルウェブ・ベストプラクティスがあります。
「.mobi」ドメインを管理しているmTLDも、ドメイン運用の際の推奨事項としてこのモバイルウェブ・ベストプラクティスに準じた約束事を.mobi スイッチ・オン！ ガイドにて公開しております。
ここでは、モバイルウェブ・ベストプラクティスの中からモバイルコンテンツの作成の際に特に抑えておきたいポイントについて、解説する事とします。
- 携帯電話での音声出力に対応したコンテンツ作りでも同様の記述がありますが、この文書はより一般化したものとなっております。
- また、ケータイ小説に学ぶ、モバイル向け文書の書き方では、より具体的な方法を書いております。
ご注意。
この文書では、推奨事項のうち、特に実践すべき項目を撰んで解説しております。
- 実際には六十項目あります。本文書では複数項目を一つに纏めている箇所もあります。
- 尚、入力フォームに関する推奨事項などは省略しております。
また、一部項目で日本の携帯電話事情には必ずしも当て嵌まらない面もありますので、その点に関しては補足させて頂きました。
- 如何に日本の携帯電話事情に合わない面があるとは言え、全く無視して良いと言うものではありませんので補足した上で解説しております。
ポップアップウィンドウを出すべからず。
ポップアップウィンドウを出す機能が無い端末もあります。
いや、そんな機能があったとしても、狭い画面をポップアップウィンドウが占領したら閲覧の邪魔にしかなりません。
以上の理由から、モバイル向けのコンテンツではポップアップウィンドウを使わないで下さい。
また、デスクトップ端末向けコンテンツみたいにリンクを別ウィンドウで開くような機構も使ってはいけません。
- XHTML 1.0 トランジッショナルには、リンク先を表示するウィンドウを指定するtarget属性がありますが、モバイルコンテンツでは絶対に使ってはいけません。
イメージマップは使うべからず。
携帯端末は、デスクトップ端末みたいにカーソルを三百六十度自由に動かせない端末が大半です。
また、スクロールの概念の無い端末も否定出来ません。
- このような端末の場合、ページを切り替える事で長いコンテンツを表示させる事になるでしょう。勿論、そんな端末ではイメージマップの使用は不可能に近いでしょう。
いずれにしても、モバイル向けコンテンツではイメージマップを絶対に使ってはいけません。
リフレッシュは使うべからず。
リフレッシュとはHTTPの機能の一つで、リソース表示後一定秒数が経過したら指定されたりソースを取得すると言うものです。
本来、コンテンツ配信時に附与するHTTP応答ヘッダで指定しますが、多くの場合<meta>要素を用いてHTML文書内で指定します。
しかしながら、この機能には幾つも問題があります。
- リフレッシュをサポートしていない端末がある
- 日本の携帯端末は大半がサポートしておりません。
- 勝手なリフレッシュは閲覧の妨げになる
- ページを読んでいる最中に勝手にリフレッシュされては堪りません。
以上の理由から、リフレッシュは使うべきではありません。
- 日本では、携帯端末とデスクトップ端末を峻別するのにリフレッシュを使う事がありますが、これは最終手段として用いるべきでしょう。
MIMEタイプを正しく出力すべし。
- この項目は日本の携帯電話事情には合わない面があります。
MIMEタイプとは、コンテンツの型を示すデータです。
HTML文書のMIMEタイプは text/html となっておりますが、通常のXHTML文書では application/xhtml+xml とする事が推奨されております。
一方、XHTML モバイル・プロファイル文書の場合、特別なMIMEタイプとして application/vnd.wap.xhtml+xml が指定されておりますが、application/xhtml+xmlでも良い事とされております。
XHTML モバイル・プロファイルを策定したOMA(オープン・モバイル・アライアンス)では、在来HTMLの型である text/html も認める事を求めておりますが、W3Cでは text/html はなるべく使わないように求めております。
以上の点から、以下のいずれかのMIMEタイプを使用する事が求められます。
- 推奨
-
application/vnd.wap.xhtml+xmlapplication/xhtml+xml
- 非推奨
-
text/html
- これらのMIMEタイプ以外を通知して配信した場合、端末に依っては全く処理が出来なくなる恐れもあります。
- デスクトップ端末ではXHTML モバイル・プロファイルの型である
application/vnd.wap.xhtml+xmlは原則として扱えません。また、XHTML世代より前のブラウザでは、デスクトップ端末/モバイル問わずapplication/xhtml+xmlも扱えず、text/htmlで配信するしかありません。
正しいMIMEタイプを設定するにはサーヴァの知識が必要になりますが、多くのサーヴァでは、好ましくはないものの text/html を送出するようになっている筈です。
- 日本の場合、XHTML世代以前の端末がまだ残っている事などから、
text/htmlに固定されるのは已むを得ないと思われます。
正しい文字コードで配信すべし。
- この項目は日本の携帯電話事情には合わない面があります。
端末はサーヴァにコンテンツを要求する際に、ACCEPT-CHARSETフィールドで対応している文字コードを通知します。
ここで指定された文字コードを使って配信しないと、文字化けなどが起こる事になります。
ただ、日本ではｉモードなどが仕様でシフトJISコードを指定しており、ACCEPT-CHARSETフィールドを送信しない端末もありますので、静的なコンテンツの場合にはシフトJISコード限定としたコンテンツ作成は已むを得ないでしょう。
尚、XHTML(を含むXML一般)では、UTF-8コードを使う事が推奨されており、海外端末も殆どの端末がUTF-8コードに対応しております。
このため、本来はUTF-8コードでコンテンツを作成して配信する事が望ましいと言えますが、日本では上記の理由からUTF-8コードは使えません。
それでも、サーヴァサイドで文字コードを変換出来るようにしておけば、海外端末にはUTF-8コードに変換する事で海外の方にも日本語コンテンツの閲覧が可能になる事が期待出来ます。
- 勿論、端末が日本語フォントを実装している事が条件ですが…。
<img>要素にはalt属性を必ず付けるべし。
<img>要素にalt属性を与えるのは基本中の基本ですが、モバイルの場合には特に有用となります。
通信料の節約のため、或いは通信時間の削減のため、画像を非表示にする事は充分予想されます。
- 日本国内では通信速度も大幅に向上し、またパケット使い放題のサーヴィスも普及しているため、それほど問題にはならないかも知れませんが、海外では依然重要な問題となっております。また、日本国内でも問題がなくなったとは言い切れません。
また、通信速度の遅い端末や、処理速度の遅い端末では、画像を表示し切るまでに時間が掛かる場合もあり、表示されるまでにテキストで情報を与えておく必要があります。
- これも基本中の基本ですが、代替テキストが不要な場合も空文字列のalt属性(
alt=""属性)を与えておきましょう。
<img>要素にはwidth属性及びheight属性を付けるべし。
デスクトップ端末では<img>要素へのwidth属性及びheight属性は必ずしも必要とは言えないとされております。
しかしながら、モバイル端末向けのコンテンツでは<img>要素にはwidth属性及びheight属性を是非与えておきたいものとされております。
理由は端末の通信速度の都合で画像を表示し切れない場合でも、表示領域を確保してそこから先のレンダリングを継続出来るようにしたいからです。
とは言うものの、日本では旧型の低解像端末や現行のQVGA端末など、端末に合わせて適切な解像度の画像を動的に配信すると言った事が行われており、そのような場合には静的なHTML文書ではwidth属性やheight属性が付けられないのは已むを得ないかも知れません。
埋め込みオブジェクトやクライアントサイドスクリプトは使うべからず。
- フラッシュやJAVAアプレットなどの埋め込みオブジェクト
- JAVAスクリプトなどのクライアントサイドスクリプト
は、サポートされない端末もあります。
- 尚、現行のXHTML モバイル・プロファイルでは<script>要素はサポートされておりません(次世代のXHTML モバイル・プロファイルで導入される予定です)。
また、これらの機能が利用出来る場合でも、端末の処理能力を奪ったり電池消耗を早めてしまうと言う問題もあります。
これらの事を考えると、埋め込みオブジェクトやクライアントサイドスクリプトは使うべきでないとさえ言えます。
どうしてもこれらの技術を使いたい場合でも、使えない環境で問題が起こらないコンテンツ作りを心掛ける必要があります。
具体的には、対応していない端末向けに代替コンテンツを記述するなどの方法があります。
- 例えば、フラッシュを埋め込む場合には、<object>要素の内容として代替コンテンツを記述しなければなりません。
デザインには小さなスタイルシートを使うべし。
XHTML モバイル・プロファイルには、<b>要素などの物理要素が導入されておりますが、これらを利用する事で確実にページの容量を増やしてしまいます。
ページを軽くするために、スタイルは全てスタイルシートファイルに纏めてしまいましょう。
- スタイルシートファイルは一度読み込んでおけば、二頁目以降はキャッシュを参照すれば良いので、同じスタイルを使い続ける限りHTML文書だけ取得すれば良くなります。通信速度が遅い端末や通信量で課金される端末では時間と費用の節約に繋がります。
スタイルシートを使うべき理由を考えれば、<style>要素やstyle属性も使わないようにすべきなのは言うまでも無い事でしょう。
また、スタイルシート自体にも容量があり、従って読込の際に通信時間及び通信料が掛かる事になりますので、スタイルシートはなるべく小さく纏めるようにしましょう。
CSSのプロパティに注意すべし。
オープンウェーヴ社端末のCSSの実装では、displayプロパティとfloatプロパティが使えません。
- displayプロパティは一部属性値は使えます。
現在、オープンウェーヴ社のモバイルブラウザは最もシェアが高い事を考えると、displayプロパティとfloatプロパティは使わない方が安全と言えます。
- 日本でもEZウェブの全端末とソフトバンクの一部端末にてオープンウェーヴ社のブラウザを採用している事を忘れないで下さい。
また、これも基本中の基本ですが、スタイルシートに対応していない環境でもリソースの閲覧には支障が出ないようにしなければなりません。
背景で閲覧を妨げるべからず。
背景の色と文字の色を明確にして、閲覧の妨げにならないようにしましょう。
また、背景画像を使う場合でも、
- それに依ってテキストが読めなくなるようではいけません。
- 背景画像が表示されない場合に読めなくなるようではいけません。
特に、携帯端末の場合、表示出来る色が限られる場合があるので、不用意に背景画像を用いると全く読めないという事態になり兼ねません。
背景画像は絶対に使うなとは言いませんが、以上の点を考慮して使うようにしましょう。
- 日本の携帯電話でも、背景画像をサポートしていない端末があります。また、CSSのサポートの問題から、CSSでの背景画像が適用されない端末もあります。
スタイルに依存すべからず。
携帯端末はさまざまな表示能力があります。
色, フォント, 文字の大きさ, 太さなど、CSSなどで指定しても、CSSをサポートしていないなどの理由に依り指定通りに表示されない場合もあります。
「赤い文字で書かれた箇所」とか「太字の箇所」等と言う表現では、内容を理解出来ない恐れが非常に高いと言えます。
横スクロール無しで閲覧出来るようにすべし。
画像の幅が大きくなり過ぎたり、テーブルを使用している場合に横スクロールが発生する事もありますが、ｉモードなど横スクロールが絶対に出来ない端末もあります。
スクロールは一方向(通常は上下方向)のみとしましょう。
- スクロールの概念の無い端末もあり得ます。この場合、ページの切替で長いコンテンツを表示させる事になります。この場合も、ページ切替だけで閲覧出来るようにすべきと言えるでしょう。
ページサイズは小さくすべし。
- この項目は日本の携帯電話事情には合わない面があります。
W3Cが定めた推奨事項では、ページサイズは最大10キロバイト以内を想定しておりますが、日本国内の端末事情を考慮した場合にはそれでもまだ大き過ぎます。
旧型機でも閲覧出来るようにするには、5キロバイトに収める必要があります。
- この点については、携帯電話キャリアの違いをご覧下さい。
画像サイズは150ピクセルズ×200ピクセルズ以内にすべし。
- この項目は日本の携帯電話事情には合わない面があります。
現在の日本はQVGA端末が主流のためこの条件は当て嵌まらない場合が多いのですが、逆に旧型の低解像度端末では150ピクセルズ×200ピクセルズでは大き過ぎるでしょう。
要は端末に合わせたサイズにしなければならないという事です。
また、画像形式としては、W3Cでは最低GIF画像とJPEG画像が使えるものと想定しておりますが、日本では逆にGIF画像が使えない端末もありますので、その点に関しても考慮する必要があるかも知れません。
- この点については、携帯電話キャリアの違い及び携帯電話向けの画像をご覧下さい。
- W3Cの文書であるにも拘らずPNG画像の実装を想定していませんが、恐らくスペックが低い携帯端末では仕様通りの実装が困難と判断されたものと思われます。実際、携帯電話でのPNG画像の実装は静止GIF画像と同程度でしかなく、仕様に準拠しているとは言い難い場合が殆どです。
表(テーブル)について。
表(テーブル)に関しては、以下の点に注意して下さい。
- 表(テーブル)をサポートしない端末もあります
- このような端末では、表の内容を前から順にインライン表示して行く事でしょう。
- 表(テーブル)が入り切らない場合があります
- このような場合、スクロールが多くなり閲覧が困難になるでしょう。
- 入れ子構造の表(テーブル)で問題が起こる場合があります
- 端末に過剰な負荷が掛かり、レンダリングに失敗する恐れもあります
- 従って、テーブルレイアウトは絶対にいけません
- テーブルレイアウトに対応出来ない端末は決して少なくないと言う事です。
可能なら、テーブルで表現されているコンテンツも、リストなどで同等の内容になるようにすると良いでしょう。
- 拙作しらぎくモバイルシステムFULLの記事に<table>要素を非対応端末向けにリスト化する方法を解説しておりますので、ご参照下さい。
アクセスキーを積極的に活用すべし。
デスクトップ端末では<a>要素などにaccesskey属性を附与しなくても余り困る事はありませんが、モバイル端末ではaccesskey属性はぜひ活用したいものです。
特に、ページの何処を見ていても利用され得る重要なナヴィゲーションリンクには、ダイヤルボタン一つでアクセス出来ると言うのは非常に便利です。
- この場合、accesskey属性の値に使えるのはダイヤルボタンに使われている数字と「#」「*」ですが、「0」「#」「*」には対応していない端末もありますので、重要度の高いリンクには「0」以外の数字を当てるようにしましょう。
- また、ボタンの意味を決めておいてコンテンツ内で一貫させると、より便利になります。例えば前のページへのリンクは「7」、次のページへのリンクは「9」などと言うようにする訳です。
外部リソースは少なめにすべし。
画像やスタイルシートなど、HTML文書以外に必要なリソースは余り多くならないようにすべきです。
これは、外部リソースの取得には通信時間や通信料などの"コスト"が掛かるからです。
具体的な値は指定されていませんが、十個未満に抑えると良いようです。
- この事から、サイト全体にわたって使い廻す事となるスタイルシートやアイコン画像などは積極的にキャッシュさせると良いでしょう。尚、HTML文書以外のリソースに関するキャッシュの操作については、サーヴァの知識が必要になります。
構造的なマークアップを行うべし。
構造的なマークアップを行う事で、スタイルシートのサポートの無い端末でも、適切にレンダリングされるでしょう。
- かつてはｉモード端末などで見出しが分かり難い端末もありましたが、最近の端末では見出しが太字で表示されたりして分かり易くなっているようです。
特に<h○>要素に依る構造化は欠かせないと言えます。
適切なタイトルを与えるべし。
<title>要素の内容は、ブックマークでも利用されます。
ブックマークの一覧には登録したページのタイトルが並びますが、大抵一行以内に収められて一行を超える分は切られてしまうでしょう。
長過ぎず、かと言って分かり難くならないように適切な表題を与えるようにしましょう。
- 初めの数文字で内容が把握出来るようにすると良いでしょう。
最低限のナヴィゲーションバーをページ冒頭に用意すべし。
モバイル端末の場合、ページ内でも手早く移動する事は困難です。
このため、ナヴィゲーションは大き過ぎないようにする必要があります。
具体的には最低限の階層に沿った最低限のリンクのみを用意すると良いでしょう。
基本的なリンクを一行で表す
と良いとの事です。リスト形式で表したくなる方もいるかも知れませんが(制作者もその一人です)、それだと複数行に及ぶためスキップするのが大変になると言う事でしょう。
また、これらのリンクにはaccesskey属性を与えておく事で、ページの何処を見ていてもボタン一つで移動出来るようになります。
特にアクセスキーでの移動を容易にするには、予めアクセスキーの機能を知らせる必要があります。
そのためにはナヴィゲーションバーはページの冒頭に置き、各リンクに与えたアクセスキーも明示する必要があります。
- 理念としては、アクセスキーはスタイルシートなどで自動的に表示されるといいのですが、残念ながらWAP 2.0のCSSの仕様及び実装ではそのような事をHTML文書への記述無しで実現する事は出来ません。
また、ページの先頭(すなわち、ナヴィゲーションバーの先頭)には、それをスキップ出来るようなアンカーを設けておくと良いでしょう。
- 但し、XHTML モバイル・プロファイルでは<a>要素にname属性を与える事は出来ず、このためid属性をフラグメントとして認識出来ない旧式のｉモード端末やソフトバンク端末では却って邪魔になるかも知れません。
ページ内のナヴィゲーションを設けるべし。(平成19年 5月27日)
ページ内の項目間の移動も、携帯電話ではかなり面倒です。
- 端末にも依りますが、スクロール用のボタンをちまちま押さなければならないものもあります。
そこで、項目間の移動を容易にするために、ページ内ナヴィゲーションを用意します。
具体的には、ページ内の各項目を<h○>要素を用いて構造的にマークアップして、すなわち、各項目には必ず見出しを付けて、各<h○>要素の直後に前後の項目に移動出来るリンクを設けます。
- このとき、アンカーは前項と次項などと言葉で表現した方が良いでしょう。つい▲と▼とか↑と↓等のような記号を用いたくなりますが、液晶表示でなら直感的に意味が判るものの、音声出力では意味が判り難い読み方をされる恐れがあります(携帯電話での音声出力に対応したコンテンツ作りもご覧下さい)。
このため、各<h○>要素には適切なid属性を与えておきます。
- id属性をフラグメントとして認識出来ない旧式のｉモード端末やソフトバンク端末に対応する場合は、<h○>要素内に適切なname属性を与えた<a>要素を入れておく事になります(XHTML モバイル・プロファイル不適合になります)。
記事の内容は最低限のものに絞り、分かり易く記述すべし。
携帯端末の容量制限だけでなく、スクロールを伴う閲覧はかなり面倒である事からも、最低限の内容に絞るようにしましょう。
また、長い文章や分かり難い言葉はなるべく使わず、手短かつ明確に表現するようにしましょう。