2018年9月25日(火) 22:25 JST

GeeklogのFCKeditor重い・・・

印刷用ページ
Geeklog このサイトはGeeklog Japaneseで作ってるんですが、まつわるお話もポツポツ書きます。

記事作成用にWYSWYGエディターが付いててFCKeditorっていうんだけど、これ重いです。
こんな記事もありました。bkmark.net/article.php/GeeklogEditor MTのエディタもそれなりに重いけど、写真のuploadをエディタからすると時々freezeしちゃうし、記事書いてる途中でアドバンスエディタモードからhtmlエディタモードに切り替えると記事が凍りつくことがあるし、改善してほしいモンです。こういうところが普及の足枷になっているんじゃないか??米国のgeeklog本家ではver 1.5.0が出て日本公式では日本語版の準備に忙しいようだけど、こういう基礎性能の向上も忘れちゃいけませんね。

携帯SEO tips

印刷用ページ
この記事、すごく役に立つのでコピーさせていただきます。
http://buzz.dendrocacalia.com/2007/01/3_seo.html

最初に注意しておきたいのは、公式サイト内での順位上げ手法と検索エンジン対策はまったく異なるということです。
公式サイトにおいては、キャリアによって程度の差はあれど「直近3ヶ月のユニークユーザ数」というのが最重要ポイントになってきます。
そのため、クリック毎にポイントが加算されるタイプの賞金サイトやメルマガ、多少下品な手法も用いるアフィリエイトなどで、とにかく一度サイトを「踏んでもらう」のがメインの手法になってきます。
登録してもらって毎月300円の課金を得ることが主目的になるサイトが多く、ほとんどのユーザは登録したことも忘れて毎月払い続けるため、リピート率などもそれほど気にしません。
こういった「今月は○×万円で△クリックくらい買う」という発想を続けてきたサイトにとっては、地道なクローラー対策はなかなか馴染み難いものでしょう。

基本的に、携帯サイトにおけるSEOもPCにおける手法は大筋で活用できます。
そして、特にAuのGooglebotでは「人間にとって見やすいサイトが、検索エンジンにとっても好ましいサイト」というポリシーは引き継がれているようです。
とはいえ、前回も挙げたようにキャリアが検索広告ビジネスを捨てたわけではありませんし、小さな携帯端末特有の仕様や癖は存在します。
以下に、それらのTipsを思いつく/メモとして書き留めておいたままに列挙しておきます。

XHTMLで論理構造的に記述する
従来のサイトですと、CHTMLやHDML、WAPなどで記述して(あるいはそれらを動的に切り替えて)いるサイトが多いかと思います。
しかし最近は多くの端末がXHTML+CSSに対応するようになっており、2006年6月の米国データではありますが、実に81%のユーザが XHTML対応の端末を使っているという統計データもあります。携帯先進国である日本ではこの数値は更に高いでしょうし、インターネットアクセスをするようなアクティブなユーザを対象にすれば、この数値は更に上がると思われます。
携帯クローラーもXHTMLを好むらしく、昨年12月に行われたSearch Engine Strategies ConferenceでもYahoo!のPaul Yiu氏やGoogleのSumit Agarwal氏をはじめ、ほとんどのパネラーが口をそろえてXHTMLによる記述を薦めていました。
XHTMLはHTMLなどと同じSGML系の構造ですが、文法が遥かに厳密なためコーディングには気を使うかもしれません。しかし、それだけにコンピュータには理解しやすくレンダリングも高速なため、是非ともリニューアルなどの際には乗り換えたいところです。

論理構造とCSSの利用

テーブルに頼ったり、列挙するのに「・」と改行で行ったりするのは止めましょう。
見栄えを満たすためだけのHTMLから、論理構造に外部ファイルのCSSでデザインを当てるスタイルへ変えることは大きなメリットがあります。
論理化することで、クローラーにコンテンツの部分部分の意味を伝えやすくなります。
また、デザインを外部ファイルにすることでページサイズを軽量化することができます。
CSSはできるだけサイト全体で共通のものが使えるようにしておけばメンテナンス性も上がりますし、端末にキャッシュされれば毎回読み込む必要がなくなり快適なページ遷移を提供できます。
更に、http user-agentやhttp accept、UAProfなどから端末を判別して画面サイズにあわせたCSSを送るなどすれば、テンプレート全体を複数用意したりすることなく端末に最適なデザインを提供することも可能です。

