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

ウェブバリアフリーの基礎情報 anchor.png

ページ内コンテンツ
Page Top

能書き anchor.png

多数に向けて情報を発信する「マスメディア」のなかでも、インターネットというのはとにかく発信コストを抑えることができます。「かけたお金」と情報の広まりは決して正比例せず、むしろ「情報の価値」が、情報の広がりに比例します。インターネットが、情報の複製・加工・授受に優れた、「デジタルデータ」を用いたものだということが、このメディアの性質に影響を与えていると思われますが、デジタルデータで情報を遣り取りすることで、もうひとつの大きな恩恵として得られるのが情報バリアフリーです。
デジタルデータ、とくにテキストデータは、ユーザエージェント次第で様々な形に加工ができます。たとえば情報の受け手側で、機械翻訳できるとか、文字のサイズを拡大縮小できる、というのもその一つでしょうし、全盲視覚障害者であってもテキストデータを音声化する装置があれば、情報取得できるというものデジタルデータならではのことでしょう。
せっかくこういうメディアなのですから、ワンソースマルチユースの理想に沿った形で作っていければ、ひとつの形として作ったウェブサイトが、利用者のニーズごとに形を変えて使うことができるようになります。

Page Top

XOOPS Cube Legacy(XOOPS)とバリアフリー anchor.png

XOOPS は、一言でいえばコミュニティサイト構築 CMS だと言えるとおもいますが、「コミュニティサイト」というのは、テキストデータを大切にしないと遣り取りが難しいので、テキストデータが主体の仕組みになります。だから実を言うと、XOOPS のサイトというのは、利用者側にとってみると、(このセクションの著者の主観かもしれませんが)それほど致命的なバリアを持っていることは少なく、たいていはそのまま構築しても、それなりに使える物に仕上がります。
しかし、「バリア(あるいはアクセシビリティ)」と言わずに、あえて「ハンディキャップトユーザのユーザビリティ」という視座を持ち出してみるとそれなりに工夫できるポイントもあります。ので、この番外編では、わりと XOOPS サイト構築に焦点を絞ってカスタマイズについて書いてみたいと思います。

Page Top

情報バリアフリーの基礎知識:規格・ガイドライン anchor.png

まずは情報バリアフリーについての基礎知識を下記します。
ふたつの代表的な仕様があります。

WCAG(Web Content Accessibility Guidelines)
インターネット上の情報発信規格標準化推進団体 W3C のなかの WAI(Web Accessibility Initiative)のもとで策定された具体的なガイドラインとして WCAG 1.0というものがあります。ver. 2.0 もあるのですが、基本的な要件としては 1.0 でもじゅうぶん読む価値があるので一読をお勧めします。
JIS X 8341-3「高齢者・障害者等配慮設計 指針 ‐ 情報通信における機器・ソフトウェア・サービス ‐ 第3部:ウェブコンテンツ」
いわゆる日本工業規格です。たぶん上述の WCAG を参考にして、日本語環境についての事例なども交えつつ、2006年に策定されました。官公庁のサイトなどはこれに沿った仕様に徐々に作り替えられています。規格団体で販売をしているので購入して読むことができます。
Page Top

情報バリアフリーの基礎知識:エッセンス anchor.png

基本的には「テキストデータは汎用性が高い」ということです。
デジタルデータというのは、それ自体、加工もしやすいし、汎用性も高いのですが、その中でもテキストデータというのは、とても様々な形に簡単に変えることができます。
細かいことを言っていけば、いろいろ書くこともあるとは思いますが、バックリとまとめます。

Page Top

キーボードだけで操作できるようにする anchor.png

