LoginSignup
2
3
アクセシビリティの知見を発信しよう!

Ionic5 系から 7 系にアップデートするときに起きた、アクセシビリティの問題と解決策

Posted at

ゼロバンク・デザインファクトリー株式会社(ZDF)でフロントエンドエンジニアをしている長島です。

アプリのアクセシビリティ改善で行っていること」でも触れた通り、みんなの銀行アプリは Ionic と Angular を使っています。Ionic のバージョンは v5.1.0 を使っており、現在 v7.8.6 へのアップデートを計画中です。そのテスト中に発覚したアクセシビリティの問題と解決策についてまとめます。

主に Ionic を用いてアプリを開発している人向けの内容ですが、最後の「学びと教訓」は他の UI ライブラリを使っていても同じことが言える部分があるかもしれません。また若干冗長になりますがこれまでの修正内容が前提になる個所もありますので、適宜上記の記事を参照しています。

具体的な課題と解決策

【課題 1】ion-list > ion-item の role 指定が上書きされる

みんなの銀行では暫定的に ion-itemrole="button"を指定している箇所があります(アプリのアクセシビリティ改善で行っていること > ボタンなどの要素の役割と名前を指定する)。アップデート後の Ionic ではion-list > ion-itemrole="listitem"が付与されるようになったため、この指定が上書きされスクリーンリーダーの読み上げなどからボタンであることが分からなくなってしまいました。

課題 1 の解決策

ion-itembutton というプロパティ(ion-item > Properties > button)を指定することで、 ion-item の下に button 要素がレンダリングされるようになります。矢印アイコンもレンダリングされますが、不要な場合は合わせて detail=false(ion-item > Properties > detail)を 指定します。

<ion-list>
  <ion-item button detail="false"></ion-item>
</ion-list>

ネイティブの HTML 要素を用いることで、role 属性がなくともスクリーンリーダーなどでボタンであることが伝わります。

【課題 2】連続してモーダルを閉じると、ルートが aria-hidden のままになる

みんなの銀行はモーダルを多用する構成になっています。モーダルを表示している間、その裏に表示している内容を支援技術から隠すという処理を入れています(アプリのアクセシビリティ改善で行っていること > モーダルの後ろにある内容を隠す)。

Ionic6 系 ではモーダルの裏側に aria-hidden="true"を設定するという類似の処理が入りましたが、モーダルを複数立ち上げた場合の考慮がされていませんでした。そのため複数モーダルを立ち上げた後にそのうちの一部を閉じると、まだモーダルが残っているにもかかわらず aria-hidden="true"の指定が外れてしまい、モーダルの裏側が支援技術から参照できるという問題がありました。GitHub の issue でモーダルが 1 つしかない場合に限り aria-hidden="true"を外すという修正案を提案し、概ね提案通りに修正してもらえました(bug: ion-router-outlet not marked aria-hidden when multiple overlays are presented and some dismissed)。

しかし今度はその提案にライフサイクルの考慮が足りていなかったために、別の問題が起きてしまいました。

  • フォーム入力モーダル(A)を立ち上げる
  • A の閉じるボタンが押下される
  • 入力内容を破棄して良いかの確認モーダル(B)を立ち上げる
  • B で OK が押下される
  • B を閉じる
  • A を閉じる

というフローがあった際に、B のwillDismissで A をdismissした場合、モーダルの数を正しく数えられず aria-hidden="true"が残ったままになってしまいます。モーダルがなくなっても支援技術から画面が隠れている状態になるので、後続の操作ができなくなってしまいます。

課題 2 の解決策

Ionic のコードではモーダルの数を数えるのにoverlay-hiddenというクラスが使われています。そのつけ外しタイミングがライフサイクルと嚙み合っていないので、全く別のフラグを立てるという修正案を GitHub の issue で提案しました(bug: root remains aria-hidden after dismissing multiple overlays consecutively)。どう嚙み合っていないかは若干込み入っているので割愛しますが、気になる方は GitHub の issue を参照するかコメント欄で質問してください。

Ionic7 系 を fork し修正案を適用すると事象が解決することを確認していますが、この issue はまだneeds: investigationというラベルがついたままでコアチームの調査中です。修正案を適用する際はその点にご留意ください。

【課題 3】iOS の VoiceOver でクリアボタンがある入力欄を操作すると、入力欄からフォーカスが外れなくなる

ion-inputclearInputを指定すると、入力をクリアするボタンがレンダリングされます。(ion-input > Properties > clearInput)。このクリアボタンに iOS の VoiceOver でフォーカスすると、入力欄にフォーカスが戻ってしまいます。

VoiceOver でクリアボタンにフォーカスすると、ion-input内のクリアボタンに対してfocusinイベントを発火します。focusinイベントはバブリングを行うので、ion-inputにイベントが伝播します。ion-inputfocusinではion-input内の入力欄にフォーカスを当てているため、VoiceOver でクリアボタンにフォーカスするたびに入力欄にフォーカスが戻されてしまうという挙動になっていました。