短いコンテンツ、簡潔なタイトル
ユーザに負荷をかけないため、PCよりもかなり短いコンテンツを書くことを心がけましょう。
携帯端末のSERPに出るタイトルやスニペットも当然かなり短いため、見せたいキーワードを極力前にもってきて短く簡潔な言葉で伝わるようにする必要があります。
また、携帯検索エンジンに入力される単語も短いものになる傾向があるため、例えば「ポピュラーミュージック」よりも「ポップス」などのように、短く口語的な言葉に置き換えるのも有効です。

W3Cの携帯標準規格に準拠
W3Cで定めたガイドラインにしたがって記述することは非常に効果的です。
人の目に触れる以前にクローラーに理解されなくては意味がありませんし、整形されて書かれたコードは複数の端末でも期待通りにレンダリングされる可能性が高くなります。
是非とも熟読して、きちんとしたコードを書くよう留意しましょう。
Mobile Web Best Practices 1.0

検索エンジンに存在を知らせる
いくら丁寧にコードを書いても、サイトの存在をクローラーに知ってもらわなければ意味がありません。
GoogleならばWebmaster ToolsのMobile sitemap.xml、Yahoo!であればこのページなどから検索エンジンに通知しましょう。
また、もし既にPC用のサイトを持っているならば、そこからリンクを貼るのも有益です。
プレスリリースなどからリンクを貼るなど、機会を見つけて積極的にリンクを出しましょう。
サイトのトップページにサイトマップへのリンクを付けるなど、サイトが隈なくクロールされるようにすることも大切です。

携帯サイトにおけるSEOはまだまだ黎明期であり、未検証の情報やオカルトに近い手法が流れているのもしばしば眼にします。
ここには、極力オフィシャルに近いところで得た情報や実体験に基づくもの、PCで同様の手法が確立されており害にはならないであろうものを選んでいるつもりですが、「恒久的な必勝法」のようなものではないので、導入の判断は自己責任でお願いします。
ただ、現時点でクローラーがペナルティを課さないからといって、クローキング紛いの手法や隠しリンク、altによるキーワード羅列などを薦めてくるコンサルタントもあります。そういったblack-hatなやり方は、ある日突然八分にされるかもしれません(自分は必ずそうなると思っています)。特に携帯を専門でやってきて、PCでのSEOに疎いサイト運営者は、充分に危険性を確認して必ずしも鵜呑みにしないよう注意しましょう。

ここでは言い換えると完全にwhite-hatな、SEOというよりもサイト作成の心得に近いものの紹介になります。(裏技的なものを期待されている方が居れば申し訳ありませんでしたが、本質的にユーザを幸せにしない手法等を紹介していくつもりは他の記事も含めて全くありません)

文字エンコーディングをきちんと指定する
文字コードの自動判定は曖昧なもので、特に携帯サイトのように1ページあたりの情報量が少なくなると判別が難しいケースも出てきます。
せっかくクローラーを呼び込めても全て文字化けでは意味がありませんので、エンコードは必ず指定しましょう。
DoCoMoの絵文字対応もありShift_JISを使っているサイトも多いのではないかと思います。まともなWeb開発者にとっては気持ち悪いかもしれませんが、現時点ではクローラーもSJISを正式対応にしているところが殆どですので、そのまま見せましょう。
ただしその絵文字ですが、バイナリで入力している場合はauなどで文字化けすることがあります。可能な限り16進のエンティティコードで入力するようにすべきです。(ページサイズの問題もありますが、ちゃんと表示されることが優先でしょう)

携帯用のサブドメインを作り、URLはシンプルに短く