……といわれてもピンとこないかもしれません。別の言い方をすれば、マウスなどのポインティングデバイスを使わずに閲覧や編集をできるようにするということです。音声環境利用者にとっては、マウスやタッチパッドなどは使いづらいマンマシンインタフェイスですが、キーボードであれば利用可能です。スクリーンリーダは「行読み」や「文字読み」のような機能をキーボードで操作できるように設計されていますが、ある程度の操作については、サイトの構築のされかたに左右されてきます。
代表的なのはドロップダウンリストです。<option> 要素で作ることのできるドロップダウンリストは、候補数が一定でなくても、領域としては、一定の大きさとして提供できる要素として重宝されます。たとえばメニュー項目のような場面で使えるのですが、ここでちょっと注意が必要です。
JavaScript(onchange="submit();")を利用することで、ドロップダウンリストをクリックし、目的の項目を選んだら、その項目が即座に実行される、という仕組みがよくありますが、これがじつはバリアになるのです。キーボードを使って操作してみるとわかるのですが、option要素を選んで、カーソルキーの下を押したとたんに項目が実行されてしまいます。つまり、これはキーボードだけで操作できるインタフェイスではないのです。
ちょっと泥臭い動作になってしまいますが、極力、選択→実行ボタンというプロセスを踏むように作るよう心がけましょう。

Page Top

画像ファイルには、適切な alt 属性をつける。 anchor.png

alt があれば、視覚が使えない環境でも、音声データによって、その画像がなんであるのかを取得することができます。また、回線速度の関係などで、画像を読み込まない設定していても、画像がなんなのかを取得できます*1
グラフなどはなかなか悩ましいのですが、表で表現できるようなものだったら、これを併記するなどするという手はあります。

Page Top
背景画像を用いてリンク用ボタンなどを構築するテクニック anchor.png

CSS に慣れた人であれば、このテクニックを使っている方もおられることと思います。この作り方をしておくと、たしかに構造とプレゼンテーションの分離という点では理にかなっているのですが問題があります。PC 利用環境で、画像を読み込まない設定にしていると、リンク文字列が見えなくなってしまうので、使えなくなってしまう、という点です。ここではとりあえず問題としてご紹介するにとどめておきます。

Page Top

各ページには適切なtitle要素をつける。サイト内で全部 title が同じ、とかいうのは避ける。 anchor.png

晴眼者であれば、たとえば何らかのリンクをクリックしたりすると、ブラウザのプログレスバーが動くなど、さまざまな視覚フィードバックを得られます。また、画面遷移の後も画面ががらっと変われば、自分が目的を達成したかどうかをすぐに把握できます。しかし音声利用環境では、場合によっては、ページを最後まで読まないと、「ページ遷移」という目的を達成できているのかどうかをすぐに把握できないことがしばしばあります。
しかし、title 要素をしっかりと記述することで、確認の機会が与えられ、目的と違うページにきたら、すべて読まなくても、他のページを読みに出かけることができます。また、音声リーダによっては、この title 要素を最初に読み上げるので、さらに遷移フィードバックをすばやく取得できます。
くわえてこの title 要素は Google などの検索エンジンでは、これが登録の見出しになり、かつ、title 要素中のキーワードは、インデクス順位に対して非常に重視されます。ややもすると食傷気味なほどの SEO が流行っていて、SEO といえば、なんとなく金の亡者のようにも思えてしまいそうですが、高齢者や障害を持った利用者も検索エンジンを利用します。ので、むしろ検索エンジン最適化するのが SEO だと考えて、積極的に title 要素を的確に入れていくようにした方がよいです。

Page Top

「こちら」リンクを避ける anchor.png

これはわりと XOOPS のような CMS ではおこりがちの問題です。サマリ文章を見せておいて、詳しくは「こちら」をクリックしてください……というように、詳細文章への誘導をする。デザイン的にもすっきりとまとまりやすいですし、一定の処理をする、という意味では CMS の得意な動きであると言えると思います。
しかし、視覚障害者──とくに全盲利用者は、よくページの構造把握のためや、通常のブラウジングのために、タブキーをつかったアンカー文字列スキップということをします。この際、「こちら」リンク文字列が並んでいると、いったいどこがどこにリンクしているのか分からない、ということが起こってしまいます。ので、できるだけリンク文字列はページ内でユニークになるように心がけた方がよいとされています。
しかし、じゃあ、複数のトピックが並んでいて、それを「編集」できるリンクを並べたい、と考えたときはどうしたらいいのでしょう? これはなかなか難しい問題です。いちいち「○○○○の編集」や「○○○○へ返信」とか書いてしまったら、今度は晴眼者ユーザビリティが下がります。alt に入れて img で表現という手もありますが、こういうものを画像データにしてしまうと、文字拡大縮小の恩恵を受けられなくなります。
こういうときのテクニークとしては、タブキーのアンカー文字列ジャンプの順番を考えてみるというのが手だと思います。たとえば、記事タイトル、サマリ、「編集」など、記事にたいするコントロールが、ずらずら並んでいる倍は、記事タイトルが、詳細文章へのリンク文字列になっていれば、タブキーでジャンプしていっても、記事タイトルを読み上げた後に「編集」と読み上げることになります。じゃあ、とうぜん「こちら」だって、記事タイトルも詳細へのリンクにしたらいいじゃないかとなりますが、そう思います。

