LOGIN ID Password Auto Login Register Now! Lost Password?
XUGJ Wiki
Page Top

テーマの組み方 anchor.png

テーマの組み方の基本的な方法については、市販の書籍や、CustomizeManual を参考にしてください。
ここでは、ことアクセシビリティに配慮したテーマということで簡単に紹介します。

Page Top

読み上げ順序とメニュースキップ anchor.png

ふつうに table で組んである状態ですと、どうしても左ブロックというのは、メニュー項目などが来やすい場所になります。table で組んであると、左上から読み上げられる特性上、毎ページ、このメニューを読み上げることになります。また、場合によっては、この左ブロックに RSS 情報などをずらずら並べたりすることで、左ブロックの長さが一定でなくなることもままあり、こうなると、音声環境利用者にとっては、「一定の回数のタブを押す」というテクニックも使えなくなります。
これを回避するために JIS や WCAG で提唱されているのがメニュースキップという技法です。たとえば1ピクセルかける1ピクセルの img 要素を用意するなどして、この alt 属性に「メニューを読み飛ばす」と書いて、センターブロックにページ内リンクを作る。非常に小さい画像なので、晴眼者には意識の妨げにならず、音声環境利用者には、使いやすくなる、というものです。
しかし、テーマをイチからか書き換えることが可能な XOOPS だったら、別の解決があります。CSS をうまく用いることで、ソースコードの順番と、レイアウトの位置の関係を壊すことができるからです。これによって、<{$xoops_contents}> をソースコード上部に配置し、CSS で位置を指定してやるということができるようになります。
少々余談ですが、「左側にメニューがある」というのは、いわゆるウェブサイトデザインのひとつのステロタイプになりました。横書き文化のインターネットにおいて、左上というのが最初に目がいく位置だから、ここにメニューを置こう、というのは自然な流れだったのかも知れません。
しかし、近年になって「マウスは右手で使う人が多いのだから、メニューは右が使いやすいんでないの?」という意見も出てきました。日和見するわけではありませんが、どちらが優れた意見ということはないのだとはおもいますが、音声環境利用者にとって、わりと影響力のある意見になりました。
2007年12月現在の XUGJ のデザインはメニューが右組みになっています。この作りだと、本文から先に読み上げるので、音声環境利用者にとっては使いやすい配置になっています。なにも CSS を使えなければ、いわゆる「コンテンツファースト」にできないというわけではなく、こういう解決も選択肢になると知っておくとよいかもしれません。

Page Top

テンプレートについて anchor.png

XOOPS のすてきな点ですが、XOOPS では、機能と構造とプレゼンテーション(あとデータも)が、かなりきれいに分離されています。このおかげで高度な機能の数々をテーマ/テンプレート作者が、安全*1に組み替えて利用することができます。テンプレート編集の基礎的な方法については、これも CustomizeManual を参照してください。
各モジュールが提供してくれているテンプレートは、おおきく本文部分(<{$xoops_contents}>)に反映される部分と、各ブロック部分に反映される部分があります。
本文部分に関わる部分としては、見出しによる構造化に基づいて、なるべく h2 などを用いて構築すると使いやすくなると思われます。

Page Top

ブロックについて anchor.png

ちなみにブロックに関しても、この見出しによる構造化が一定の関わりをしてきます。むしろ「テーマ」のまとまりに書くべきかもしれませんが、デフォルトでは「blockTitle」となっている、各ブロックのタイトルを heading で構造化することによって、各機能へのアクセシビリティが向上します。各ブロックが一定の見出しの下にぶら下がるというようにまとめられれば、おのずとブロック内のマークアップも整理されてきます。

Page Top

フォーム要素を使いやすく(label について) anchor.png

詳細は HTML の書き方の本に譲るべきかと思いますが、alt 属性や title 属性と並んで、ちょっと手を加えるだけで劇的に変化するのが input などフォーム系の要素です、XOOPS の場合は、コミュニティサイトとしてこれを使う場合、大体にしてログインフォームがあります。この部分をたとえば下記のようにするだけで、ずいぶんと使いよくなります(関係の深いフォーム部分だけ抜き出します)。

@XCL - user_block_login.html

<form action="<{$xoops_url}>/user.php" method="post" style="margin-top: 0px;">
<dl>
<dt><label for="legacy_xoopsform_block_uname"><{$smarty.const._MB_USER_USERNAME}></label></dt>
 <dd><{xoops_input type=text name=uname size=10 value=$block.unamevalue maxlength=25 id="`$smarty.const.XOOPS_INPUT_DEFID_PREFIX`block_uname"}></dd>
<dt><label for="legacy_xoopsform_block_pass"><{$smarty.const._MB_USER_PASSWORD}></label></dt>
 <dd><{xoops_input type=password name=pass size=10 maxlength=32 id="`$smarty.const.XOOPS_INPUT_DEFID_PREFIX`block_pass"}></dd>
 <dd><{* <label><{xoops_input type=checkbox name=rememberme value=On class=formButton}><{$smarty.const._MB_USER_REMEMBERME}></label><br /> *}>
 <input type="hidden" name="xoops_redirect" value="<{$xoops_requesturi}>" />
 <{xoops_input type=hidden name=op value=login id="`$smarty.const.XOOPS_INPUT_DEFID_PREFIX`block_op"}>
 <{xoops_input type=submit name=submit value=$smarty.const._MB_USER_LOGIN id="`$smarty.const.XOOPS_INPUT_DEFID_PREFIX`block_submit"}></dd>
