はてなブログに移行しました

この前の投稿が2014年6月だそうです。ご無沙汰しています。

ほぼ塩漬けのこのブログですが、捨ててしまうのももったいないので、今回のはてなダイアリー終了に当たってはてなブログに移行しました

ふむふむ、編集するにはタイトルにonmouseoverなわけですね。今風UIなので慣れが必要なようです。

今後ともよろしくお願いいたします。

GitHub Kaigiに参加してきました

2014/6/1 に渋谷のサイバーエージェントさんのセミナールームで開催された GitHub Kaigiに参加してきました。

会場

サイバーエージェントさんのセミナールームAは渋谷マークシティの13Fにあり、駅からは少し迷いがちですが近い場所でした。参加者500名にもかかわらず会議テーブルと電源が使えるようになっていて驚きました。
(私が全体を知らないのでもしかすると部分的だったかもしれません。)
無線LANや飲み物の提供、ビアバッシュでの食事提供などもあり、スポンサーやボランティアで運営している技術者の方々には頭が下がります。

セッションの概要

以下、セッションの概要を簡単に記載します。各セッションの資料はPDFで上がっていて、そのうちustreamビデオも公開されるそうなので、詳細はそちらを確認されることをお勧めします。

  • GitHub実践入門 ─ Pull Request による開発の変
    • GitHub実践入門」の著者によるGitHubを活用した開発の世界の話。GitHubのある開発の世界とそうでない世界の差を、習慣、機会、品質、心理の面から示していました。また、GitHubをただ利用している開発と、その先の活用している状態との差として、Pull Requestがただのマージ依頼でなくそこで対話が生まれる状態としていました。GitHubを活用できるようになるために成長の段階に応じて必要なことを示したガイドブックとしてこの書籍を紹介していました。
    • GitHub実践入門は私も購入しました。Pull Requestの送り方、受け方を実際に手を動かして学べるようにしている他、画面構成を細かく説明しているのが私にとっては助かりました。
  • はてなブログチームの開発フローとGitHub
    • はてなブログの開発におけるGitHub利用前および使い始めてからの課題とその解決について取り上げていました。はてなブログは開発者5人+デザイナー二人で月間1300コミット、月間45回リリースという規模で開発されているそうです。タスク管理ではGitHubイシューがタスク管理には使いにくいこと、レビューではPullReqが放置される問題、リリースではデプロイ作業とプロセスとの乖離の問題を取り上げ、それぞれはてなでどのように取り組んでいるかを示していました。
    • 私は業務ではほとんどGitHubを使っていませんが、オンラインでのレビューが滞りがちになるとか、デプロイ作業と管理が人でしかつながっていないという問題は一般的なように感じました。レビュータイムの導入や、デプロイ時のチェックリスト生成自動化のようなことは改善のヒントになりそうです。
  • OSS と GitHub (仮)
    • RubyRailsのコミッター、kaminariの開発者である @a_matsuda さんによるOSS界隈でのGitHubの使われ方に関するお話。GitHubにとてもマッチしているRails、かたくなにsvnがマスターのRuby、ドキュメントとコミュニティでうまくいっているkaminariなどを例示していました。その上でGitHubはコードを書く人に「あちら側」と「こちら側」のない平等な世界を提供するので、1歩を踏み出してコードを書こうという呼びかけになっていました。
  • How GitHub Works
    • GitHubではモチベーションを重要視していて、そのために柔軟な働き方が可能な仕組みを構築しているそうです。同じオフィスで働くこともできるけれど、リモートをデフォルトと考えてツールを整備、その上で信頼を築くために実際に会う機会を作るなど。
  • GitHubで