Page Top

小さいクリック領域、隣接したクリック領域を作らない anchor.png

リンクできる部分が、あんまりにも小さかったり、密集していたりすると、誤操作を招きやすいということです。主に、上肢障害者など、ポインティングデバイスの操作の自由度が低い人への配慮項目です。

Page Top

リンクの下線 anchor.png

リンクの下線というのは、サイトのデザインによっては、CSS でこれをなくしてしまって、リンク文字列の色を変えることで、対応している方もおられます。が、たとえば色盲・色弱対応などを考えると、このリンクの下線というのは、結構重要な仕事をします。なるべくリンクの下線を残すようにしましょう。
ただメニュー部分などでは、デザイン構造上、そこがリンク文字列であるという視覚フィードバックが返っているので、かならずしもすべての場合に於いて、リンクの下線が必要というわけではありません。

Page Top

パンくず anchor.png

意外かもしれませんが、JIS のなかでは、サイトにパンくず機能を持たせることを推奨しています。

g.閲覧しているページがウェブサイトの構造のどこに位置しているか把握できるように、階層などの構造を示した情報を提供することが望ましい。

XOOPS の場合であれば、モジュールがパンくずを提供してくれている場合もありますが、ユーザ情報部分などのモジュール以外の場所でもパンくず対応してくれて、かつ一定の場所に置くことができる xugj_assign の利用をおすすめします。

Page Top

「新しいウィンドウを開く」ということ anchor.png

XOOPS の場合だと、プライベートメッセージなどは、新しいウィンドウを開きますね。しかし、JIS でも、WCAG でも、ユーザが新しいウィンドウを開かないという動作を意識的に選択できるようになるまでは、情報提供側で自動的に新しいウィンドウを開くのを避けるように提唱しています。近年のブラウザは環境設定で、この「意識的に新しいウィンドウを開かない」という設定項目を積んでいるものもできてきたので、状況としては、だんたんと改善されているのかもしれませんが、なぜこの項目があるのかに触れておきます。
高齢者の利用者などでは、「戻るボタンを押せばとにかく戻れる」と覚えている人もたくさんいます。この場合、新しいウィンドウで開いてしまったページからは、戻れなくなってしまう、という事態が起こります。また全盲視覚障害者の利用の場合は、新しいウィンドウが開いたことに気づかないという場合も考えられ、こういった観点から、新規ウィンドウが嫌われた経緯があります。
しかし一概に新規ウィンドウを悪者扱いもできません。たとえば何かの投稿内容を編集している。で、この書類に向かって何かを post したいという動作が挟まれるとき、なんらかの救済措置をとっておかないと、画面遷移が起こったときに編集途中のデータは消えてしまいます。しかし、別窓を開いて、新規窓で post 動作を行えば、編集画面を維持できます。編集途中の内容が消えてしまうというのは、障害の有無に関わらず、不便なものです。
おすすめの対応は、新しい窓で開くのだ、ということを文章で明示することです。これによって、新規窓を開く前に動作を確認できます。

Page Top

フレームは使用しない。 anchor.png

XOOPS で、わざわざフレームを使うということは少ないと思いますが、フレーム技術というのはなかなか正しく使うのが難しい技術です。うっかり各フレームにタイトルをつけ忘れたりなどしてしまいがちです。音声利用環境でも、フレームのサイトを使えないわけではないのですが、ちょっと注意を忘れると、1枚のフレームを読み終わった時点で「ページを読み終わった」と勘違いしてしまうこともあります。
また、また検索エンジンの話しになりますが、フレームが一枚だけ検索結果に出てしまうと、にっちもさっちもいかなくなることがあり、これも単純にアクセシビリティの問題とは言いづらいですが、気をつけていきたい点だと思います。
あとは、iframe 技術です。これも一見便利な機能なのですが、音声環境によってはここを読み上げない、あるいは読み上げ順序が狂うことがままあります。できれば避けた方がよい技術だと思います。

