nishimotzの日記

このエントリーは Webじゃないアクセシビリティ Advent Calendar 2018 の12日目の記事になります。

NVDA日本語チーム の西本です。ふだんは広島県広島市にいます。オープンソースのスクリーンリーダー NVDA の日本語対応に関わりながら、NVDA 日本語版のリリースを続けています。ウェブアクセシビリティ基盤委員会 WAIC WG2 にも参加しています。

今年は自分の会社 シュアルタ を設立しました。
NVDA に関するコンサルティングや受託開発を、株式会社シュアルタでお受けするのでよろしくお願いします。

後述するように NVDA と Windows アクセシビリティを取り巻く環境は2019年にも大きく変化します。
視覚障害者の雇用などで NVDA を活用したい企業や団体などの法人に向けて、コンサルティング契約により NVDA の技術サポートを提供します。
現在は申込受付の準備中です。
詳細は info@shuaruta.com にお問い合わせください。

Windows と Edge のこれから

Webアクセシビリティ Advent Calendar 2018 の4日目として NVDAのブラウズモード という記事を書いて、「Microsoft が Chromium 技術で作ったデスクトップアプリ」の紹介をしたら、直後に Microsoft Edge が Chromium に移行するという発表がありました。
（momdoさんの日本語訳）

そこまで Chromium 大好きになってたのか。。

Windows 10 がリリースされた直後に NVDA は Microsoft Edge をちゃんとサポートできていない、という宣言をしたのが懐かしいですね。
最大の理由は Internet Explorer 11 がサポートしてきたアクセシビリティAPIを Edge が廃止して UI Automation という技術に移行してしまったから、なのですが、その後、長い間をかけて Microsoft と NV Access は Edge が NVDA でちゃんと動き、性能的にも問題がないようになった、というのが2017年の終わりごろでした。

Chromium になった Edge は、もはや Chrome や VS Code や Skype のようにきちんと NVDA で操作できるようになるのだろうな、と思ったら、今度は Microsoft が Chromium の UI Automation 移行を進める、という話になっています。ということは Edge と Chrome にちゃんと対応できたばかりの NVDA は、また新たな作業が必要になるかも。。

Windows スクリーンリーダーのワクワク・ドキドキ・ハラハラの日々はなかなか終わりそうにありません。

NVDAのこれから

Python 2 のサポートが2019年末に終了する、ということがわかっていたにも関わらず NVDA はいまだに Python 2.7 に依存しています。

あれやこれやのアップデートに対応する作業に NVDA が追われることがなければ、もっと前向きな作業ができたのではないか、と言われそうですが、私は「もともとスクリーンリーダーというのはそういう運命のもの」だと思っています。

つまり OS やアプリやコンテンツが「理想的に作られていない」ことで起きる不具合を「取り繕う」のが、スクリーンリーダーの（本質とまでは言わないけれど）「重要な価値」になってしまっています。

なので「スクリーンリーダーの未来は？」と聞かれると、「スクリーンリーダーがなくなる」は言い過ぎとしても「スクリーンリーダーが単純になるのが理想の未来」と私は答えます。

話を戻すと、NVDA は来年 2019.1 から 2019.4 までの4回のリリースを行うあいだに、互換性を切り捨てて大きく変わり、Python 3.7 あるいは Python 3.8 を積んでパワーアップした NVDA に生まれ変わります。

ですが、そのパワーアップは、ユーザーには「何の得にもならない」と思われる可能性が高いです。

Windows XP のサポートが終わったときにも、Firefox で WebVisum が動かなくなったときにも、ガラケーで Web サイトが閲覧できなくなったときにも、むかしの Visual Basic で書かれたアプリが動かなくなったときにも、同じような話がありました。

今度は NVDA にその試練が降りかかる番ですね。。
たぶん NVDA 2018.4 やその日本語版を、アップグレードしないで何年か使い続けたい、という要望が出るだろうなあと覚悟をしています。
まあ、そういう使い方をする PC を割り切って温存するのは「アリ」かも知れません。。