雑誌・書籍を作る
    • Web+DB Press関連書籍の著者とのやりとりをGitHubで行っているお話。原稿は以前は専用の全角編集記号によるマークアップだったのを、今はMarkdownにし、そこからAdobe InDesignテキストに変換するツールを使っているそうです。GitHubにしてから執筆の進捗が見える化された、バージョン管理前提なので大きな変更提案がしやすいなどを挙げていました。
    • テキストベースの高度な編集作業である点はソフト開発と同じなので、GitHubの使いこなしさえうまくいけば雑誌編集に使うのは実は自然な流れなのかもしれません。
  • Atom, the Programmable Text Editor
    • Emacsのようにパワフルだけど普段使う言語で拡張でき、シンプルでそのまま使えるエディタとして開発。でもOSに近いレイヤーまで新たに実装するのを避けるためにChromeをベースに開発されています。HTML5実装であるために、変更したい時に探しやすいといった利点もあるようでした。
    • おもしろそうなので私もAtomをダウンロードしてはみましたが、残念ながらMacのVoiceOverからは表示内容を取得できませんでした。しかし多機能なエディタなので、単にVoiceOverがHTMLビューとして認識しても機能を果たす期はしません。HTML直接でなく内部APIがあるようなので、それらを使ってEmacspeak的アプローチで音声UIを構築すべきなのではと思いつつ、0からそこまで持っていくほどの必要性を感じていません。
  • 入門書には載ってない Git & GitHub Tips
    • qiitaで人気のあるGitHubのTips紹介でした。merge.conflictstyleによるコンフリクト時の元ソース表示、インデックスにgit addしている状態からのgit stashの操作、git-new-workdir、git diff/applyによる空白コミットの分離、git fsckによるコミット救出、hub browseと hub pul-request、rebase.autosquashなど。
    • まだまだgitは奥が深いです。
  • Rebuild.fm Live(47になるみたい?)
    • PullRequest駆動、Hubot、Atom contribution guideline、リモートワークにおけるSqweggleなど
  • LT

感想

全体として、GitHubやgitのTips、自プロジェクトでの使い方や工夫、エモな話まで、とても勉強になりました。

今日はおそらくGitHub Kaigiなので特殊な環境かもしれませんが、もはやgit + GitHub利用はWeb系やOSS開発において当然のツールとなっているなと改めて感じました。最近やっとGitHubのUIが理解できてPull Requestを送ったりしていると、少しがんばればもっと世の中に貢献できるんじゃないかという期がしてきます。コードを中心にした共同のツールとしてよく考えられているからでしょう。

またそこから1歩進んで、Hubotにデプロイ依頼するとデプロイのチェックリストが入ったプルリクエストが生成されて、それがレビュー・マージされるとデプロイ、といったように、共同作業の土台としてGitHubを使う工夫はおもしろいと思いました。ここはGitHubに限らず、ワークフローの改善ととらえて参考にしたいところです。

最後に

久しぶりにこのような規模の一般のセミナーに参加し、日頃文字や声だけで聞いている人と同じ場を共有したり一部の方とはお話できて、とても有意義でした。運営やスポンサーの方々、また、いきなり私のフォローを頼まれたのに対応してくださった sota0805 さん、ありがとうございました。
今後も機会があれば勇気を出して参加して行きたいと思います。
その前にコード…。

JAWSでgvimを使う

JAWSユーザがWindowsのエディタとしてgvimを使うための設定がわかってきたので書いてみます。
以下のようにするとひとまずvimとして利用できるようになります。基本はJAWSにカーソルを認識させることと、反転表示を強調部分として認識しないようにするという二つです。追加の応用として、上下矢印キーで移動した時に画面上の改行単位で移動する設定も書いてみます。

(12/23追記)linespaceの設定を追加しました。また、水平カーソルはもう少し細くてもいいかもしれないので直しました。

利用した環境

_gvimrcはこのパッケージに含まれている_sample_gvimrcを_gvimrcにコピーしたものをベースに設定を追加しました。

カーソルをJAWSが認識できるようにする

gvimのカーソル形状

gvimのカーソルはモードによって切り替わるのがデフォルトですが、多くのモードではブロックカーソルになっています。JAWSは縦型または横型カーソルしか認識しないようなので、変更する必要があります。また、縦型カーソルだとJAWSが認識するカーソル位置が揺れてしまうため、結局は横型(水平)カーソルにする必要がありました。
以下の設定はすべてのモードで水平カーソルにします。

