(cache) 最近一週間ほどのえび日記 | 水無月ばけらのえび日記

最近一週間ほどのえび日記

2012年3月25日(日曜日)

新・光神話パルテナの鏡クリア

公開: 2012年3月28日13時35分頃

新・光神話パルテナの鏡 (www.amazon.co.jp)、いちおうストーリーを最後まで終わらせました。

10章くらいで終わりかと思っていたら25章まであって、けっこうなボリュームでした。さらに高ホンキ度でやり直したり、未探索部分を探索したりする必要があるので、まだまだ終わりませんが。

以下、攻略のポイントと思われるもの。

「回避」がとても重要。弾も避けられますが、敵の突進や打撃を避けるのが大事で、回避できないと勝てない敵も多いです (低ホンキ度だと何とかなりますが)。攻撃しているときに回避しようとしてもダッシュ連射になってしまうので、攻撃の手を休めて回避する必要があります。
「回り込み」も重要。敵にある程度近づいた状態で、タッチペンで敵をポイントしっぱなしにして左右にはじき入力。「ある程度」近づいていれば良いので、打撃が届かない間合いでもOK。
ハートに余裕があれば、ホンキ度はちょっと高めのほうが良さそう。ホンキ度5でノーミスクリアするより、ホンキ度6で始めて1回コンティニューしてクリアする方が簡単ですし。
普通にプレイしているだけでは、神器はなかなか強くならないです。融合を活用する必要があると思われますが、もったいなくて融合ができない罠……。
「射撃」の星の数より、「立ち連射+4」などの方が影響が大きいような気がします。ダッシュ連射の強い神弓はなかなか良いです。

難易度を上げると儲かる代わりにテクニックが要求されるといううまいバランスになっているので、繰り返しプレイのしがいがありますね。

「新・光神話パルテナの鏡クリア」にコメントを書く

関連する話題: ゲーム / 任天堂 / ニンテンドー3DS

2012年3月23日(金曜日)

私のおウチはHON屋さん5

公開: 2011年10月26日1時20分頃

出ていたので購入。

私のおウチはHON屋さん 5 (www.amazon.co.jp)

みゆは相変わらずのプロフェッショナル書店員ぶりですが、怪盗とか謎の幼女発明家とか出てきて方向性が分からなくなってきたなぁ……と思ったところで、まさかのみゆ母登場、そして思わせぶりな台詞。

続きが気になる感じです。

「私のおウチはHON屋さん5」にコメントを書く

関連する話題: マンガ / 買い物 / 私のおウチはHON屋さん

2012年3月22日(木曜日)

新・光神話パルテナの鏡

公開: 2012年3月24日13時15分頃

届きましたよ。

新・光神話パルテナの鏡 (www.amazon.co.jp)

メニューがいきなりスマブラ (www.amazon.co.jp)風ですね。まあ作ってる人が同じなので当然ですが。

スマブラと違うのは、スマブラがメニューで「このゲームはみんなで遊ぶものです!」と力強く主張しているのに対して、パルテナは一人用も対戦も同じ重みになっていること。

以下、感想などを少し。

左手親指スライドパッドで移動、人差し指Lボタンで攻撃、右手はタッチペンで照準の操作、という操作体系。左手が痛くなります。
地上戦はちょっと操作しづらいと感じました。方向転換がタッチペンでのスライドなのが少しやりにくいのと、ダッシュと歩行の使い分けが難しい感じ。歩行のつもりでダッシュして転落したりとか。
地獄の釜のシステムは面白いです。デフォルトの難易度は2ですが、ちょっと上げるくらいがちょうど良いかも。あと、ノーミスクリアし続けるとおすすめの難易度も上がっていきますね。
神器の強さの見方がよく分からないです……。あと高いです。
ナスビは健在、ですがナスビ使いの出現頻度は高くないので滅多に見られないかも。今回は病院がなく、時間で回復するようになりました。
公式サイトにあるチュートリアル動画はそのまま収録されています。そしてパルテナ様のキャラは本編ストーリーでもそのまんま。全体的に軽いノリです。戦闘中も下画面ではピット君とパルテナ様のやりとりが続いているのですが、見ている暇が……。

神器ですが、ピット君は弓だろうということでとりあえず神弓を使ってみています。弾の誘導性が高いので、へたっぴでも割と使いやすい感じ。