ユーザーが直接得をしない「新しい技術への移行」は、そうは言っても、標準化、ソフトウェア開発、セキュリティ、オープンソース、など多くの企業やコミュニティの活動が関わって作られた「大きな流れ」であり、逆らうことは「孤立」を意味します。

そして「孤立」は「コンピューターとインターネットを学びたい、楽しみたい、活用したい」というスクリーンリーダー利用者には「残念な」選択だと思います。

実はまだ NVDA コミュニティは NVDA を Python 3 に移行させるための技術的課題を完全にはクリアできていません。

私の手元で動いている Python 3.7.1 版 NVDA は、今日やっとフォーカスハイライトが動いたところですが、まだ重要な機能がボロボロと欠けている状態です。

大丈夫なのか、ほんとにやれるのかよ、と心配しています。

来年は NVDA 日本語版よりも、まず本家 NVDA コミュニティのチャレンジを支えたい、と思っています。

NVDA 日本語アルファ版の新しい仕様

ここからはメーリングリストに投稿した内容です。

現在 NVDA 2018.4 のリリース候補版が出ていて、NVDA 日本語ベータ版 nvda_2018.4jp-beta-181210j はその変更が反映された、事実上の日本語リリース候補版になっています。
来週中に 2018.4jp の正式版もリリースできると思います。

本家は NVDA 2019.1 に向けた作業を進めており、日本語アルファ版では 2019.1 に向けた変更をテストしています。

最新の日本語アルファ版で、NVDA のアドオンについて大きな変更があるので、お知らせしておきます。

以下の説明を読んで、不都合と思う場合は、前もってリリース版やベータ版に移行することをお勧めします。

2019.1 以降の NVDA は、原則として、アドオン開発者によって互換性が確認されたアドオンだけをインストールできます。

アドオン開発者は、互換性を確認していることを知らせるために、アドオンを作り直して公開する必要があります。
先日リリースした focusHighlight 5.4 ではこの問題を修正しています。

NVDA 2019.1 系の日本語アルファ版をインストールするときに、従来のアドオンがインストールされていると、
「アドオンの互換性について了解しました」
というボタンが表示される場合があります。

ですが、そのボタンを押してインストールを実行するだけだと、互換性のないアドオンはすべて無効化されてしまいます。

インストールを実行する前に「アドオンの互換性の確認」というボタンからダイアログを開き、それぞれのアドオンについて「有効にする」のチェックボックスをチェックすれば、従来のアドオンを使い続けることができます。

この作業は、すべてのアドオンについて必要です。
（NVDA をインストールし直すたびに必要かどうかは再調査中です）

アドオンをたくさんインストールしている場合や、頻繁に NVDA 日本語アルファ版を更新している人には、かなり面倒ではないかと思います。

場合によってはベータ版や安定版に切り替えたほうがよい、というのはそういう理由です。

この数日、本家では、この仕組みのリリースで大きな混乱がありましたが、メーリングリストなどの議論を読んでいるかぎりでは、アドオンの互換性チェックを見直すつもりはなさそうです。

NVDA が依存している Python を2019年末までに 2 から 3 に切り替えて、そのほかの NVDA の内部の改良を進めるために、アドオン開発者に対応をしてもらう必要があり、その準備としてこの機能が必要だと考えられているためです。

NVDA 日本語版についても、こういう仕組みになったことを早く知っていただこうと考えています。

インストール時のアドオンの操作についてのメッセージは、日本語アルファ版では日本語に翻訳しました。
通常よりも早いタイミングで翻訳作業をしたので、不完全な部分があるかも知れません。

従来動いていたアドオンが「手動で有効化」すれば動くかどうかは、アドオンごとに状況が異なりますが、2019.1 で動いているとしても、アドオンそのものが更新されなければ、2019.4 や 2020.1 で動かない可能性が高いです。

