アクセシビリティ改善の検討

[yncat]

実現したいこと

視覚に障害があっても、スクリーンリーダーを利用して麻雀を練習したい。
このアプリケーションは、ウェブベースで構築されているので、画面読み上げソフトウェアに比較的低コストで対応できる可能性がある。
画面表示に影響することなく改善できることが理想的だが、もしかすると特別な変更が必要かもしれない。

このissueで議論する内容

電脳麻将をスクリーンリーダーで操作できるように改善できるかどうか、実装面での相談をしたい。
実現可能なめどが立ったとして、その変更を公式にも組み込むか、forkしたアクセシビリティ対応版を作成するか決定したい。

前提

アクセシビリティ対応のために他のプレイヤーのUXを下げたり、既存の挙動を大きく変更するようなことは望んでいない。あくまでも、この対応によるダウングレードは出さない、だれも困らないことが前提。

現状気になっていること

これらの問題がなんとかなれば、かなり遊べるようになるのではないかと思う。

自分の持ち牌が正しく読まれない

rawdata の画像データに alt を入れることで解決できる。検証済み。

捨てられた牌や、ドラの情報が確認できない

詳しい原因はまだ調査していない。
スクリーンリーダーで見ると、牌数、得点、自牌画像、音声コントロール、速度コントロール、バージョンを認識できるが、それ以外が見えていない。

自分以外の対戦相手の行動が分からない

もっとも改善の難易度が高いと思われる。おそらく、今は卓の盤面上の牌が変化するのを見て状況を判断する、ということになっていると思うが、これはテキストで情報伝達しないと正確には伝わりにくい。
やり方としては、 live region を使って、 aria-live="polite" 属性を付けた領域に補助情報を書き込んで読ませる方法がある。
ただ、これだけだと補助情報が画面に出てしまうので、さらにこうする。

<div
  aria-live='polite'
  style='position: absolute; width: 1px; height: 1px; margin-top: -1px; clip: rect(1px, 1px, 1px, 1px); overflow: hidden;'>
  <div>ここを更新したら自動で読み上げられる</div>
  <div>あとからここに要素を追加したら、追加した物だけが読まれる</div>
  <div>{player_name} は {pai} を捨てた、みたいな情報を書いていく</div>
</div>

cssでやっているのはこの実装例

見ての通り、非常にハッキッシュなコードができる。forkしたほうがいいんではないかと言った理由はここにある。

泣けるかという問題

泣けるとき、おそらく何かクリックできる要素が出てきて、それをクリックすれば泣く、しなければ泣かない、というようなやりかたをしていると思う。この時、

• 出てきたことが分かるか
• 出てきたものを押せるか
  という問題があり、検証が必要。

[kobalab]

まず「前提」について了解しました。forkするか否かは修正内容によって判断しましょう。

こちらからは情報を提供します。
まず、視覚障害の方がどのように盤面を把握するかですが、以下の2つの方法があると思います。

1. 画面に見えている情報から把握する
2. AIに通知している情報から把握する

それぞれについて説明します。

画面に見えている情報から把握する

人間のプレーヤーが盤面を把握するのと同じ方法です。HTMLの適切な場所に適切な情報を追加することで実現できると思います。電脳麻将では雛形となるHTMLに牌を差し込んだり、classを追加したりで画面を変化させています。JavaScriptでHTMLをゴリゴリ書いている部分は少ないです。なので pug のソースか、そこからビルド済みのHTMLのソースを一通り見ればコントロールの類は全容を把握できるかと思います。

ご懸念の「鳴けるか」については可能なアクションをボタンで出しています。セレクタでいうと #game .UI に <span> でボタンが並んでいます(<span> はよくなかったですね)。class="hide" のものは現在押せない状態を示しています(CSSにより非表示になります)。

AIに通知している情報から把握する

AIが盤面を把握するのと同じ方法です。当然ながらAIは盤面のHTMLなど見てはおらず、プログラムが通知する「変化情報」(打牌や鳴きなど)だけを頼りに行動を判断しています。具体的には以下の部分です。