構造的にPC向けのサイトと携帯向けのサイトが混在してしまうと、robots.txtなどでクローラーに棲み分けを知らせるのも大変になってきます。
ここは可能であれば、携帯用のサブドメインを作って独立したサイトとしてシンプルに立ち上げましょう。
端末によっては、少し長いURL(100bytes程度)でエラーを返してしまうものもありますし、QRコードも文字数(=情報量)が多くなると読み取りにくくなったりサイズを大きくする必要が出てきたりします。
サブドメイン名から含めてURLは極力短く、シンプルなものになるよう心がけましょう。

ソース上の順番に気をつける
たとえばページがグローバルナビゲーションメニューとメインコンテンツから成る場合、デザイン上はナビゲーションを前(左上に近い方)に配置したかったとしても、ソースコード上できる限りメインコンテンツを前に書くようにしましょう。
クローラーが上部のコンテンツを重要視するという噂もありますが、何よりもSERPのスニペットにコンテンツの方が表示される可能性を高める意味で重要です。
コードブロック上は重要なコンテンツを前に置き、デザイン上の要件はCSSで賄う形にすることをお勧めします。

全てのページにトップから3クリック以内でアクセス可能にする
単純にユーザビリティを考えても、DLに時間もコストもかかる携帯サイトにおいてはサイト構造を浅く作ることにPC以上に気を使うべきです。
階層の浅さはクロールを容易にする上でも重要です。
ページ数が増えて分類上難しかったとしても、サイトマップを用いるなどして最低限3クリックで辿り着けるルートを用意しましょう。

携帯用SBSやRSSを利用する
PC市場において既に円熟期から衰退期に入りかかっている感もあるSBSやRSSですが、コンテンツ内容をつまみ食い的に得る特にRSS Readerの仕組みは、実は携帯市場にこそ最も適しているのではないかと思えます。
SBSやRSS Readerに登録してもらうことは、被リンクを増やすというSEO的観点でも単純にユーザの眼に触れる機会を増やすというマーケティングの観点でも有益です。
RSS Readerにより定期的な訪問者が増えることは、公式サイトの順位上げにも役立つでしょう。
登録用のアイコンなどを配置し、積極的に登録してもらうことを促しましょう。

繰り返しになりますが、現時点での携帯検索市場は「よちよち歩き」の段階です。
逆に言えば、今であれば少しの工夫ですぐに上位表示されるサイトを作ることが可能でしょう。
しかし、SERPの上位は公式コンテンツが占めていることを忘れてはいけません。
第2回で書いたように、キャリアがこのビジネスを完全に手放すわけではない以上「公式サイトの優遇」は続くでしょうし、キャリアが独自に始めるサービスにおいてはそれが最優先にされるであろうことは確かです。
順番として

1. サイト自身のサービス
2. PPC系の広告
3. 公式サイト内での検索結果
4. 勝手サイトの検索結果

となるようであれば、いくら勝手サイトで1位になっても実質的には10位以下ということにもなってしまいます。(携帯でのSERPにおいて、ページをどのくらい下までユーザがスクロールダウンするかは検証が必要ですが、そう下までは見ないでしょう)
結局のところ現時点では、SEOよりも公式サイトとして認められること、そしてSEMに重きを置く方が効果は高いように思います。(ここまで書いてきて、こんな結論ですみません)
しかし、今後検索市場が円熟化してきた時に立ち遅れないため、今のうちからSEOを意識したサイトを構築することが無駄だとは思いません。
しつこいようですが、「検索エンジンにとって良いサイトはエンドユーザにとっても良いサイトである」と信じて、良質の携帯ページを作るためのTipsとして扱ってもらえれば幸いです。

携帯キャリアのIP

印刷用ページ
携帯キャリア iモードセンタのIPアドレス帯域

2006年9月更新
WEBアクセス時 (iモードブラウザ)

* 210.153.84.0/24
* 210.136.161.0/24
* 210.153.86.0/24
* 注意:全てのiモード対応端末
* 注意:2006/10/23 より、「210.153.86.0/24」のIPアドレス帯域が追加となります。