Page Top

文字色と背景色のコントラストに配慮する。 anchor.png

これはわりと単純な話しですね。おもにデザイナの方々にかかる部分だと思います。
「赤と緑」など、典型的な禁忌パターンもあるので、いろいろ調べてみるとよいと思います。

Page Top

読み上げ環境に配慮し、単語内に空白や改行を挿入しないようにする。 anchor.png

文字列をジャスティファイしたい場合など、つい、漢字熟語中でも改行を挟んでしまうことがありますが、これは検索エンジンにとっても、音声利用環境にとってもマイナス要素です。また、項目表示やボタンなどで、「日 時:」「送 信」ということもやってしまいがちですが、避けた方がよいでしょう。

Page Top
音声環境特有の問題 - 日付の読み上げ anchor.png

音声環境の癖なんですが、日常的に使われる「YYYY/MM/DD」というようなスラッシュ区切りの日付表記は、分数と勘違いをされて「MM分のYYYY、DD」と読み上げられたりします。音声環境利用者としてはもはや慣れてしまっている観もありますが、できれば、「YYYY年MM月DD日」と読んでくれればうれしいものです。
しかしテーマ/テンプレート作者としては、モジュールやシステムが渡してくれる日付をいじるのは、ちょっとハードルが高い場合があります。そういう場合は、xugj_date を使いましょう。柔軟な日付表示に対応できます。

Page Top

閲覧者の意図しない音声再生をしないようにする。 anchor.png