Majiang/src/js/majiang/player.js

Lines 28 to 43 in 0e53c64

	action(msg, callback) {
	this._callback = callback;
	if (msg.kaiju) this.kaiju (msg.kaiju);
	else if (msg.qipai) this.qipai (msg.qipai);
	else if (msg.zimo) this.zimo (msg.zimo);
	else if (msg.dapai) this.dapai (msg.dapai);
	else if (msg.fulou) this.fulou (msg.fulou);
	else if (msg.gang) this.gang (msg.gang);
	else if (msg.gangzimo) this.zimo (msg.gangzimo, 'lingshang')
	else if (msg.kaigang) this.kaigang(msg.kaigang);
	else if (msg.hule) this.hule (msg.hule);
	else if (msg.pingju) this.pingju (msg.pingju);
	else if (msg.jieju) this.jieju (msg.jieju);
	}

この msg が「変化情報」になります。この詳細は以下のブログ記事で解説しています。(情報が古いので形式が今と若干異なりますが雰囲気は伝わると思います)

• 麻雀の局進行のプログラム方式

msg の内容を読み上げれば、「東家、一索をツモ切り」のような情報を出すことが可能です。

ただし、この方法だけに頼る場合、盤面の把握は難しくなると思います。頭の中で将棋を差すような状態ですね。

以上、ご参考まで。

[yncat]

返信が遅くなってすみません。
本業が忙しく、やっとある程度調査できました。
数週間前に麻雀をやりはじめたため、用語として適切でない説明があるかもしれませんが、ご容赦ください。

盤面の把握について、ある程度現実解が見えてきたので、相談させてください。

基本的には、ひとまず (1) の "画面に見えている情報から把握する" の方向で、なんとかなるのではないかと考えています。全体を一気に見ることはできないため、通常時よりも時間はかかりますが、読み上げができれば判断は可能そうでした。
2番の "AIに通知している情報から把握する" は、あればプレイは早くなると思いますが、1と比べると設計が大変なので、とりあえず今は優先度を下げてもよいと思います。

盤面の把握を実現するために、最低限必要なことは以下の2つだと思います。

(1) rawdataの牌画像にaltを入れる

これは絶対に必要です。
altがないことによって、自分の手牌を除く全ての牌の状況が、スクリーンリーダーからは見えません(逆に、自分の手牌だけが見えている原因は謎です)。
詳しいところは、スクリーンリーダーの仕様とも関連するのではっきりとは分かりませんが、DOM上で深いところに画像があるときに、altがないと読み上げから漏れてしまうことがあるようです。altを付けると改善されることは確認済みです。
挿入するaltの内容ですが、漢字で記載するとスクリーンリーダーの読み上げがへんになることがあるため、p1なら「イーピン」のように、カタカナで入力しておくのがよいかと思います。

(2) divで表現されているセクションに名前を付ける

rawdataの画像は、 (1) の対応によって全て読み上げ可能になるのですが、これだけだと、いろんな牌の名前をひたすら読まれるだけ、という状態になります。今読んだものが、自分の手牌なのか、だれかの捨て牌なのか、ドラなのか、ということがまだ分かりません。
ドラや、各プレイヤーの捨て牌は、クラス名で識別され、専用のdivセクション内に描画されると思います。これを利用して、各領域に識別可能な名前を付けることで、盤面におけるどの場所にある牌なのかを認識できるようになります。マークアップとしては、 region role を使用します。
たとえば、プレイヤーの手牌に対して適用するときは、以下のようにします。(クラス名を読み間違っていたらすいません)
"game"/"shoupai main"/"bingpai"の div に、以下の2つの属性を追加

• role="region"
• aria-label="プレイヤーの手牌"
  ドラの場合は、たぶん、こうなります。
  "game"/"chang"/"shan"/"baopai"にある div に、同様に属性を追加。
• role="region"
• aria-label="ドラ"