新しい日本語アルファ版を試してもらい、どのアドオンで不都合なことが起きるかを調べながら、NVDA 日本語チームの取り組むべきことを検討したいと思います。

アドオン開発者のための補足

アドオン開発者のための公式の説明は developerGuide に書かれています。

https://github.com/nvaccess/nvda/blob/master/developerGuide.t2t

具体的には manifest ファイルに

minimumNVDAVersion = 2017.4
lastTestedNVDAVersion = 2018.3

のように記載します。
前者を「最小要件の NVDA バージョン」
後者を「動作確認済みの NVDA バージョン」
と日本語では表記しています。

未来のバージョン番号を 2019.2 のように書いてもエラーにはなりません。
（が、最新のアルファ版のバージョンにしておくべきという本家のMLでの議論あり）

2019.1 と書くと本家版 2019.1 とも互換性があり、NVDA 日本語版 2019.1jp とも互換性がある、と解釈される見込みです。
（日本語版でしか動かない、みたいなチェックは想定していません）

本家のコミュニティで公開されているアドオンのテンプレート
https://github.com/nvdaaddons/AddonTemplate
こちらには
updateChannel
という項目もありますが、これは本家の addonUpdater で使われる項目で、不要な場合は None にしておきます。

focusHighlight の buildVars.py も紹介しておきます。

https://github.com/nvdajp/focusHighlight/blob/master/buildVars.py

NVDAとアドオン開発者のための補足の補足

ユーザーには何の役にも立たないように見えるであろう「NVDA の Python 3 移行」ですが、NVDA の現在と未来の開発者が幸せになれる、というメリットが、めぐりめぐって NVDA のユーザーを幸せにする、という展望があります。

例えば、いままで NVDA が日本語環境でうまく動いていない不具合の多くは「Windows で日本語の文字コードが使われている場合だけで起きる問題」の見落としでした。

Python 3 への移行で、そのような不具合が起こりにくくなる、と私は期待しています。

おまけ：今年出演したポッドキャスト（再掲）

サイトワールド2018特集 第6回 NVDA日本語チーム（日本視覚障害者ICTネットワーク JBICT ポッドキャスト）

AccSell ポッドキャスト第140回: 「こういうもの俺自分で作らなくて良い時代になったんだ」

わしポ 9: Kinsai PyCon mini Hiroshima (nishimotz)

この記事は Web Accessibility Advent Calender 2017 の10日目の記事です。

オープンソースの Windows 用スクリーンリーダー NVDA に関するこの1年の活動を振り返るポエムで乗り切ろうと思ったのですが、ゆうべ広島フロントエンド勉強会で喋ったら気が変わってしまいました。

11月11日 JAC Vol.1 の講演「アクセシビリティ検証ツールとしてのNVDA入門」での失敗をフォローします。

アクセシブルな決済システムの試作

アクセシビリティで難しそう、めんどくさそう、スクリーンリーダーで実際に検証しないと不安なポイントはやっぱりセキュリティだろう。

試してみたくなったのがクレジット決済 API を使うサイトの開発だった。

11月11日に見せようとした試作サイトは、以下のような方針で開発した。

決済サービスの選択

• テストモード、つまり、ダミーのカード情報を送信して実際にWebアプリのテストができること
• カード情報を Web アプリが保存しなくてよい、できれば受け取る必要すらないこと（情報漏洩のリスクを回避）
• Python から簡単に使えること（個人的な好みです）

実際に使った決済サービスの仕様

• JavaScript ライブラリがあり、ブラウザが決済APIサーバと直接通信を行い、カードと紐付いたトークン情報だけが返ってくる
• そのトークン情報を Web アプリが受け取って、実際の課金を行うことが（Python ライブラリから）できる

つまり、ブラウザの中で「ユーザーにカード情報を入力させて、決済サーバに送って、カードのトークンを受け取る」という処理を、画面遷移せずに完結させたい、ということになる。

これは、セキュリティのために「動的なコンテンツを作らざるを得ない」ということで、アクセシビリティの題材としてはよさそうだと思った。