set guicursor=a:hor10-Cursor/lCursor
JAWSが幅広の水平カーソルを認識できるようにする

上の設定を入れるとカーソル位置が安定してとれるようになりますが、日本語が書かれた行にいるとカーソルを見失ってしまいます。gvimは日本語のような幅広の文字では水平カーソルを広げて表示するため、JAWSが水平カーソルと認識する幅を超えてしまうのです。
そこでgvimを起動した状態でJAWSキー+F6でJAWS設定センターを開き、「キャレットおよびカーソル」の中にある水平カーソルの最大幅を最大値の30に設定してしまいます。

反転表示を強調表示と思わないように設定する

gvimのステータス行は黒地に白で、JAWSはこれを強調表示と認識し、カーソル位置にかかわらずそこを読もうとしてしまいます。これをさせないように設定します。
JAWS設定センターから「ハイライトカラーの設定」を開き、「ハイライトカラー」を「カスタムのみ」に設定します。

行間隔を広げる

これだけだと日本語を含む行の下の行がなぜか点字表示されないという問題があります。そこで、行間隔を少し広げます。広げすぎるとカーソルをとれなくなるみたいなのでこれくらいが適当です。

set linespace=2

上下矢印キーで移動時に物理行で移動する

JAWSは上下矢印で移動した時にその(画面上の)行を読み上げるので文書やコードを読むのに使える訳ですが、これが論理行単位だと折りたたまれた2行目以降を読み飛ばす可能性があります。
元々vimにgj, gkという物理行移動のためのコマンドがあるので、これを上下矢印キーに割り当てます。j, kの動作も変更する人もいますが、ここはJAWSの挙動に関係ないので私はそのままにしました。

nnoremap <Down> gj
nnoremap <Up> gk

gvim.jcf

JAWS設定センターで設定した後のgvim.jcfファイルを貼り付けておきます。

[Options]
UseCustomHighlight=2
[OSM]
HorizCaretMaxX=30

iOS 6.0+VoiceOver: 日本の視覚障害者にとっての大きな1歩

本日2012年9月19日(米国時間)、アップルのiPhone, iPad向けOSであるiOS 6.0へのアップデートが開始されました。
iOS 6の一般的な更新内容については本家のサイトを始めとして各所で紹介されていますが、VoiceOverについて書かれていない大きな新機能があり、また問題点も残っています。
ここでは日本のVoiceOverユーザにとって特筆すべき新機能と問題点について挙げてみたいと思います。

改良点

文字の説明読み

iOS 6.0では長年の待望だった日本語の文字を説明読みする機能が入りました。説明読みとはたとえば「今日は」を「今月のこん・今、日曜日の日・ひ、ひらがなのは」と説明するものです。これまでは「漢字」と「感じ」を区別できませんでしたが、これからは確実に選べるようになります。

  • 日本語入力中に、上下フリックまたはキーボード上側の候補部分をタッチすると、選ばれた候補を説明読みします。
  • 任意の場所でVoiceOverローターを「文字」に合わせた状態で上下にフリックして1文字ずつ読ませると、選択された文字の後にその文字の説明読みをしゃべります。

これで日本のVoiceOverユーザも、文字入力を自信を持って行うことができるようになりました。なお漢字の説明読みはJAWSやPC-Talkerのそれとは違っているようです。(追記: IBMホームページリーダーに搭載されていた説明読みではないかという噂があります。→どうやらそうでもないようです。)

Bluetoothキーボードでも説明読み

これと合わせて、Bluetoothキーボードを接続して使っている時にも日本語入力時の説明読みが提供されるようになりました。日本語を入力してスペースキーを押せば、最初の(推測)変換候補が説明読みされます。そこから再度スペースキーを押したり左右の矢印キーで候補が選択でき、Enterキーで確定します。
入力時に余分なぽよぽよという音がしたり、あまり速く入力しすぎると文字が入らなかったりしますが、十分実用になるレベルです。これでiPhone/iPadの使い方が大きく広がりました。

