 |
 |
「利用者と管理者」というのを分けるのは少々奇異な種類分けかも知れません。むしろ「サイト構築者と利用者」という方が XUGJ 向けのトピックと言えるからです。しかし、あえて管理者と書くのは、業者さんなどが仕事で XOOPS サイトを構築する場合、往々にして、後の更新は発注もとの担当者というようになるからです。願わくば、この「管理者」が、身体障害者であってもよい、というようにできないでしょうか。どんな業者さんであっても、XOOPS でサイトを作ったら、身体障害者の雇用が産まれる、というようになればということを目指してみたいと思います。
では具体的にはどこをいじるのか、という話しになります。XOOPS で管理者側ということですと、やはり管理画面がひとつの焦点になります。X2 の時代は、左側のモジュールアイコンたちは alt なしで、かつサイトによって数が違うので、メニュースキップなしには音声利用環境にとって使いづらいものでした。しかし XCL になってからは、この部分が文字で提供されるようになり、音声利用環境でも意味が取得でき、かつ晴眼者のユーザビリティも向上したように思われます。
が、管理画面という概念は、ひとつのサイトにふたつの種類の構造を持たせるというものなので、二つの画面について操作を理解していく必要というのが出てきます。つまり構造の種類が一つになってしまえば、覚えることも減る、と考えうるということです。それをするためのテクニックがGIJOE さんの管理画面を通常テーマで表示（X2用）です。
これはこれで試してみると面白いですし、管理画面でも、通常画面でも両方に対応できるテーマを作ろう、と意欲を燃やすのもアリなんですが、ただ、これも理由なく二つの種類の構造になっているわけではないのでなかなか大変なことも出てきます。そこで別の解としては、管理画面用テーマを丁寧に作る、というものだと思います。
正味な話 XCL であれば、alt なしモジュールアイコンの森もないし、管理画面も smarty テンプレートで自由自在ですし、アクセシビリティというか、障害者による更新／管理を考えるのであれば、「慣れてもらう」というのが、メンテナンス性が高いといえるかもしれません。
ブログ系モジュールや、静的コンテンツモジュールの中には、記事編集などの際、あまり管理画面に遷移しないで操作できるものもあります。こうなってくると、やはりフォームをどう作り込んでいくかということになってきます。幸い最近のモジュールは、記事編集画面もテンプレート化してくれているものもあり、こういう場合であれば基本的には、利用者側への配慮と同じです。適切な label 要素を用いてマークアップすることで、格段に記事編集が容易くなります*1。
JIS X 8341-3 には、制作者からすると、ちょっと勘弁してくれという項目があります。
b.日本語のページでは、想定する利用者にとって理解しづらいと考えられる外国語は、多用しないことが望ましい。使用するときは、初めて記載する時に解説しなければならない。
c.省略語、専門用語、流行語、俗語などの想定する利用者にとって理解しにくいと考えられる用語は、多用しないことが望ましい。使用するときは、初めて記載されるときに定義しなければならない。
d.想定する利用者にとって、読みの難しいと考えられる言葉（固有名詞など）は、多用しないことが望ましい。使用するときは、初めて記載されるときに読みを明示しなければならない。
なんともかんとも、サイトを管理しようというのであれば、どうしても限界があります。
ただそもそもこの項目は、あまりサイト管理者側を想定した項目であるとはいいにくいと考えられます。ある程度は勉強も必要ですし、ね。
最近は巷のブログなどでも、JavaScript による wysiwyg*2入力支援機構が用意されていることがほとんどです。これらの入力支援機構によって、ブラウザ上であるにも関わらず、ワープロソフトのような使用感でページ情報編集が可能になります。これはある意味、情報発信のバリアを非常に下げる画期的な技術です。
しかし、非常に悩ましいのですが、音声利用環境とはどうしても相容れない部分があります（音声と JavaScript について）。場合によっては、 HTML を生書きできる方が、音声で更新している人にとって使いやすい場合もあるということです。くわえて、この部分はどうしてもモジュール作者の方々に、お願いする部分もあり、テーマ／テンプレート作家では、いじるのが難しい部分にもなります。
たしかにプアな環境に基準を寄せた方が、利用者は増えますが、でも、XOOPS はオープンソースアプリケーションで、新しい技術を目指していくのは、その宿命と言ってもよいはずです。UA の進化に期待しつつ、また、この機能があることで利便性を増すユーザが確実にいることも意識に入れつつ、でも、後方互換として、JavaScript の入力支援がないとどうしようもない、という状況を避けられるとよいのですが……。