11月11日の前に作っていたもの

コードの抜粋はこちら

環境は Google App Engine for Python + Flask

(1) ログインする前の画面

ログインしてください、という表示になり、ログインのリンクがある。
実際にログインで使っているのは Google アカウント認証。

これが使いたかったので GAE を選んだ。本人確認されたユーザーのメールアドレスを取得。Google のログイン画面はスクリーンリーダーでちゃんと使えるはず。

ログインする前とログインしたあとの画面は Jinja2 （Python のテンプレートエンジン）で分岐している。

(2) ログインした直後の画面

ログインすると最初の画面が入力フォームになっている。

上から順に、以下のものがある。

• テキスト「カード情報を入力して「確認」を押してください」
• 4個の入力フィールド：カード番号、有効期限（年）、有効期限（月）、CVC番号
• 「確認」ボタン（有効状態）
• 「購入」ボタン（無効状態）
• 「キャンセル」ボタン（無効状態）

ただし、デモなので、入力フィールドには決済サービスのテスト用カード番号があらかじめ入れてある。

確認ボタンを押すと URL が遷移するのではなく、JavaScript の処理が実行されて、コンテンツが動的に変化する。

(3) カード情報が正しくない場合の「確認」結果

「カード番号が正しくありません」などが表示され、入力フィールドの修正と「確認」ボタンしか有効にならない。

何が正しくないかというメッセージはテキスト（ aria-live=”assertive” 属性の div ）として表示され、スクリーンリーダーで読み上げられる。

つまり動的コンテンツだがバリデーション結果をアクセシブルに提示できる。

(4) カード情報が受理された場合の「確認」結果

「カード情報が確認できました。「購入する」を押すと***円のお支払いが完了します。」

のように表示され、「購入」ボタンと「キャンセル」ボタンが有効になり、入力フィールドと「確認」ボタンが無効になる。

購入ボタンを押すとカードのトークンが submit されて URL が遷移する。Python アプリで決済 API をたたいて結果を取得、次のページに「購入完了」みたいな表示を出す。

「キャンセル」を押すと、入力フィールドの値がふたたび変更可能になる。

本番でやったドジなこと

確認ボタンを押して入力フィールドが無効になった状態で、「じゃあ今度は値をわざと変更して正しくない入力内容にしてみましょう」とか言いながら、無効になっている入力フィールドのテキストを書き換えようとしてうまくいかず、デモを中断してしまった。

そのあとで考えたこと

aria-live=”assertive” とか、フォーカスの制御とか、invalid とか、いろいろ盛り込んだのだが。。

そもそも「自分がうっかり間違えるような UI 設計がよくない」と考え直した。

最近作り直したもの

(1) ログインする前の画面

ログインしてください、という表示になり、ログインのリンクがある。

(2) ログインした直後の画面

ログインすると最初の画面が入力フォームになっている。

上から順に、以下のものがある。

• テキストA「カード情報を入力して「確認」を押してください」
• 4個の入力フィールド：カード番号、有効期限（年）、有効期限（月）、CVC番号
• 「確認」ボタン（有効状態）

(3) カード情報が正しくない場合の「確認」結果

テキストA「カード番号が正しくありません」などが表示され、入力フィールドの修正と「確認」ボタンが使える状態のまま

(4) カード情報が受理された場合の「確認」結果

• テキストB「カード情報が確認できました。「購入する」を押すと***円のお支払いが完了します。」
• 「購入」ボタン
• 「キャンセル」ボタン

その他のものは非表示になる。

「キャンセル」を押すと、テキストAと入力フィールドだけの表示に戻る。

振り返って思うこと

なんのことはない、これはひとつの HTML ファイルにダイアログAとダイアログBがあって、交互に表示・非表示になる、一種のモーダルである。

たぶん最初の「非表示・無効」だらけの画面を作っていたときには、「この操作を実際に行うと、次にどういう段階に進むのか」みたいな見通しを伝えたかった。
だから、あとから有効になるけどいま無効なものをたくさん作ってしまった。
その流れで「さっきは有効だったけどいまは無効になった」ものも、たくさん残してしまった。