対戦も少しだけやってみましたが、まあ下手なので申し訳ないとしか……。

「新・光神話パルテナの鏡」にコメントを書く

関連する話題: ゲーム / 任天堂 / ニンテンドー3DS

2012年3月21日(水曜日)

スキップリンクにまつわる議論まとめ

公開: 2012年3月22日22時0分頃

「スキップリンクの議論: 前提まとめ」の続きです。

まず、前提をおさらいしておきます。

WCAG2.0 2.4.1には"Bypass Blocks"という等級Aの基準がある
その実装方法の一つがスキップリンク
ビジュアルブラウザの利用者もスキップリンクを利用できるように、見えるようになっている必要がある
スキップリンク以外の実装方法もあるが、ビジュアルブラウザで利用できるものはほとんどない

この前提をふまえた上で、スキップリンクにまつわるいくつかの議論をまとめていきたいと思います。

スキップリンク実装の現状

2.4.1は達成等級Aです。これは最低限の等級で、すなわちあらゆるサイトに求められる必須の要件ということになります。

また前提で述べたように、スキップリンクは見えている、もしくはフォーカス移動すると見えるようになる必要があります。ほとんどのサイトが、そのようなスキップリンクを備えなければならないということになります。

もっとも、サイトによってはナビゲーションがない、ナビゲーションがメインコンテンツより後ろにあるのでスキップが不要、というような場合もあるでしょう。しかし、大規模サイトの多くはそのような条件を満たしません。

ブロックスキップは元々WCAG1.0にはなく、WCAG2.0で追加された項目です。リハビリテーション法508条にはありましたが、ビジュアルブラウザで可視であることまでは求められていませんでした。

ですから、古くからアクセシビリティを意識して作られていたサイトであっても、要件を満たすようなスキップリンクを設けていないケースが多いです。そして、追加で設けるのもそれほど簡単なことではありません。

そのような事情もあり、この実装は等級Aであるにもかかわらず、あまり普及していない状況だと思います。

スキップ機能はWebコンテンツ側で設けるべきか

スキップリンクをWebコンテンツ側で設けるべきなのかどうか、という議論があります。

スキップリンクはキーボード、スイッチ、音声認識などのユーザーに役立つとされています。逆に言えば、それ以外の利用者にはあまり意味のないものになります。

つまり、これは多くの人に役立つユニバーサルな機能ではなく、特定の利用者を意識した機能だということです。このようなものはサイト側に求めるべきではなく、必要に応じて支援技術などで補えるようになっていれば良いのではないか、という考え方があります。

そもそも、ブロックスキップ機能をブラウザ側が実装すれば、サイト側では何も実装する必要がないはずです。

UAAG2.0のワーキングドラフトを見ると、2.3.1に「重要な要素に直接アクセスできるように」という規定があります。

2.3.1 Direct Navigation to Important Elements: (former 2.7.4):
The user can navigate directly to important (structural and operable) elements in rendered content. (Level A)
Intent of Success Criterion 2.3.1 :
It is often difficult for some people to use a pointing device (the standard method of direct navigation) to move the viewport and focus to important elements. In this case some other form of direct navigation - such as numbers or key combinations assigned to important elements - should be available which can then be accessed via the keyboard or speech control technology.

以上、Implementing Guideline 2.3 - Provide direct navigation and activation より

まさにWCAG2.0の2.4.1と同じ理由ですね。実装の例として、以下のようなケースが挙げられています。

Examples of Success Criterion 2.3.1 :◦Mary cannot use the mouse or keyboard due to a repetitive strain injury, instead she uses voice control technology with uses a mouse-less browsing plug-in to her browser. The plug-in overlays each hyperlink with a number that can then be used to directly select it (e.g. by speaking the command "select link 12"). This prevents Mary from having to say the word 'tab' numerous times to get to her desired hyperlink.

以上、Implementing Guideline 2.3 - Provide direct navigation and activation より

音声認識のソフトウェアを使っているケースで、「select link 12」と言えば12番目のリンクを選択してくれる、という動作で、これによって「tab」と何度も言わなくて済むという想定です。

スクリーンリーダーなどの支援技術では、既にこのような機能が実装されている場合が多いです。そのため、スキップリンクがなくてもあまり問題になりません。

問題は、支援技術を使っておらず、素のブラウザでキーボード操作というケースをどう考えるかです。「支援技術なしでもブロックスキップできるように、ブラウザ側で機能を設けるべき」という考え方もあると思います。