キーボード操作の変更

タッチ入力モードで入力している時、これまでは削除キーはダブルタップまたはスプリットタップが必要で操作性を悪くしていました。iOS 6からはこれらのキーも文字のキーと同じように指を置いて離すだけで入力できるようになりました。
キーボードの切り替えキーの読み上げが少し変わりました。以前は「そのキーを押したら切り替わる先のキーボード」をガイドしていましたが、iOS 6では「次のキーボード」とガイドされます。キーボードの切り替えがややこしいなと思ったら、このキーをダブルタップして押さえたままにし、上に指を滑らせてみてください。キーボードの一覧があるので必要なところで指を離せばそのキーボードに切り替わります。これは以前からあった機能ですが、iOS 6で反応が改善されて使いやすくなりました。
地味な修正として、スペースキーや改行キーにその時の状態がきちんと反映されるようになりました。たとえば改行キーは未確定の文字がある時は「確定」、確定した後に続く推測候補が出ている時には「閉じる」とガイドされます。
また、日本語仮名キーボードで「あ」や「た」の左にあるキーにもガイドがつきました。「完了」や「逆順」とガイドされます。
改良ではありませんが、以前はEnglish USキーボードの時にキーの文字を英語音声でしゃべっていましたが、iOS 6では日本語音声でガイドされます。これはちょっと不便になったかもしれません。

圧縮ボイスで音声が出なくなる問題の解消

iOS 5では圧縮ボイスにしている時に、しばらく使っていると突然しゃべらなくなることが頻発していました。iPhone 4を使っている場合など高音質音声では重たいと感じる場合に圧縮ボイスは重宝します。今回の修正でiPhone 4が延命されるかもしれませんね。

問題点

iOS 6.0のリリース時点では結構困ったものも含めていくつかの問題点が残っているようです。重要なものだけ以下に紹介します。

全角の英数字が韓国語になる

一番困るのはこれです。「1」や「a」などのいわゆる全角英数字、それに一部の記号が韓国語とおぼしき音声で読まれます。「1」は「イルー」とかになっています。(私は韓国語を知らないので違うかもしれません。)
普段Twitterやメールを読んでいると意外に全角英数字が多いことに気づかされます。できるだけ早く修正されることを期待しています。

削除キーなどが説明読みされる

削除キーなどに指を置いたままにしていると、「削除  削減するのさく・削る、 除外するのじょ・除く」としゃべってしまいます。本来は「削除」というだけでいいはずです。キーボード上のキーを触っていてこのように言われても驚かないようにしましょう。

その他いろいろ
  • BluetoothキーボードでSafariの検索ボックスに入力しているとキーが繰り返されてうまく入力できなかったりします。
  • 説明読みで「お」と「を」が区別できなかったり、英字が大文字かどうかわからなかったりします。
  • 他にも致命的でない問題がいくつかあります。

バグレポートの勧め

iOS5のベータ段階から、アップルの開発者登録をした数人でリリース前のiOSを利用してバグ報告を送る取り組みをして、これまでに20件近い修正が取り入れられています。
iOSの開発は主に米国で、日本語環境の問題はそのままでは見過ごされがちです。ベータ版の入手には有料のiOS Developer Program登録が必要ですが、無料の開発者登録でもApple Bug Reporter経由で既存バージョンに対するバグレポートを送ることができます。レポートは英語で書く必要がありますが、レポートしなければ日本人が困っていることは開発者まで伝わりません。
レポートを送っても、それがいつ直るのかはこちらからは分かりません。ただ、何か不明なことがあれば質問が来ますし、バグが修正されたり改善がされたりした時にはIOSの開発者向けリリースが出ると同時に「このバグが新バージョンでも出るか確認してください」という連絡が来ます。これを見て動作確認し、ちゃんと直っていた時はうれしいものです。やりとりをしていると、アップルのアクセシビリティへの対応が活発であることを肌で感じることができます。
なお、今回説明読みがついたことそのものは我々が挙げた要望が直接の理由ではないと思っています。説明読みに関する要望を出したのは今年の2月九日で、iOS 6.0 betaが出たのが6月ですから4ヶ月で盛り込まれた訳ではないと思うからです。
アップルの取り組みには感謝しています。そしてこれからも引き続きレポートを続けていきたいと思っています。