</dl>
</form>

この例ではたまたま dl でマークアップしていますが、これは何でも構いません。ポイントは label 要素です。
デフォルトの状態でも、<{$smarty.const._MB_USER_USERNAME}> と、インプット要素である<{xoops_input type=text name=uname size=10 value=$block.unamevalue maxlength=25 id="`$smarty.const.XOOPS_INPUT_DEFID_PREFIX`block_uname"}>は並んでいるので、視覚的には、これを関連づけることは容易いですが、じつは HTML 的(意味的)には、_MB_USER_USERNAME と input 要素は何のつながりも持たない状態です。
これを label によって関連づけることで、音声利用環境でも、どのインプット領域が、なにを入力するべき場所なのかを読み上げてくれるようになります。同様に検索窓などでも、label なしで用いるのでなく、「検索」というラベルを明示的に用いることで、音声利用環境でも使いやすくなります。
ちなみに label を使うことで、クリック領域の拡大の効果も得られます。

<label><input type="checkbox" />foo</label>

というようなマークアップを施すことで、チェックボックスそのものだけでなく、foo というラベル文字列も、このチェックボックスの捜査対象としてカウントされるようになります(一部ブラウザ*2では、この機能は実装されていません)。

Page Top

使えと言われていますが……? anchor.png

Page Top

tabindex anchor.png

lint は、フォーム要素があると、tabindex 属性を使うように促してきます。tabindex 属性をあてがうことで、input 要素類のタブ順序を制御できるのですが、XOOPS のように、いろんなフォーム要素がページごとにたくさん出てきうるサイトの場合、tabindex が、利用者が期待している順序以外の順序を強要する場合が出てしまい、このトピックの筆者の体験談になってしまいますが、視覚障害者の利用者からは不評が多かったです。

Page Top

accesskey anchor.png

accesskey も悩ましい属性値です。a 要素にあてがうことで、いわばウェブページがキーボードショートカットを提供することができるようになる機能なのですが、たとえばあるサイトの制作者は「Top」の T でトップページに戻ると考え、でもあるサイトの制作者は T をページの先頭に戻ると考えたりで、そこには統一を望みにくい現状があります。また利用者側からすると、サイトごとに accesskey を覚えなければならず、結局リンク先を確認しながらページ遷移を行う方向に落ち着いていく……というようです。
でも、だから使い物にならないと切って捨てるようなものでもなく、場合によっては、頻繁に利用することが想定されるコミュニティサイトなどでは、そこの流儀に慣れて、慣れてくればページスクロール動作などを必要とせずにブラウジングできるようになったりする便利な機能でもあります。
あと、特筆しておきたいのは携帯電話利用です。accesskey 属性を数字であてがっておくと、携帯電話でサイトを閲覧する際、その数字と電話のキーが連動するので、非常に便利にブラウジングできます。

Page Top

悩ましい新技術 - JavaScript と Ajax anchor.png

ウェブ制作に関わっていると、いろんな主義主張に出会うことと思います。一昔前は W3C 主義者とか、そういうのが流行った時代もありました。こういう趣味・主義の中の一つに「アンチ JavaScript」という派閥があります。クライアントサイドスクリプトは、

  • ユーザが切っている可能性がある
  • UAごとに動いたり動かなかったりする

という観点から嫌われるようです。近年はセキュリティ意識の向上から JavaScript を切ってブラウジングしている人も少なくなく、依然一定量の支持をもった派閥であるといえます。
しかし、それはさておき、ことアクセシビリティの観点から JavaScript(Ajax) について言及します。
JavaScript は、当たり前ですが、それ自体が悪では決してありません。たとえば post するまえに、JavaScript で簡易的にフォーム内容を validate することをすれば、クライアント/サーバの負荷分散にもつながるでしょう。
また小窓のところで述べましたように、Ajax をうまく使えば、編集途中のフォームの内容を維持した状態で、POST 行為を行うことが可能になったりします。
しかし、問題は document.write 系の挙動に対するスクリーンリーダの特性です。これは、もうなんというか早く UA のほうが進化するべきといいたいのですが、スクリーンリーダの中には、ページにアクセスした瞬間にページ内容をメモリに格納し、そこだけが読み上げの対象になる、というものがあります。具体的には XPReader というスクリーンリーダなのですが、これは、JavaScript があとから書き足した情報を読み上げの対象にしません。とくに JavaScript は、テーマ/テンプレート作家でも手軽にサイトを強化できる分野なので、惜しいのですが、現状では、JavaScript に致命的な情報提供を依存させない方がよいと考えれます。


*1 あまりセキュリティホールを造ってしまうことを恐れずに
*2 Safari2

トップ   凍結 差分 バックアップ 複製 名前変更 リロード印刷に適した表示   ページ新規作成 全ページ一覧 単語検索 最新ページの一覧   ヘルプ   最新ページのRSS 1.0 最新ページのRSS 2.0 最新ページのRSS Atom Powered by xpWiki
Counter: 5710, today: 1, yesterday: 0
初版日時: 2007-12-22 (土) 05:39:36
最終更新: 2014-01-13 (月) 22:06:01 (JST) (1405d) by jidaikobo
Back to Page Top
MainMenu
Manuals
Search
XOOPS Official & Dev.
XOOPS Communities