Webブラウザはスキップ機能を設けるべきか

では、実際にそのような機能をWebブラウザは設けているのでしょうか。

残念ながら、2011年時点では、ほとんどのブラウザにはそのような機能はありません。

アクセシビリティ・サポーテッド（AS）情報：H069-1 (waic.jp)

ちなみにOperaはひっそりと対応しています。「シングルキーショートカットを有効にする」を選択すると、「S」で次の見出し、「W」で前の見出しに飛べるようになります (参考: Opera ヘルプ: キーボードショートカット (help.opera.com))。

Opera以外のブラウザがデフォルトでこの機能を持たないのは、そういうニーズがないから、というところが大きいようです。少なくともIEに関しては実装の予定がなく、このような機能が欲しいというニーズが出ていないし、もっとほかの機能に対するニーズがあって、そちらが優先されているという話を聞いています。

つまり、ブラウザがこの機能を設けていく可能性は高くありません。そして、そんな機能はそもそも必要とされていないのではないか、という疑問も出てきます。

ブロックスキップの達成等級は妥当なのか

前提では、視覚系ブラウザでもブロックスキップできないと困る利用者がいる、ということになっていしました。そしてブロックスキップは達成等級A。これは最低限の基準です。

しかしながら、現状ではブロックスキップが実装されていないサイトも多いですし、ブラウザ側でもあまり実装されていません。にもかかわらず、ブラウザに対してそのような機能を求める声はあまりないらしい、という状況であるようです。

とすると、実は利用者はそれほど困っていないのではないか、という疑問が出てきます。

大きなブロックをスキップする事ができると、キーを連打したり、音声による命令を連呼したりすることが避けられ、メインコンテンツに素早くアクセスできるとされています。しかし逆に言えば、素早いアクセスができないと言うだけで、アクセスが不可能になるわけではないはずです。

ほかの等級Aの項目は、達成しない場合、利用者によっては全くアクセスできなくなる可能性のあるものがほとんどです。それらと比較すると、この達成基準が等級Aとされているのは厳しすぎるのではないか、という印象もあります。

利用者は実際どう利用しているのか

ここまでの議論はおおむねスキップリンクに対して否定的ですが、それでも、実際にスキップリンクを便利に活用している人がいるのであれば、その人のために設けるというのも悪いことではないでしょう。邪魔にならないのであれば、つけても良いとは思います。

ただ、実際のところ利用者はスキップリンクをどう利用しているのか、という点はあまり調査が進んでいないところです。

以下のような論点があるでしょう。

スキップリンクは実際に役に立っているのか
現状ではスキップリンクのないサイトも多いが、スキップリンクの利用が想定されるような利用者は、どのようにしてアクセスしているのか
メインコンテンツへ移動する機能だけで良いのか。ほかの場所に移動するリンクは必要ないのか

今後はどうなるのか

今後、すなわちHTML5が普及した場合の話です。

今までのHTMLでは、ナビゲーション部分をナビゲーションであると明示する一般的な方法はありませんでした。しかしHTML5にはおなじみのnav要素がありますし、WAI-ARIAにはnavigation (www.w3.org)やmain (www.w3.org)といったロールがあります。

WAI-ARIAはともかく、HTML5はかなり急速に普及が進んでいるように思えます。今後、こういったものが普及してくる可能性は高く、下手をすると、スキップリンクを実装したサイトよりもHTML5のnav要素を使ったサイトの方が多くなってくるかもしれません。

そうなれば、ブラウザの対応状況にも変化が出てくる可能性はあるでしょう。

以上、スキップリンクがらみの議論をざっくりとまとめてみました。

WCAG2.0 2.4.1の "Bypass Blocks" は、理論上は、可視のスキップリンクをつければ達成できる基準です。しかし、単につければ良いのか、と言われるとなかなか難しいところで、考えるべき事がかなりあります。

こういった議論があることも踏まえて、基準を少し見直した方が良いのではないか、とも思えます。

奥が深いですね。

「スキップリンクにまつわる議論まとめ」にコメントを書く

関連する話題: Web / アクセシビリティ

2012年3月20日(火曜日)

Google、かんたんログインを廃止

公開: 2012年3月21日22時40分頃

Googleが「かんたんログイン」を廃止したそうで。