Ployer momo9でTalkBackを使う

またまたお久しぶりです。

いわゆる中華タブレットのPloyer momo9というのを先日購入しました。Androidアクセシビリティと、Androidそのものについて知りたかったので、Android 4.0搭載でできるだけ安くいろいろ試せるものをと思って調べていると、http://androidgirls.blog.fc2.com/?tag=momo9;title=こちらアンドロイド少女隊 MOMO9というサイトを初めとして日本でも情報が多いようなので購入に踏み切りました。
\7800で、購入後三日だけ保証という後から考えると怪しいお店です。裏面にPLOYERなどのロゴがないことから、どうやらメーカー純正品ですらないようです。

しゃべらせるまで一筋縄ではいかなかったので、その記録をメモ代わりにここに書きます。結論はカスタムファームを利用したという点につきます。

TalkBackが起動するまでとCWMによるファーム書き換え操作はしゃべらないのでうちの奥さんに手伝ってもらいました。iOSユーザですがさっさと慣れてくれたので、適応力あるなあと関心してしまいました。

momo9純正ファーム: NG

さて、自宅無線LANにつないで早速設定の「ユーザ補助」からTalkBackをインストールします。ところが、Google TTS EngineやTalkBackそのものがクラッシュしてどうにも使えません。
なんとこのmomo9の「言語と入力」設定には「テキスト読み上げの出力」という項目が存在しないのです。Android 4.0にはあるはずなのですが、どうも削られているらしい。「momo9 TTS」でググると同様のことで困っている人を見つけました。詰んだ・・・?

カスタムファーム

こうなったらダメ元ということで、カスタムファームに挑戦してみることにしました。試したのは以下三つです。

一つ目のQware Pro3 7はmomo9のファームウェアをベースにしたもののようで、オリジナルと同様「テキスト読み上げの出力」設定はありませんでした。
二つ目のFun Seriesですが、なぜかタッチパネルの操作ができなくなってしまい残念ながら使えませんでした。個体の問題なのか直前に入れたQwareとの関係なのか。。。再起動もできないので、PCにつないでAndroid SDKの adbでshellにログインし、「reboot -p」とやって電源を落としました。イソップ物語じゃないですが、これもmomo9ファームベースなのできっと操作できてもNGだったのではと思っています。
三つ目のCyanBook v0.4でようやく「テキスト読み上げの出力」設定にお目にかかることができました。

TalkBack等の設定

そこからはドキュメントトーカ for Androidデモ版のインストール、読み上げエンジンの選択、TalkBackの有効化、「タッチガイド」の有効化を行ってしゃべるようになりました。
最初のうちは指を画面に沿って滑らせているだけで画面のタップと誤認してしまい、「これが中華パッドの実力か。結局安物買いの…」とあきらめ欠けていましたが、一夜明けてみたら非常に当たり前に動くようになっていました。謎です。

Tipsなど

以下にはまりポイントや追加情報を列挙します。

ファーム書き換え関連
  • LiveSuiteを利用したファームウェア入れ替えの時、通常ならLiveSuite起動→imgファイル選択→特定の手順でデバイスをPCに接続、でファーム更新確認の画面がPCに表示されるはずです。しかし我が家はVMware Fusion上のWindows 7から行おうとしたため、この更新確認ダイアログがどうやっても出せませんでした。結局ノートPC(Windows XP)で試したらあっさりできてしまいました。
  • Clockwork Mod Recoveryを使ったファーム書き換えは、結局こちらに書かれているようにnovo7toolsによる再起動が必要でした。CWMのドキュメントには「Menuキーを押しながら電源キーを長押しするとリカバリーモードで起動」となっているのですが、この方法はこの個体では使えませんでした。
  • ファーム更新モードに入ってもPCが認識しなかったなどで通常にブートさせたい時、リセットボタンが不可欠です。細いものを準備しておくのがポイントです。