だが、けっきょくのところ「ひとつひとつの段階で迷わせない」「無関係なものを見せない」ということのほうが大事だったと思われる。

カード情報が確認できたときに、もういちどカード番号を表示する、みたいなことは、本当はやった方がいいのか、やっぱり不要なのか。。

こまかいこと

今回のデモでは invalid の判定には2種類ある。

(1) HTML の required と pattern を使う処理
(2) 決済APIサーバーのエラーメッセージに基づく処理

後者の場合には、JavaScript のコールバックで

<div id="input_guide" class="alert alert-primary" role="status" aria-live="assertive"></div>

<div class="col-12">
  <label for="card_number">カード番号</label>
  <input type="text" id="card_number" class="form-control" aria-describedby="card_number_help" value="5555555555554444" required aria-required="true" pattern="[0-9]{13,16}" />
  <small id="card_number_help" class="form-text text-muted">半角数字 <span aria-hidden="true">省略できません</span></small>
</div>

if (response.error.code === 'invalid_number') {
  $('#card_number').attr('aria-invalid', true).focus();
  $('#input_guide').text('カード番号が正しくありません').addClass('alert-warning').removeClass('alert-success');
}

みたいなことをする（jQuery を使っている）。

JavaScript 2行目の最後の .focus() がなければライブリージョンの「カード番号が正しくありません」が読み上げられる。

一方で、この .focus() をつけてしまうと card_number 要素の読み上げしか聞くことができない。

NVDA 2018.1jp-beta-171206x + Firefox ESR 52.5.2 でスピーチビューアを使って確認すると：

ブラウズモード
カード番号が正しくありません 
カード番号  エディット  正しくない入力内容  必須  オートコンプリート  半角数字 省略できません
55555555555544 選択
フォーカスモード

つまり、ライブリージョンの読み上げの直後にフォーカス位置の読み上げイベントが発生して、直前の読み上げを止めてしまうのだ。

（「フォーカスモードとブラウズモードの切り替えを音で報告」はチェックなし。後述の追記2を参照のこと）

実は最初のバージョンはこれが気に入らなくて（だって live region のデモにならないから）フォーカスを移動しなかったのだが、考えてみるとライブリージョンを読むことよりもフォーカスをエラー箇所に移動してあげることのほうがずっと親切で、ユニバーサルな気がする。

さらに、フォーカスを読み上げるときに「正しくない入力内容」もちゃんと読み上げているのだ。

本当にスクリーンリーダーで検証するべき「アクセシビリティのディティール」というのはこういうことなんだろうな、と思っている。

ここから追記

追記：NVDA の live region の実装がおかしいのではないか、と言われそうな気もするので（そうかも知れないけど）ちゃんと制御できるケースも紹介しておく。

$('#card_number').attr('aria-invalid', true);
$('#get_token_btn').focus();
$('#input_guide').text('カード番号が正しくありません').addClass('alert-warning').removeClass('alert-success');

こんなふうにボタンにフォーカスを移動して、直後に live region の内容を更新すれば、「カード番号が正しくありません」をちゃんと聞くことができる。
（このテクニックは最初のバージョンで使っていた）

追記2：さらに調べたら、NVDA の「フォーカスの変化を追跡する自動フォーカスモード」をチェックなしにすると、エディットにフォーカスが移動したときに live region を最後まで読み上げて、それからフォーカスを読み上げるようになった。

ボタンとエディットで挙動が違うのだから、もしやと思ったら、やっぱりそういうことだったか。。

おことわり

勘のいい人は shop.nishimotz.net というサイトを見つけたかも知れませんが、このサイトは「本当に何かを販売して決済を行うサイト」に作り替える予定の場所です。

明日は tosssaurus さんの「社内じんわりアクセシビリティ普及活動報告」だそうです。お楽しみに。