こうすることで、たとえばドラの牌が表示されているところにカーソルを移動したとき、　「ドラ　リージョン、　イーピン」というふうに読まれるようになります。

以上の修正ができれば、スクリーンリーダーだけでプレイすることは可能になると思いました。全部ではないですが、ゲーム中にwebコンソールで似たような感じでDOMを書き換えてからやってみたところ、あがりまで到達できました。
これらの変更は、いずれも、表示内容には関係ない修正のため、既存の表示や挙動が変化することはありません。

ご検討いただけると幸いです。

[kobalab]

取り急ぎ作業ブランチを切りました。

• https://github.com/kobalab/Majiang/tree/feature/%2389

もし修正してみる場合はこのブランチでお願いします。
明日時間が取れれば牌へのalt挿入くらいまでは作業しようかと思います。

私自身がVoiceOverの操作に慣れていないので確認がうまくできないのがもどかしいです。
(テキストサイトの読み上げはある程度できるようになったのですが、飛ばし読みの仕方がわかってないです)
バリアフリーなアプリに興味がわいてきたので、ぼちぼち作業はしようかと思います。

まあ、慌てずやりましょう。

[kobalab]

feature/#89 ブランチの 63debdd の修正で、牌の画像にalt属性を追加してみました。確認してみてください。