ドキュメントトーカ関連
  • ドキュメントトーカのデモ版は発話の差異にかなり頻繁に「これはデモバージョンです」と前置きします。Android端末を触り始めて間もない時で、かつタッチの五人が発生している状態だったのでほとんど使い物にならず、すぐに有償版にしてしまいました。もしAndroid端末を購入してお店で設定してもらうような時は、けちらず最初から有償版(\990)を入れてしまうのがいいでしょう。
  • ドキュメントトーカIMEのキーボードのキーラベルを読ませるためには、ユーザ補助で「パスワードの文字を読み上げ」をオンにする必要があります。よく見るとドキュメントトーカIMEのページにもちゃんと書いてあります。Shimejiなど他の日本語キーボードでも同様の状況なのでTalkBackかどこかにバグがあるのだと思います。
CyanBookについて
  • オリジナルのmomo9のファームウェアもそうですが、SuperUserなどのアプリが入っていていわゆるroot化済みとなっているようです。
  • このファームウェアはホーム画面がApex Launcherというものになっています。ここからアプリを起動するには、右上の「アプリ」というボタンをタップして一覧を出すことで行います。Android標準のホーム画面を体験してみたいのですが、それ単体で入手できるものなのかわかっていません。
アプリについて
  • Terminal Emulator: CyanBookに最初から入っています。残念ながらTalkBackでは読めませんでした。
  • Skype: 着信を受けるボタンがTalkBackで認識できません。自分から発信はできます。残念です。
ハードウェアキーボード
  • momo9はUSBホストを持っているので、手持ちのUSBキーボードが使えました。方向キーで画面上のアイテム間を確実に移動したり、文字キーで入力したりと便利に使えました。難点は方向キーによる移動では移動できない箇所があることです。

第2世代Apple TVのVoiceOver

昨年2010/12/23に、近くのヤマダ電機Apple TVを買いました。
第2世代Apple TVのiOS 4.1以降にはVoiceOver機能があり、音声フィードバックで全盲社でも使うことができます。
Apple TVで何ができるか、買うべきか買わざるべきかという記事はたくさんあるようなので、ここではVoiceOver機能のみに絞ってレポートしてみます。
読者としてVoiceOverを使いたいユーザを想定します。

基本的な操作

操作のイメージを持ってもらうために、まず操作系について説明します。
Apple TVの操作はすべて付属のApple Remoteで行います。
Remoteには上半分に丸い方向キー、方向キーの真ん中に決定キーがあります。その下に左側にくぼんだMENUキー、右側に再生/一時停止ボタンです。たったこれだけです。Apple Remoteそのものには「MENU」以外文字での記載はありません。
操作系は、方向キーで選択して決定キーで決定、メニューキーを押すと一つ前の階層に戻る、という単純なものです。
左から右に向かって、ムービー、インターネット、コンピュータ、設定というタブがあり、Remoteの左右を押して移動します。タブの中では上下に項目が選択できます。
操作をすると、反応したときにぴっという小さい音がします。トップの階層でメニューを押したり、設定のエリアで右を押したりというように、無効な操作をすると違った音がするのでわかります。
VoiceOverが有効になっていると、選択した項目や、今どの階層にいるかをしゃべってくれます。ほとんどの操作がVoiceOverの音声を聞きながら行えます。
日本語も英語も、iPhoneと同じ声でしゃべります。

VoiceOverのOn/Off手順