WEBアクセス時(フルブラウザ)

* 210.153.87.0/24


注意:大規模災害などでiモードセンタが故障した際は、WEBアクセス時(iモードブラウザ)と同じIPアドレス帯域からのアクセスとなる場合があります。

メール送信時(インターネット⇒iモード対応携帯電話)

* 203.138.180.0/24
* 203.138.181.0/24


メール受信時(iモード対応携帯電話⇒インターネット)

* 203.138.203.0/24


注意iモードメール、iモーションメール、iショットメール利用の場合
注意:ある1台のiモード対応携帯電話より連続してWEBサーバにアクセスした場合、通知される送信元IPアドレスはアクセスのたび異なる場合があります。
注意:お客様に快適にご利用いただくため、IPアドレスは上記帯域の範囲で予告なく変更させていただきますので予めご了承願います。但し、帯域が追加される場合は本ページ上にて周知させていただきます。
注意:本情報はあくまでも目安としてご参照ください。iモードセンタ以外から本IPアドレスでのアクセスがない事を保証するものではありません。
http://www.nttdocomo.co.jp/service/imode/make/content/ip/


SoftBank
■ IPアドレス帯域について--ゲートウェイのIPアドレス帯域
ソフトバンク携帯電話から、インターネット経由でウェブサーバにアクセスする際、ウェブサーバ側に通知される送信元のIPアドレスは下記の帯域内アドレスとなります。
202.179.204.0/24
202.253.96.248/29**
210.146.7.192/26
210.146.60.192/26
210.151.9.128/26
210.169.130.112/29**
210.169.130.120/29**
210.169.176.0/24
210.175.1.128/25
210.228.189.0/24
211.8.159.128/25
2006年11月17日現在(**は12月20日に追加されるIPアドレス帯域)
※ソフトバンク携帯電話から通知される送信元IPアドレスは、同一の端末であってもアクセスの度に異なる場合があります。
※サービス向上の為に、ゲートウェイは予告なく増設させていただきますので予めご了承願います。帯域が新規に追加される場合は、本サイトにてお知らせいたします。
※本情報はあくまでも目安としてご参照ください。ゲートウェイ以外から本IPアドレスでのアクセスがない事を保証するものではありません。
http://developers.softbankmobile.co.jp/dp/tech_svc/web/ip.php

EZweb
EZweb端末は、EZサーバを経由してWebサーバにアクセスします。その際、Webサーバに対してEZサーバのIPアドレスがリクエスト要求元のIPアドレスとして通知されます。
■EZサーバのIPアドレスは、次表の帯域内のIPアドレスとなります。

2007年6月12日現在
210.169.40.0/24
210.196.3.192/26
210.196.5.192/26
210.230.128.0/24
210.230.141.192/26
210.234.105.32/29
210.234.108.64/26
210.251.1.192/26
210.251.2.0/27
211.5.1.0/24
211.5.2.128/25
211.5.7.0/24
218.222.1.0/24
61.117.0.0/24
61.117.1.0/24
61.117.2.0/26
61.202.3.0/24
219.108.158.0/26
219.125.148.0/24
222.5.63.0/24
222.7.56.0/24
222.5.62.128/25
222.7.57.0/24
59.135.38.128/25
219.108.157.0/25
219.125.151.128/25
219.125.145.0/25

※ EZサーバから通知されるIPアドレスは、同一のEZweb端末を使用してもアクセスのたびに異なる場合があります。
※ EZwebサービス向上のため、EZサーバは予告なく増設させて頂きますのでご了承ください。なお、帯域が新たに追加される場合には、本ページ上にて周知させて頂きます。
※ 本情報はEZサーバ以外のホストによる上記表のIPアドレスでのアクセスがないことを保証するものではありません。

携帯クローラ

印刷用ページ
crawler 2007年9月情報

Googlebot-mobile:

66.249.66.97
66.249.65.167
Nokia6820/2.0 (4.83) Profile/MIDP-1.0 Configuration/CLDC-1.0
66.249.66.69
66.249.66.79
DoCoMo/1.0/N505i/c20/TB/W20H10
CHTMLインデックスは DoCoMo googlebot-mobile, XHTMLインデックスは Nokia googlebot-mobile という役割分担があるらしい。
# DOCTYPEはchtml, xhtmlの両方のインデックスでインデックスされるためにするのがよい。CHTMLでインデックスさせるにはDOCTYPEをCHTMLにするか設定しないのがよい。XHTMLではインデックスされるにはDOCTYPEが必要。DOCTYPEでXHTMLと明示的に記述していないとインデックスされない
# CHTMLインデックスとXHTMLインデックスは切り離されている。DOCTYPEを出し分ければ(もしくは)にすればひとつのページをCHTML, XHTML両方でヒットさせることが可能
66.249.73.20 KDDI-CA33 UP.Browser/6.2.0.10.4 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)"

Yahoo:

* DoCoMo/2.0/SO502i

(compatible; Mozilla 4.0; MSIE 6.0; yahooseeker-jp-mobile AT Yahoo!JAPAN)
12/JUN/06より変更?
KDDI-CA23 UP.Browser/6.2.0.5 (compatible; KDDI-TS24 UP. Browser /6.0.8.2 (GUI) MMP/1.1; yahooseeker-jp-mobile AT Yahoo!JAPAN )
ホスト名: dev0{1,2}.bsearch.bbt.yahoo.co.jp
dev01.bsearch.bbt.yahoo.co.jp→202.93.76.90
dev02.bsearch.bbt.yahoo.co.jp→202.93.76.91


* Y!J-SRD

IP: 124.83.159. 203.216.197.xxx
UserAgent
J-PHONE/4.3/V603T
J-PHONE/2.0/J-SH03
J-PHONE/3.0/V403SH
DoCoMo/2.0/SO502i
DoCoMo/1.0/SO506iC
KDDI-CA23 UP.Browser/6.2.0.5

* Y!J-MBS


* Y!J/1.0

IP: 211.14.8.2xx

* lwp-trivial/1.41(cr0x.wap.search.mud.yahoo.comでやってくる)

IP: 209.191.126.xxx

* Yahoo Seeker

IP: 66.94.229.146 66.94.233.75 66.196.93.xxx 68.142.195.xxx 216.109.126.143
UserAgent:
KDDI-TS24
J-PHONE/2.0/J-SH03
DoCoMo/1.0/SO502i



IP: 209.191.126.182
HOST: cr06.wap.search.mud.yahoo.com
UA: lwp-trivial/1.41
ちょっとあやしいが、多分ホントのYahoo。様子見・・・。
参考:http://pulltab.info/seo-1/

DeNA moba-crawler