私も Mac + Safari + VoiceOver で操作してみたのですが、牌にフォーカスが当たりません。これはマウスクリックで卓が選択状態にならないように卓相当のHTML(セレクタだと#game)に user-select: none のスタイルを設定しているからと思い外してみたのですが、それでもフォーカスされません。何かヒントはありませんか？

transform: translate() で位置を移動させていることが原因ではと推測しますが、それが正しいのならVoiceOver用の画面を作った方がいいかもしれません。現在の画面は視覚効果のために色々いじっているのですが、それがナビゲートの邪魔になっている可能性があるからです。

[yncat]

早速作業してくださりありがとうございます！
普段、支援技術を利用されていない方にとって、動作確認が大変なのはまったくその通りで。色々調べてくださり、感謝いたします。私は Windows と Mac のどちらにも対応できますので、情報提供は惜しみません。

いつもは Windows でやっていたのですが、 Mac にも開発環境をセットアップして、 VoiceOver でやってみました。
牌にフォーカスを当てるのは、 ctrl+ option + 左右矢印を使えば可能です。上下矢印をそのまま押しただけだと、確かにゲームの領域をまるごとスキップしてしまいますね。
矢印だけを使用した際に読み飛ばされる原因は、おそらく VoiceOver の挙動によるものなので、確定的なことは分かりません。ただ、 VoiceOver を常用する人は、通常 ctrl + option + 左右矢印で画面を順番に読んでいくはずなので、大きな問題にはならないのではないかと思いました。
余談ですが、 iOS の VoiceOver では、この操作は左右のフリックに割り当てられています。そのため、 Majiang 事態が対応していれば、 iPhone などの端末でも同様に遊ぶことができます。

alt属性が着いたことにより、盤面の牌を認識できるようになったことを、 Windows + NVDA 、および Mac + VoiceOver で確認しました。

[kobalab]

role="region" を追加しました。これで盤面の見えている情報はだいたい把握できるようになったかと思います。

あとはクリックできる場所が分かるようにしないといけないですね。クリックできる牌を<a>で囲えばいいのかな？
すいません。質問ですが、VoiceOverで「クリック可能」と言われた時に、どういう操作で実際にクリックできますか？

[yncat]

ありがとうございます。かなり分かるようになってきました。
(以前のコミットですでに入っていたかもしれませんが) 本場/供託もしっかりと読み上げられていました。

リージョンが着いたことで、牌が置かれている場所が分かるようになりました。

VoiceOver で要素をクリックするには、 ctrl + option + スペースバーを押します。

クリックできる牌を分かりやすくする方法ですが、見た目に影響がなければ a タグを使ってもよいですし、 button タグを使ってもよいです。ただ、基本的には見た目が変わる気がします。リンクであれば、架線？が入ったりなど。
通常のHTMLタグが使えない場合は、クリックできる牌に role="button" 属性を追加すれば、「イーピン、ボタン」のように読まれるようになるので、クリックできることは伝わります。

ここからは多少挙動が変わるので、対応として必須というわけではないのですが、クリック可能な牌には、 tabindex="0" 属性を追加していただきたいです。これにより、タブキーを押したときに、クリック可能な牌にフォーカスが当たるようになるので、キーボードでの操作性が向上します。
挙動が変わる点としては、単純に、タブキーを押したときにフォーカスされる項目数が増えます。マウスで操作していれば、影響は薄いと思われます。

[kobalab]

自分の手牌にタブで移動できるよう tabindex="0" を追加しました。

これを行ってみて1つ疑問がわいています。それはタブでの移動とVoiceOverでの移動(ctrl + option + 左右矢印)の使い分けです。私としてはタブ移動はクリック可能な場所のみとした方がよいと思います。今回の修正は実は微妙にそうではなくて、相手の思考中は自分の手牌はクリックできない(クリックできたら打順を飛ばしてしまう)にも関わらずタブ移動できてしまっています。

けれどもう一つタブの使い方にアイデアがあって、「東一局」や相手の捨て牌などVoiceOverでの移動が遠いところにジャンプするような操作に使ってもいい気もしています。

VoiceOverの操作に慣れている方からするとどのような使い分けが自然でしょうか。

[yncat]

修正ありがとうございます！
最新のコミットでビルドして試してみました。
今までは、盤面を確認した後、手牌を選ぶために、手牌リージョンを探す必要がありましたが、タブキーを押すだけでたどり着けるようになったので、操作性が向上しました。

ご質問の件は、使用者によって多少好みが分かれる部分でもあると思いますが、個人的な見解で回答します。

まず、いつでもクリックできるように見えてしまって、打順を飛ばして押せてしまうかも…という件について。
これは、
"実装上は、他のプレイヤーが打っているときにクリックしても反応しないようにはなっているが、読み上げではクリックできそうに聞こえるので、混乱しやすいのではないか"
ということでしょうか？それとも、実際にクリックされてしまうと順番が飛んでしまうでしょうか？
もし、前者の場合なら、 aria-disabled属性 を追加して、自分が操作可能なときに値をtrue、操作不能のと機にfalseに変化させれば、スクリーンリーダーが自動で認識して状態を読み上げてくれます。

次に、タブキーを遠い場所へのナビゲーション手段として使う件についてです。
おっしゃるとおり、基本的には、何らかの操作を実行できるものに対してのみ、タブキーでフォーカス可能であることが望ましいと考えています。なぜかというと、そのほうが html の標準仕様に近く、音声読み上げを利用しているユーザーが推測する挙動にも近いからです。(上で言及していた手牌一覧のように、条件によって使用不能となるコントロールは、この条件を厳密に適用すると、タブキーでのフォーカス可能/不可能が動的に変わってしまうので例外とします。)
"東一局"から始まる各種情報は、比較的ページの先頭(DOM上での話です)に近いところに配置されています。そのため、ページ先頭に戻って、下矢印キーで次の行に移動すれば到達できます。つまり、どこにいても2ステップでたどり着けることになるので、タブキーでのフォーカスはしなくてもいいのかなと考えています。
Windowsの場合: ctrl+home を押した後、下矢印。
Mac の場合: cmd + 上矢印 を押した後、下矢印。

Voiceover を使用しているときの各種ナビゲーションコマンドの挙動は、大まかに説明すると以下のような感じです。
上下矢印: 論理行単位で移動。
ctrl+option+左右矢印: DOM 要素単位で移動。
tab または shift + tab: html 標準でフォーカス可能な項目、または、明示的に tabindex >=0 指定されている項目間を移動。ただし、 Mac の Safari では挙動が異なり、一気にWebコンテンツの外まで出てしまう。 Mac の Chrome あるいは Firefox であれば、この問題は発生しない。

[kobalab]

情報ありがとうございます。いくつか修正してみました。

• クリック可能な要素(牌、チー/ポン などのボタン)に tabindex="0" を追加
• 画面上の手牌などの並び順を 自分 → 下家 → 対面 → 上家 に変更

これでだいぶ遊べるようになるかと思いますが、ちょっと問題があって、チー/ポン などのボタンをキャンセルできません。マウスでのUIでは盤面の任意の場所を押してキャンセルできるのですが、VoiceOverではその操作はできないのではないかと思います。また、チー/ポン などのボタンが現れたことの把握が難しいと思います。ポップアップ類が出現した時同様の操作性にしたいですが、今の所やり方がわかっていないです。

[yncat]

修正していただいていたのに、またもや間が開いてしまい申し訳ありません。
今週末あたりで、修正いただいたところを確認しつつ、モーダル外のクリックをどうするか考えてみたいと思います。
おそらくは予想の通りで、泣かないときに必ずモーダル外をクリックする必要があるなら、それは普通の操作では不可能です。モーダルの外をクリックするということを理解した上で、まったく違う場所でクリック操作をする、というようなことをすれば進めるでしょうが、あまり直感的ではないのかなと思います。
実際にやってみるので、もう少し時間をください。

[kobalab]

大丈夫です。焦らず進めましょう。

[yncat]

最新の修正を適用した状態で、何度かプレイしてみました。

泣くときに、ボタンの出現に気がつけないかもしれないという懸念

こちらについては、確かに出たタイミングがその場では分からないのですが、プレイのうえではそこまで問題だと思いませんでした。というのも、

• 入力待ちになってゲームが停止する
• 自分の番が来たと思って、タブキーで牌を選択し始める
• チーやポンなどのモーダルが出ているときは、タブキーでの移動は自分の牌を飛ばして、「チー」や「ポン」のボタンに移動してくれる
• この段階で、チーやポンができる状態にあることを把握できる

という操作をしていたので、泣きたかったのにモーダルを見逃したため機会を逃してしまった、というような問題は発生しなかったからです。

モーダル外のクリック

こちらは、モーダルの外であればどこでもよかったので、適当に盤面の牌などを選択してエンターを押すことで、モーダルを閉じることが可能でした。これは、スクリーンリーダー側が、エンターを押したときにクリックイベントをブラウザに送信してくれるため実現できています。スクリーンリーダーの仕様に依存した回避方法のため、Macで同じことができるかどうかを明日検証してみます。
モーダル外のクリックが必要なのは、泣かない場合もそうですが、局が修了後、次に進むときにも同様ですね。
我々のように、普段からスクリーンリーダーを利用しているユーザーからすると、モーダルを閉じるボタンがモーダル内にあることを期待します(スキップボタンや、次へ進むボタンなど)。ただ、モーダルを閉じるために外をクリック/タップするというのは、一般知識としては有効であるべきと考えています。WindowsとMacの両方で、スクリーンリーダーを利用していてもモーダル外を押せることが確認できれば、追加の対応は特に必要ないのかなとも思います。

追加で気がついた問題点

一方、どの種類の牌をチー/ポンしようとしているのかは、なかなか把握が困難でした。
現在の仕様的に、対象とする牌の名称が取得可能であれば、「イーピンをチー」のように読み上げられるとよいのかなと考えています。
やり方としては、普通に画面表示を変えてしまう方法と、画面表示はそのままで読み上げだけ変える方法があります。
画面表示に影響を与えたくない場合は、htmlの aria-label属性 を使用します。
これを使うと、実際に画面に表示されている内容よりも、 aria-label 内のテキストを優先して読み上げさせることが可能です。
たとえば、

<p aria-label="閉じる"> x </p>

というような要素は、 "x" ではなく、 "閉じる" と読み上げられます。
これを応用して、画面上の表示は以前と変わっていないけれども、 aria-label にだけ "イーピンをチー" のようなテキストを入れて、スクリーンリーダー利用者のヒントとして使うことが可能だと思われます。

ご検討いただけましたら幸いです。

[yncat]

遅くなってすみません。
MacのSafariでも、モーダル外のクリックが可能かどうか試してみました。
Windowsのときと同じ方法でクリック可能でした。
多少の知識は必要になりますが、関係ない牌などをエンター(voiceoverの場合はcmd+option+スペースバー)で閉じることができます。

[kobalab]

反応が遅くて申し訳ありません。

電脳麻将改造中 - koba::blog で触れているのですが、今全面的なリファクタリングをはじめており、その中でアクセシビリティの改善も行う計画です。
UIに関してはまだリポジトリだけ作った段階ですが、これからここに手を入れて行こうと思っています。

• kobalab/majiang-ui: 麻雀UIライブラリ(作成中)

進捗したら連絡しますので、触って見ていただけると幸いです。

[kobalab]

モーダルの動作を見る限り、アクセシビリティを考慮した作り替えが必要かなと思っています。
先の返答でも触れたように今全体のリファクタリングを開始しているので、そこで本格的に対応しようと画策中です。

とりあえず1人麻雀でツモと打牌ができるデモを作ってみました。

• https://kobalab.net/majiang/v2/paili.html

[yncat]

改善の検討、ありがとうございます。インターネット越しの対戦も計画されているとのことで、うれしくなりました。
麻雀をオンラインで友達とプレイしたいという視覚障害者はかなり(おそらく10人以上は)いると思います。一般的に普及しているサイトでは、やはりウェブアクセシビリティの関係で、十分にプレイすることができない状況にあります。
電脳麻将のプログラムや、ユニットテストで実行されている内容から判断して、ゲームのシミュレーションとUI層がかなりしっかりと分離されているように見えていたので、(ブログにもあるとおり変更箇所が少なくはないのでしょうが)サーバ/クライアントモデルへの変更も視野に入れられているのかなと考えていました。仲間にも共有できそうで楽しみです。
現状のデモプログラムも試してみました。牌の読み上げもしっかり行われていて、まったく問題なく操作することができました。
次のメジャーバージョンのリリースを楽しみにしております。オンラインでの対戦機能を付けようとすると、動作確認なども大変だと思いますので、ゆっくりお待ちしています。
アクセシビリティ関連でなにかありましたら、このissueにコメントか、 私に直接 (personal [at] nyanchangames [dot] com) ご連絡いただけると幸いです。
改めまして、このたびのご対応に感謝いたします。今後ともどうぞよろしくお願いします！

[kobalab]

とてつもなく時間が空いてしまいましたが、プログラムを更新しました。

• https://kobalab.net/majiang/v2/

以前ブログに書いたのですが、プログラム全体をリファクタリング中です。
大まかには以下の状況です。

• 基本部分のリファクタリングはほぼ完了し、UIのリファクタリングに着手したところ
• AIも作り直し中で、現在のバージョンはかろうじてゲームができるレベルで弱い(主にUIの確認に使う目的なので)
• 画面上の主な部分に読み上げに必要な情報は入れたので静的な状況把握はできそう
• 相手の打牌や鳴きの把握はまだ改善が必要。どのような形で改善するか検討中
• チーのやり方が選択可能なケースのUIが未作成
• ゲーム最後の成績表を出す画面が未作成

かなり間が空いてしまいましたが、まだ興味があるようでしたらお試しいただけると幸いです。

[yncat]

ご連絡ありがとうございます!
丁度今年の活動を振り返ってまとめていたときに、このissueをのぞいたところでした。
本業のほうがなかなか忙しく、確認は年末になるかと思いますが、実行して試してみたいと思います。

[yncat]

遅くなって申し訳ありません。

数人で、それぞれ何度かプレイしてみました。

全体的には、以下の2つにまずはフォーカスして考えられると、劇的にプレイしやすくなるのではないかという意見でまとまりそうです。

1. 相手の打った牌を、相手が打ったタイミングで自動で読み上げられるようになるとよさそう
2. 自分がどのポジションにいるのか(東西南北)の情報が今は分からないので、戦略を立てるためにその情報がどこかから取得できるとよさそう

1について、まだ実際に検証はできていないのですが、 aria-live属性 を打牌のエリアに付けるだけで、もしかするとどうにかなってくれる可能性があります。

[kobalab]

返信ありがとうございます。

UIの修正になかなか着手できていないのですが、明日からちょうど旧正月の休暇に入るのでこの機会に手をつけようと思っています。

相手の切った牌の読み上げですが、流れの中で読み上げるのが難しそう(VoiceOverがない状態だと打牌速度はだいたい1秒以内になる)なので「ステップ実行」的なモードを導入しようと思っています。相手の動作を読み上げてそれを確認してから次へ進むイメージです。

それと、まだチーの候補が複数ある場合のUIを実装していないのでこれも実装が必要です。

進捗したらまた連絡します。

[kobalab]

間が空いてしまって申し訳ありません。
一通りゲームができるようになりました。

• https://kobalab.net/majiang/v2/

ゲームの進行のさせ方には2つの案がありました。

1. 相手の打牌のたびに停止し牌を読み上げ、リターンキーを押すと先に進む
2. 相手の打牌のタイミングで割り込んで牌を読み上げる

今回は2を採用し、捨て牌を aria-live で読み上げるようにしましたが、ブラウザによってはボタンが出るタイミングとぶつかると読み上げが飛ばされる場合があるようです。

まだ以下の問題があり修正が必要と思っています。

1. 他者が副露したのがわかりにくい
2. 複数の副露の候補があるとき、選択肢がわからない(role="button" の内部が読み上げられないため)
3. 和了情報、流局情報の内部が読み上げられない(role="button" を設定したため)
4. 終局時に出てくる集計画面の読み上げがメチャメチャ(表の記述順に読み上げてくれない。chrome読み上げのバグ？)
5. 各局の開始時に「東一局1本場、ドラは一萬、持ち点は……」みたいなアナウンスができるとすごくよい

時間があるときに遊んでみていただけると嬉しいです。

[yncat]

引き続きの対応、ありがとうございます！
実装の詳細について情報提供しようと思っていて、なかなかまとまった文章が書けずにいてすみませんでした。情報が少ない中で実装してくださり、感謝しています。
ゲームの進行のさせ方については、ひとまずは今の方式でよいと考えています。自分の順番が回ってくるまでに起きうることは、通常それほど多くないと考えられるので。
今週末に何人かにプレイしてもらって、自分もやってみて、フィードバックをまとめてお送りします。
まだ詳しいところを見ていないので外しているかもしれませんが…。ブラウザは、基本的にDOMツリーを再帰的に転回しながら、それと同じ順番で読み上げのための情報を構築していくという性質があります。CSSによってDOM順と表示順の明らかな差があるとき、意図しない読み上げ順序になる場合があります。結果画面のところは、注意して確認してみます。そもそも、正しいものが読めているのか自信がなかったら、スクリーンショットなども撮影しておきます。

[yncat]

こんにちは。
状況報告ですが、Windowsだとうまく読み上げてくれなかったので、Macでも試そうとしているところです。テストできたらまた書き込みます。

[kobalab]

こんにちは。
Windowsではダメですか…… 自宅にWindows環境がないので確認できてないです。
さすがに会社で麻雀アプリの音声読み上げはできない……

他の実装もあり急いではいませんので、時間があるときに状況を教えていただければと思います。

[yncat]

こんにちは。

Macで動かしたところ、読み上げされていました。これは、WindowsとMacの、読み上げソフト側の実装の差異によるものなので、とりあえず横に置いておいても大丈夫だと思います(対応方法は思いついています）。ひとまず、Mac環境で再現できる習性を順番に議論して、落ち着いた頃にWindowsへの対応についてはご紹介させていただきます。

かなり遊べるようになってきたので、Voiceoverでのゲームプレイを録画しました。ブラウザの画面を画面共有で映して、Zoomで録画したので、たぶん映像も大丈夫だと思います。私のプレイにほぼ戦術がないのはご容赦ください。初心者なので...

https://www.dropbox.com/s/2tyea5cwtmbykr4/video1057106885.mp4?dl=0

牌の読み上げについては、このように読み上げてもらえば、まったく問題ないと思います。
チーやポンなどのアクションを選択するところで、「キャンセル」ボタンが設置されたのも、とても助かりました。
「チーをしたもの」、「ポンをしたもの」も専用のグループに入るようになっているので、こちらも改善していただけて、プレイがしやすくなりました。
結果の表示は、動画の中でも読んでいますが、なんとなく実際の状況と合った読み上げがちゃんとできているのではないかなと思いました。ただ、なぜか１回目はフォーカスが結果画面に載らなかったので、読めませんでした。これはもうすこし調べて見ないとはっきりとは分からない感じです。

そのほかに気がついた点は、以下のようなことです。
チーやポンなどをするとき、獲得予定の牌を把握することが少し難しいと感じました。おそらく、CPUが最後に打牌したものなので、一瞬読み上げていると思うのですが、直後にボタンにフォーカスが乗るため、読み上げが上書きされていると思います。対策としてすぐに思いついたものは、ボタンにaria-label属性を追加して、その中に「サンソーをチー」というようなテキストを入れてから描画する方法です。この方法では、画面表示はまったく変わりませんが、ボタンにフォーカスを載せたときの読み上げが、「サンソーをチー」になるので、空いてからなんの牌を得るのかがすぐに分かるようになるかなと思いました。
もう一つ、自分がいる盤面上のポジションを把握することに関して、困難があるかなと思いました。東/西/南/北のどこに配置されているかということです。
見逃していたら申し訳ないのですが、今の状況でこれを把握できるタイミングは、以下の２つしかなさそうに思いました。

• 自分があがることができて、結果画面で点数が増えたのを見た時
• 空いてからロンを受けて、結果画面で点数が減ったのを見た時

とはいえ、打牌がリアルタイムに確認できるようになったことで、麻雀をプレイしているという感覚がかなり強くなりました。改善していただき、ありがとうございます！

[kobalab]

確認いただきありがとうございます。

まずは他者の打牌とボタン表示のタイミングがぶつかったときに打牌の読み上げがかき消される問題に対処しないといけないですね。ご指摘のようにボタンの aria-label に直前の打牌の情報を入れるのがよさそうです。

自分のポジションがわかりにくい問題は、配牌時に「東一局 1本番 ドラは一索、あなたは南家です」みたいなアナウンスが入れられればよいですが、読み上げソフトを使っていない人に取っては待ち時間が長すぎる気がします。これらの情報は画面の一番先頭にありますので、最初のツモを引いたタイミングなどで確認してもらうのがよいと思います。

修正したら、また連絡します。

[kobalab]

ご無沙汰してます。

先ほど電脳麻将の ver.2.0.0 をリリースしました。
https://blog.kobalab.net/entry/2022/11/11/212624

ブログで言及しましたが、電脳麻将のプログラム解説書を出版することになり、この半年はそれに注力していました。そのために機能追加が後回しになってしまい申し訳ありません。
年内出版予定なので、まだ校正作業が続くのですが、出版し一息ついたらアクセシビリティ改善の検討を再開するつもりです。

近況報告だけですいませんが、まだ続けてますということだけ気に留めて頂ければ幸いです😁

[yncat]

リリースおめでとうございます！
プログラム解説書の出版すごいですね。技術面に振った書籍は色々ありますが、麻雀ゲームに特化したものはなかなかないと思います。
ある程度落ち着きましたら、引き続きよろしくお願いいたします。