これもあんまり XOOPS 特有の話しではないですね。音声利用環境に取っては、サイトを訪れると自動的に何かが再生するようでは、操作の邪魔になります。YouTube なんかはその悪例ですね(って、裏方だから名指しで書いちゃいますが (^^;

Page Top

サイトマップや共通のメニューを設けるなどして、サイト構成を把握しやすくする。 anchor.png

晴眼者にとっても、視覚障害者にとっても、サイトのメニュー位置が一貫していると使いやすいです。XOOPS はせっかくその辺りの統一が非常にしやすい仕組みなので、意識して一貫したデザイン構築をしていきましょう。またメニュー項目をソースコード上、冒頭にまとめる場合など、余裕があれば、メニュースキップをもうけると、音声利用環境にとっては便利になることがあります。
他にも CMS ならではのことかもしれませんが、RSS の取得リンクなどがずらずら並ぶ場合などもスキップを書けると便利かもしれません(ちなみに音声環境によっては、似たリンクがずらずら並んでいたら、まとめて読み飛ばす機能を積んだ物があったと思います)。

Page Top

丸数字やローマ数字などの機種依存文字を用いない。 anchor.png

これも特筆するべきことはありません。……が、文字化け、ということについては気をつけた方がいいでしょう。あるブラウザでは化けないけど、他のブラウザでは化ける、というのは、XOOPS でなくともよくある話しですので。

Page Top

文字サイズは、閲覧者の好みで自由に変更できるように設定する。 anchor.png

これは非常にくだらない項目ですね。JIS X 8341-3 にもこの規定がありますが、IE が愚かな文字サイズ変更機構を積んだためだけに、できた項目です。もともと CSS は、情報提供者が「できればこのような見栄えで見てほしい」ということを定義する仕組みで、それを選ぶか選ばないかは閲覧者側の自由なんですが、文字サイズもその一つだと思います。ようは CSS で px や mm でフォントサイズを指定すると、IE で文字サイズ変更ができなかったというだけのことです。
まあ、悪く言うだけではなんですが、文字サイズの大小というのも、情報の一種ではあります。もちろん HTML の理想からすればマークアップですべてを表現できるのですが、文字サイズは、人間に対してその理解を助ける働きとして重要です(本文よりも、投稿ボタンなどは大きい必要はないからです)。ので、文字サイズは相対的な指定の仕方(パーセント指定など)にしましょう、というように覚えておけば大丈夫だと思います。

Page Top

レイアウト用のテーブルは、読み上げ環境に配慮して設計する。 anchor.png

もうだんだんと table レイアウトというのも廃れてきて、DreamWeaver などでも、CSS + Valid HTML のサイトが構築しやすくなってきた昨今では、この項目の意味が分からない人がいるかもしれませんね。
X2 および XCL のデフォルトテーマは table で出来上がっています。これは table レイアウトと呼ばれる手法で、HTML の table 要素がレイアウト技術に転用しやすいことから90年代の日本のインターネット創世記に盛んに作られました。主要ブラウザの中では、クロスブラウザの問題も少なく、見栄えをうまくくみ上げられるので、初心者には習得しやすいのかもしれませんが、音声利用環境に取っては、あまり好ましい物ではありませんでした。たとえば、テレビの番組表です。
音声環境では、table を左上から右下に向かって読み上げてゆきます。ので、この例であげているテレビの番組表はほとんど意味が不明になってしまいます。「レイアウト用のテーブルは、読み上げ環境に配慮して設計する。」というのは、この table 読み上げ順の特性を加味してレイアウトしなさい、ということです。
(聞く人が聞いたら怒りそうですが)ので、XOOPS に却ってみると、じつはそれほどバリアではありません。XOOPS では、ブロックごとに意味がまとまるようにできているので、よっぽど複雑にブロックを組まなければ、だいたいの場合、意味を把握できるようになっています。
でも、これから XOOPS サイトを構築していくのでしたら、table レイアウトを避けることで、たとえば携帯電話などの利用にも耐えるサイト構築ができるということもあるので、ぜひ HTML を勉強して、tableless でくみ上げていかれることをおすすめします。

  • tableless のテーマもたくさん配布されていますし(と、ここに具体例を挙げたい?)。
Page Top

見出しによる構造化 anchor.png

見出しというのは h1 とか h2 など、いわゆる heading 類のタグでマークアップされる要素です。この見出し要素は、文章の大まかな構造を作る機能から、音声環境においても便利に使うことができます。長い文章であっても、見出しによって構造化されていれば、キーボードショートカットなどで、文章中の見出しをわりと自由に行き来できるようになります。これによって、リニアな情報取得になりがちな音声利用環境でも、俯瞰的にページの内容を把握できるようになります。

Page Top

入力時間、閲覧時間に制限を設けない anchor.png

XOOPS は、セッションでログイン状況を監視しています。セッションがだらだらとのびるような仕組みになっていると、セキュリティ脆弱性になることもあり、適宜セッションを切るような機構がある方がよいと考えられます。
ただ XOOPS サイトを使っていて、長い文章を書いていたらタイムアウトしちゃったとかいう経験をお持ちの方もおられると思います。これがいわゆる「入力時間に対する制限」です。
安全な対策としては、GIJOE さんが提唱しておられるハートビート法というものがあります。
もうひとつ閲覧側の時間制限ですが、XOOPS で代表的なのは、POST 後などに表示される遷移用画面です。refresh で数秒表示されますが、かならずしもすべて読める時間というのが提供されているわけでもなく、できればなくてもよいものといえるかもしれません。
この対策としては、おなじく GIJOE さんのお手軽高速化ハック、あるいは Ryuji さんの XCL 版お手軽高速化を用いることでスマートに解決できます。

Page Top

スタイルシートがもたらすバリア anchor.png

構造とプレゼンテーションの分離のためにも、スタイルシートを用いてウェブページのデザインをすることはよいことなのですが、残念ながらまだ各ブラウザの CSS 対応は、完全であるとはいいがたい状況です。レイアウトが崩れてしまうことが、情報取得を困難にすることはままありますし、できるだけクロスブラウザチェックをかけましょう。
よくある状況としては、

  • position:absolute で指定した領域が、文字サイズ変更時に文字サイズに追従せず、他の領域にかぶさって表示されてしまう。
  • ちょっと前の IE で height 指定した要素中の文字列が、height 内に収まらないと表示されない。

等があげられます。文字サイズはクライアントサイドで変えられてしまうものだ、という前提に立ってチェックするようにしてみましょう。

Page Top

lint チェックをかけてみよう anchor.png

Another HTML-lint gatewayというオンラインサービスがあります。XOOPS でサイトを構築したら、いちどこれをかけてみましょう。本来は HTML が DTD に沿っているかをチェックするための機構ですが、じつはアクセシビリティと HTML の構文の正確さには関係があります。ユーザエージェントというのはすなわちソフトウェアなので、ソフトウェアが解釈しやすい……つまり、ただしい HTML で構築されているかどうか、というのは、そのままわりとアクセシビリティの問題に直結します。
lint の作り自体も、けっこうアクセシビリティに配慮した形のコメントをかえしてくれるので、参考になること請け合いです。

Page Top

UA(ユーザエージェント)について - 携帯電話人口の増加 anchor.png

ワンソースマルチユースの理想の先には、UA を選ばない、という目標地点があるように思われます。一つ提供しておけば、あとは、情報は利用者側の好みの形で取得される……ということです。
近年、携帯電話でウェブを閲覧するという人は増えてきました*2。主婦層や若い学生を中心に、これからはビジネスマンもだんだんと携帯電話の進化に伴って、利用者を増やしていくだろうことは想像に難くありません。しかし、そういったユーザ以外で、この項で書きたいのは、視覚障害者による携帯電話利用です。
そもそも全盲視覚障害者であれば、スピーカがあれば、PC操作などにディスプレイは不要です*3。メール、WWW が利用できるのであれば、携帯電話で十分に用件を果たせてしまいます。現在はほぼ、専用のスクリーンリーダを搭載した DOCOMO の「らくらくフォン」という携帯電話の一人勝ちの状況ですが、こと閲覧者側の携帯電話利用は、徐々に視覚障害者の間では WWW アクセスの常識になっていくと考えうります。
XOOPS にもたくさんの携帯電話対応のノウハウがあります。ぜひ、携帯電話利用にも配慮しながらサイト構築をしてゆきたいものです。

Page Top

UA について - 音声閲覧環境の一例 anchor.png

なかなか下記のような動作環境をそろえるのは難しいとは思いますが、いちおうこんなのがあるということでご紹介しておきます。WCAG や JIS を守っていれば、実験環境がなくても、だいたいアクセシビリティを確保できるので、無理にそろえようとしなくてもよいと思います。
あと残念ながら基本的に Windows のアプリケーションしかありません。Macitosh の場合は、OSX であれば、OS が標準で積んでいる VoiceOver があり、ブラウジングもできるようですが、日本語未対応です。ちなみに Vista は、標準で日本語読み上げエンジンを積んでいるそうで、これでウェブのブラウジングできるそうですが、まだその機能の利用者も少なく、あまり正体はつかめていません。

FocusTalk
会社は違いますが、事実上 XPReader の後継だそうです。ウェブ閲覧の機能が強化されているそうですが、筆者未体験です ^^;
PC Talker
上述の XPReader 系と並んでユーザの多いスクリーンリーダのようです。専用のブラウザを持っているそうですが、筆者の実感としては、IE を使ってブラウジングしている人が多いように思われます。
IBM Homepage Reader
音声でウェブを閲覧する専用のブラウザです。Ver 2 まではエンジンを選べたので、Netscape などにしている人もいました(Ver 3 以降は IE のみになったようです)。Vista 非対応を宣言したそうで、高機能ですが、利用者は減少傾向だそうです。
JAWS
一番高性能だが、もっとも高価ということで、普及率がいまいち高くないスクリーンリーダだそうです。触ったことはないんですが、office 系のアプリケーション利用時などに他のスクリーンリーダとの違いを実感することがある、と聞いたことがあります。

以上がだいたいのオーバービューです。
次からもうすこし、具体的に XOOPS サイトのアクセシビリティとユーザビリティを向上していくためのコツを書いていきます。
あと、XOOPSに特化したコンテンツではないのですが、神崎正英さんの下記ページは、アクセシビリティについて勉強する上で非常によくできていますので、一読をおオススメします。


*1 いまどきそんな低速回線はないだろう、というご意見もあるも知れませんが、携帯電話利用などもありますし、機械翻訳ができるのですから、ターゲットは日本国内だけとは限りません
*2 なぜか XOOPS 界隈の人はあまりそうでもないみたいですが……?
*3 極論ですが

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