202.238.103.126, 202.213.221.97
User-Agent:
DoCoMo/2.0 N902iS(c100;TB;W24H12)(compatible; moba-crawler; http://crawler.dena.jp/)
robots.txt対応

Ixen/SeafTyy
クローラIPは非公開?
UA: (CA.MOBILE crawler;http://seaftyy.jp/q?i=bot)

Yicha
クローラIP非公開?
Yicha自体のIPは220.192.0.0 - 220.207.255.255
この中のどれかと思われる

キャリア別技術情報ページ

印刷用ページ

docomo
http://www.nttdocomo.co.jp/service/imode/make/
AU
http://www.au.kddi.com/ezfactory/tec/
softbank
webコンテンツ開発ガイド(ソフトバンクxhtml等)
creation.mb.softbank.jp/


  • コメント (0件)
  • トラックバック (0件)

apache status code

印刷用ページ
apache status code

コード 内容
100番台は情報
100 Continue
101 Switching Protocols
200番台は成功
200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content
300番台は転送
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
303 See Other
304 Not Modified
305 Use Proxy
400番台はエラー(アクセスする側の問題)
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Time-out
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Request Entity Too Large
414 Request-URI Too Large
415 Unsupported Media Type
500番台はエラー(アクセスされる側の問題)
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Time-out
505 HTTP Version not supported

refererとUA

印刷用ページ
某公式サイトの場合のケーススタディです。

LOGから見るキャリア別refererの取れ方

ezweb: 30%くらい取れる
imode: ほとんど取れない
softbank: 50%くらい取れる

LOGから見るキャリア別UserAgent情報の取れ方

ezweb: だいたい取れる(数字再調査要)
imode: だいたい取れる(数字再調査要)
softbank: ほとんど取れない


Mobile Web Best Practice

印刷用ページ
原文は英語です。長いな^^;
日本の携帯では無理なことも結構ありますね。
参考にしたのはこちら↓。
http://www.odysseygate.com/archives/664

1.[テーマの一貫性] あるURLにアクセスして得られるコンテンツは、異なるデバイス(PCでもケータイでも)でアクセスしてもテーマ上一貫性のあるものであること。

2.[ブラウザ性能] 洗練されたユーザ体験を提供するべく、デバイスの性能を十分に引き出すこと。

3.[不完全性] (デバイスの)不完全な実装に対して程よい対処策をとること。

4.[試験] エミュレータと同様に(デバイスの)実機でもテストを実行すること。

5.[URI] (ケータイで長いURIを打つのは大変なので)URIは短めに。

6.[ナビバー] ページのトップに置くナビゲーションは最低限に止めること。

7.[バランス] ページに膨大な量のリンクがあると、ユーザは見たいもの(コンテンツ)にたどり着くまでに膨大な量のリンクをスクロールしないといけなくなる。このトレードオフを十分に考慮すること。

8.[ナビゲーション] 一貫したナビゲーションを用いること。(そうすればユーザはそのサイトのナビゲーションの仕組みを用意に理解できる)

9.[アクセスキー] ナビゲーションメニューのリンクにアクセスキー(ケータイなら0~9とか)を割り当てること。

10.[リンクターゲットID] それぞれのリンクのターゲットを明確にすること。

11.[リンクターゲットのフォーマット] デバイスが(表示や再生を)サポートしていないこともあるので、リンク先のファイルフォーマットには注意すること。

12.[イメージマップ] デバイスが十分にサポートしていない可能性があるので、イメージマップは使わないこと。(ほとんどのケータイにはポインティングデバイスはない)

13.[ポップアップ] ポップアップや別窓表示は避けること。ユーザにそれと知らせることなく現在のウィンドウを変えたりしないこと。

14.[自動遷移] 自動遷移ページは作らないこと。自動遷移をユーザに知らせないなら、遷移を止める手段を用意すること。

15.[リダイレクト] 自動的にページをリダイレクトするようなマークアップはしないこと。代わりにHTTP 3xxコードを用いることでリダイレクトするようにサーバーを設定すること。

16.[外部リンクリソース] 外部リンクしたリソース(ファイル)は最小限に止めること。(ケータイではダウンロードに時間がかかるため)

17.[適切さ] コンテンツ内容はモバイルでの利用に適したものとすること。(モバイルでの利用においてユーザはまず役立つ情報を求めている)

18.[明瞭さ] はっきりとシンプルな言葉を使うこと。

19.[限度] ユーザが求めているものに内容を限定すること。

20.[使うのに便利なページサイズ] 使いやすさは残しつつも、適度なサイズまでページを分割すること。

21.[ページサイズの限度] ページ全体のサイズは、デバイスのメモリ制限にあったものにすること。(ケータイでダウンロードできるページサイズは限られている)

22.[スクロール] 二方向へのスクロールを避けられるなら、ページのスクロールは一方向とすること。

23.[中心的意味] ページの中で中心となる要素は、そうでない要素よりも先に配置すること。(ページのトップのリンクはメタに止め、コンテンツが先に読めるように)

24.[スペーサー画像] スペース調整のための画像(スペーサー)は使わないこと。

25.[大きな画像] デバイスがレンダリングできない画像は使わないこと。それを使わないといけない重要な情報があるのでなければ、巨大あるいは高解像度の画像は避けること。

26.[色の使用] 色がないと伝えられない情報は、色がなくても伝えられるようにすること。(モノクロ液晶のケータイの人も…まだまだ要るはず…)

27.[カラーコントラスト] 前景色と背景色は十分(視認できる)コントラストがある組み合わせとすること。

28.[背景画像可読性] 背景画像を使うときはデバイスでコンテンツが読めるように使うこと。

29.[ページタイトル] ページタイトルは短く、かつ内容が分かるようにすること。

30.[フレームダメ!] フレームは使用禁止。

31.[構造] 論理的な構造を示せるマークアップ言語を使うこと。(HTMLとか)

32.[テーブルタグのサポート] デバイスがテーブルタグをサポートしていると分からないのであれば、テーブルは使わないこと。

33.[テーブルのネスト] テーブルはネスト(入れ子に)しないこと。

34.[テーブルレイアウト] テーブルレイアウトはしないこと。

35.[テーブルの代わり] もし可能であるなら、テーブルの代わりとなる見せ方をすること。

36.[非テキスト要素の代わり] あらゆる非テキスト要素には代わりとなるテキストを用意すること。

37.[オブジェクトかスクリプト] 埋め込みオブジェクトやスクリプトには頼らないこと。

38.[画像サイズの特定] 画像に固有のサイズがあるなら、マークアップで画像サイズを特定すること。

39.[イメージリサイズ] 画像に固有のサイズがあるなら、サーバーで画像サイズをリサイズすること。

40.[VALIDなマークアップ] 公式の文法に従ってドキュメントを作成すること。

41.[単位] マークアップの属性値やスタイルシートの属性値の単位にピクセルや絶対値を使わないこと。

42.[スタイルシートの使用] デバイスがスタイルシートをサポートしているなら、レイアウトや見せ方にスタイルシートを使うこと。(日本のケータイはまだあんまり対応してないですけどね…)

43.[スタイルシートサポート] 必要ならスタイルシートがなくても読めるようにドキュメントを構成すること。

44.[スタイルシートのサイズ] スタイルシートは小さく。

45.[最小化] 簡潔かつ効率的にマックアップすること。

46.[コンテンツフォーマットサポート] デバイスでサポートされているフォーマットでコンテンツを提供すること。

47.[より好まれるコンテンツフォーマット] もし可能なら、より好まれているコンテンツフォーマットで提供すること。

48.[文字エンコードサポート] デバイスがサポートしている文字エンコードでもってコンテンツをエンコードすること。(UTF-8に対応しているケータイのほうが少ないですけどね…)

49.[使用した文字エンコード] 使用した文字エンコードを示すこと。

50.[エラーメッセージ] 手助けとなるエラーメッセージと、エラーメッセージから有用な情報へとナビゲートする手段を提供すること。

51.[クッキー] クッキーの利用に頼らない。(日本のケータイは対応してませんね…)

52.[キャッシュ] HTTPレスポンスにおけるキャッシュ情報を提供すること。(日本のケータイでは無理なような…)

53.[フォント] フォント関係のスタイルに頼らない。(…めっさメーカー依存ですしね…)

54.[キーストロークを最小限に] キーストロークは最小限に止める。

55.[フリーテキストを避ける] 可能であれば、textareaやinput type=”text”は避けること。

56.[デフォルト値を使う] 可能であれば、あらかじめ決められたデフォルトの値を使うこと。

57.[デフォルト入力モード] デバイスがサポートしているのなら、デフォルトの入力モードを決めること。(住所はかな漢字、郵便番号は半角数字って感じに)

58.[タブ順序] (tabindexを使って)リンク、フォームのコントロールとオブジェクトに論理的な順序を儲けること。

59.[ラベルコントロール] labelとformとを関連付けてすべてのformを適切にコントロールすること。

60.[位置の調節] labelの位置はそれらが参照するformコントロールに関して適切にレイアウトされていること。