ガラパゴス携帯で2012年5月1日以降Gmailをモバイルブラウザで見れない？ (d.hatena.ne.jp)
Google が「かんたんログイン」を廃止へ、Cookie 非対応のドコモ端末に影響 (japanese.engadget.com)

というか、今まであったのですね。もとより、非公式サイトが実装する「かんたんログイン」にはセキュリティ上の懸念点が多く、あまりおすすめできない方式だったわけですが。

まあ、モバイルサイトはもうスマートフォンにシフトしつつありますし、いつまでもこんな事をしていても仕方ないというところでしょう。

「Google、かんたんログインを廃止」にコメントを書く

関連する話題: Web / セキュリティ / モバイル

2012年3月19日(月曜日)

スキップリンクの議論: 前提まとめ

公開: 2012年3月21日22時20分頃

スキップリンクの話が盛り上がったので、情報を整理してみます。「キヤノンはなぜ達成等級「A」を満たせなかったのか」「スキップリンクにまつわるいくつかの議論」の続きです。

ブロックスキップの達成基準

まず前提の話から。WCAG2.0の2.4.1には "Bypass Blocks" という等級Aの基準があります。

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)

以上、WCAG2.0 2.4.1 より

JIS X 8341-3:2010 では以下のように訳されています。

7.2.4.1 ブロックスキップに関する達成基準
複数のウェブページ上で繰り返されているコンテンツのブロックをスキップできるメカニズムが利用可能でなければならない。
注記この達成基準は，等級A の達成基準である。

以上、JIS X 8341-3:2010 7.2.4.1 より

これだけだと分かりにくいですが、以下でもう少し細かく解説されています。

Bypass Blocks: Understanding SC 2.4.1 (www.w3.org)
ブロック・スキップ: 達成基準 2.4.1 を理解する (waic.jp)

スキップリンク

ブロックスキップを達成するための実装方法はいくつか提示されていますが、その筆頭に挙げられているのが以下のテクニックです。

「本文へ」などのリンクを設けて、メインコンテンツの開始位置までフォーカスを移動させられるようにするという手法です。

G123にもブロックスキップのリンクを設ける手法が挙げられています。

こちらは本文へ移動するのではなく、ナビゲーションの直前にリンクを設けてナビゲーションのすぐ後ろまで飛ぶようなタイプのものです。

さらにG124にも、G1と似たようなリンクの手法があります。

これは「本文へ」単独ではなくて、いくつかのブロックへのリンクを列挙するタイプのものですね。

これらをまとめて「スキップリンク」と呼んでいます。ただし、G123やG124のパターンは、G1と比べるとマイナーで、使われるケースはことが少なめです。断りなしに「スキップリンク」と言った場合、特にG1をイメージしている場合が多いです。

スキップリンクの目的と要件

スキップリンクの目的は、キーボードの利用者がナビゲーション部分を飛ばして、すぐにメインコンテンツにアクセスできるようにすることです。

スクリーンリーダー専用の機能ではない、という点に注意が必要です。G1の説明には以下のような注記があります。

Note: It is preferable for links to be visible at all times, since users navigating via the keyboard include switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software.

以上、G1: Adding a link at the top of each page that goes directly to the main content area より

ここでは、以下のようなケースがあるとしています。

キーボードやスイッチを利用し、ストロークを遅くしている
画面拡大ソフトウェアを利用している
スクリーンリーダーの利用者が、目の見える人と一緒に作業している
キーボードだけで操作している
音声認識ソフトでナビゲーションしている (音声の場合、キーと違って連打が大変)

こういった場合、スキップリンクが視覚的に見えるものになっていなければ利用することができません。

従来のサイトには、透明な画像をスキップリンクにしたり、何らかの方法でスキップリンクを視覚的に隠すといった処理をしているものがあります。そのようなケースはG1の実装の要件を満たしていないことになります。

なお、この注記には続きがあります。

However, does not require that they be visible when they do not have focus, and links that are visible only when they have focus can meet this success criterion.

以上、G1: Adding a link at the top of each page that goes directly to the main content area より

フォーカスを受け取っていないときは見えていなくても良い、ということになっています。つまり、最初は見えていないが、tabキーを押してフォーカスが移るとひょっこり現れる、という実装はOKです。

※この部分は後から追記された部分で、日本語訳には追記部分がありません。