課題 3 の解決策

Ionic に GitHub の issue で問題を報告(bug: unintended re-focus to input after selecting clear input button with iOS VoiceOver)したところ、クリアボタンのfocusinイベントのバブリングを止める修正を入れてくれました。8 系を使っている人は、v8.0.1 以降のバージョンを使えばこの事象は起きません。

v7.8.6 にもバックポートが入っていますが、その際に Ionic7 系ではion-inputのレンダリング処理に 2 種類ある点の考慮がされていませんでした。新しいシンタックス(参考:ion-input > Migrating from Legacy Input Syntax)を使っている場合には正しく修正が適用されていますが、古いシンタックスを使っている場合は引き続き同じ事象が起きます。みんなの銀行では古いシンタックスを使っているため、 v7.8.6 を fork し、後者にもクリアボタンのfocusinイベントのバブリングを止める処理を入れています。

【課題 4】画面の表示内容を一度に全部読み上げる

ion-slidesが Ionic6 系で非推奨になり、Ionic7 系で削除されました(Migrating from ion-slides to Swiper.js)。私たちも今回Swiper.jsに移行することにし、何点か調整が必要になりました。

そのうちの 1 つが各スライドの読み上げの粒度です。アップデート前はスクリーンリーダーがフォーカスしている箇所のみ読み上げていたのですが、アップデート後はスライドに含まれる内容を全て読み上げるようになりました。

この挙動が問題にならないアプリもあると思いますが、みんなの銀行では画面遷移をスライドで実装している箇所が多くあります。その箇所ではスライド=画面であるため、何か操作をするたびに画面全体を読み上げるという状態になってしまいました。

課題 4 の解決策

こちらの原因はswiper-containerのデフォルトの role が group になっていることが原因でした。a11y-slide-role="general"を指定し role を上書きすると、スクリーンリーダーでフォーカスが当たっている箇所のみを読み上げるようになりました。

学びと教訓

今回のアップデートを通して大きく 3 つの教訓を得ることができました。

大きな UI の変更が入る際には、できるだけ早いタイミングから支援技術での確認を行う

iOS の VoiceOver と Android の Talkback での動作確認は、Ionic7 系 へのアップデート作業が始まったのとほぼ同じタイミングで始めました。まだ改善するべきところは残っていますが、結果として上記のような致命的な問題の解決はなんとかリリースに間に合わせることができました。これよりも遅い段階で支援技術での確認を始めていたら、上記の問題の原因特定と対応が間に合っていなかったかもしれません。

なかなか作業の時間を確保するのが難しい場合もありますが、UI を大きく変える場合にはできるだけ早いタイミングで支援技術での確認が必要だと改めて認識しました。

機械的に適用できる修正には静的解析のルールを作る

前回の記事で触れていた通り、パターン化できる改善は以前から Markuplint や ESLint を用いて静的解析を行っていました。「ion-list > ion-item の role 指定が上書きされる」のような影響範囲が多くの画面に及ぶ問題もありましたが、ESLint のルールを微調整することで自動で修正することができました。アクセシビリティの改善は現時点では人間の目で見る必要がある部分が多くありますが、それらに取り組む時間を捻出するためには自動化できる部分を自動化していく必要があります。

標準的な HTML やライブラリ機能で出来ることはそちらを使い、なるべく独自実装をしない

button要素ではなくrole="button"を使っている箇所など、開発速度を優先し抜本的なマークアップの改善をするのではなく WAI-ARIA の指定などで改善を行った箇所で修正が必要になりました。特に上記の「ion-list > ion-item の role 指定が上書きされる」で触れた書き方は Ionic5 でも同様の書き方ができたので、role="button"ではなく最初からそちらのプロパティを使うべきでした。

また、前回の記事の「モーダルの後ろにある内容を隠す」で触れた処理は上述の通りほぼ同等の処理が Ionic に入りましたし、「遷移時、スクリーンリーダーに遷移を通知する」の内容についても類似の機能が Ionic8 系で Experimental になりました(Managing Focus)。

結果論にはなってしまいますが、標準的な HTML の挙動や Ionic に入れ違いに実装された機能に近いことを自前で実装してきていた結果、余計な工数がかかってしまいました。まず標準の HTML・Ionic コンポーネントを使い、それでも出来ないことがあれば独自実装するのではなく Ionic にコントリビュートした方が、却って少ない工数で同等の改善がリリースできていたかもしれません。

まとめ

以上、Ionic を v5.1.0 から v7.8.6 にアップデートする中で見つけたアクセシビリティ関連の問題と解決策についてまとめました。Ionic や他の UI フレームワークの更新をする方の参考になれば幸いです。

2
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
3