iOS 4.1が入っている状態でVoiceOverをon/offする手順は以下のようになります。

  • メニューキーを何度か押してトップレベルの操作階層に移動します。
  • 方向キーの右を何度か押して、「設定」のエリアに移動します。端っこでは違った音がするのでわかります。
  • 方向キーの上を何度か押して、一番上の「一般」を選びます。
  • 決定キーを押して「一般」の中に入ります。
  • 方向キーの下を10回押して、上から数えて11番目にある「アクセシビリティ」を選択します。
  • 決定キーを押して「アクセシビリティ」の中に入ります。「VoiceOver」という項目が選ばれた状態になります。
  • 決定キーをもう一度押します。VoiceOverがoffならonに、onならoffに切り替わります。

使い始めに少し難あり

さて、それなりに使えるのですが、私が購入したものは内蔵のiOSのバージョンが古く、最初はVoiceOverが使えませんでした。
設定項目そのものがなく、一度ネットワークにつないで画面をみてもらいながらOSを4.1にアップデートするとアクセシビリティの項目が現れました。
OSのアップデートは、有線LANなら手数を覚えて自力でできる作業かもしれませんが、もはや古いOSがないので「アップデート」がどこにあるか説明できません。ちなみに4.1では一般の上から7項目目(上の端から下キーを6回押したところ)にあります。
私が買ったのはたまたま売れ残りで、今買えばiOS 4.1が入っていることを期待します。
それから、買ってきて最初に電源を入れるとOSが起動して言語選択(初期値はEnglish)、その後に無線LANの設定があります。メニューキーを押すとネットにつながらないままでトップの操作階層が表示されました。

現在のVoiceOverの問題点

iPhoneに存在する音声の問題点がそのままApple TVにも当てはまります。英字列の読み下しがおかしい点、日本語音声が音素レベルで崩れてぐしゃぐしゃになることがある点などです。また、日本語では検索などで使うソフトウェアキーボードの一部の記号が「ボタン」とだけ読まれて識別できません。ちなみにApple TVでは画面上でも日本語入力ができないので、検索はiPhoneのRemote Appを使う方がよいです。
それから、VoiceOverが有効だと、曲の変わり目で曲名をしゃべるのでちょっとうるさいです。iPhoneではHomeボタンを3回押すことでVoiceOverをOn/Offできますが、Apple TVにも何らかの工夫がほしいところです。

感想

iPod Nano, Mac OS X, iPhone/iPod Touchに引き続き、視覚に頼らなくてもちゃんと使えるようになっている点は非常にうれしいです。iTunesライブラリとAV機器とiPhoneなどをつなぐハブといった位置づけの機器ですが、\8800という価格でここまでできてしまうのは、iOSの共通プラットフォームと世界中で使われる市場の大きさによるところなのでしょう。Apple製品にはより隅っこの改良を要望したいところではありますが、それ以上に他メーカーが追従してくれることを望みたいです。

Mac OS Xアクセシビリティ勉強会やりました

先日1/30,31にただの個人の集まりであるArgument VectorMac OS Xアクセシビリティ勉強会というのをやりました。タイトルはMacですが、MaciPhoneアクセシビリティについて実演を交えながら語るというものです。
最初は仲間内の宴会のはずだったのですが、気がつくと結構オーバースペックな機材を使ったネット放送ということになってました。それぞれの資料もかなり力はいったものになってます。当日の録音が昨日公開されました。

Mac OS Xアクセシビリティ勉強会

私は序盤のVoiceOverで始めるMac OS Xというのを担当しました。しゃべりは下手なのでともかく、資料は現時点では日本のMac+VoiceOver入門としてアップルの資料の次によくまとまってるんじゃないかと思っています。(早くそうでなくなることを願いつつ。)

アップル製品は視覚障害者にとって、特に全盲者にとって遠い存在だったのですが、昨年発表されたiPhone 3GSのVoiceOverが日本語でもかなり使えることからユーザが増えています。Macについては価格もパソコンなのでまだ日本のVoiceOverユーザは両手分いないんじゃないかと思いますが、これからじわじわ増えていくことでしょう。そういう時期の記録としても今回の勉強会は意義があると思っています。