この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
アクセシビリティの祭典は、チームアイコラボが2015年から主催するイベントで、2023年は9回目の開催になるそうです。
クラスメソッドとしては、2021年からスポンサーとして応援させていただいています。
今年は「アクセシビリティ・サイクル ～人の繋がりが世界を変え続ける～」がテーマとのことで、これに合わせて「障害当事者の困りごとと受託開発をどう繋げるか」というテーマでスポンサーセッションに登壇させていただきました。
登壇内容
(一部省略があります)
障害当事者の困りごとと受託開発をどう繋げるか
クラスメソッドからは『障害当事者の困りごとと受託開発をどうつなげるか』というテーマでお話しさせていただきます。
背景(1)
コロナ禍を契機として、いわゆるデジタルトランスフォーメーションが進んだことは、障害当事者の方の生活を向上させた側面があるかなと想像しています。例えば、飲食店のテイクアウト予約のデジタル化やECの進展などがあり、外出が困難であったり対面のコミュニケーションが困難な方にとっては、自力での買い物のハードルが下がったのかと想像します。
しかしながら、そうしたオンラインサービスやスマホアプリなどがアクセシブルでないことも少なくありません。
このような、アクセシビリティに起因する生活のさまざまな場面における困りごとについて、障害当事者の方々が意見を表明されことを目にすることがありますが、そのような勇気ある意見表明が行われても、残念ながらそれが届いた事例はあまりないかと思います。
これは、アクセシビリティ・サイクルが途切れている状態と考えます。
背景(2)
ここでサービスを大きく2つに分類してみます。自社開発と受託開発です。
自社開発とは、サービスを提供する企業が自分たちでエンジニアを雇用して自社でサービスの開発やメンテナンスをおこなうサービスです。
受託開発は、サービス提供企業が、他社に開発を依頼し、私たちクラスメソッドのようなお客様の事業課題を解決する技術力を提供する企業が受託して開発を行うスタイルです。
最近は、自社で開発しているサービスを提供している企業の中からアクセシビリティを向上させる取り組みを加速させるところが複数出てきました。それらは歓迎すべき動きですが、障害当事者の方々が使われるサービスには、受託開発によるものも多くあります。
先日、Microsoft Ability Summitのあるセッションでは、「世界人口の約15%が障害を持っているが、障害のある顧客や従業員へのサービス提供に注力している企業はわずか4％」というデータが紹介されていました。
Approximately 15% of the world’s population have a disability, but only 4% of businesses are focused on expanding their offerings to customers and employees with disabilities.
This session at #AbilitySummit discusses measuring disability inclusion ? https://t.co/iJ4nFA7C83
— MSFT Accessibility (@MSFTEnable) April 17, 2023
それでは、受託開発を行ってる私たちのような企業が、障害当事者から「困っている」というバトンを受け取った時に、どのようにすれば受託しているプロダクトのアクセシビリティを向上させることができるのでしょうか。
今日は、その点について提言をおこないたいと思います。
受託開発の流れ
まず、ご説明に際して、受託開発の大まかな流れをご説明します。
最初に行うのがプリセールスです。
これは、開発契約を締結する前に実施する作業で、ここで、お客様から開発したい内容をうかがったり、それに対して開発する我々からプロジェクトの提案や見積もり提示などをおこないます。
開発契約を締結した後は、要件定義を行います。これは開発する内容を具体化していく作業です。
その後、画面などのデザインを行います。
次に、開発内容の詳細設計を行い、実際にプログラミングを行う実装に移ります。
実装が終わったらテストを行ってからリリースします。
リリースを終えると、みなさんが実際にサービスを使える形になります。
受託で開発するサービスをアクセシブルにするために、先ほどご説明した受託開発の各段階で、どういうことをすべきなのかについて順にご説明します。
1. プリセールス＋要件定義でやるべきこと
まず、プリセールスと要件定義のフェーズで行うべきことです。全体の中では、このフェーズが一番重要かなと思います。
まず最初に、お客様からの、こういう開発をしてほしいという依頼内容の中でアクセシビリティが考慮されてない場合は、私達の方から、プロジェクト全体でアクセシビリティの視点を持つことの重要性を説明することが必要です。
開発するサービスで、他社との差別化をどう図るかという視点がありますが、そこに「できるだけ多くのユーザーが使えること」を目指すことを提案したり、デザインや実装、テストのフェーズでアクセシビリティ向上作業が必要であることをご了承いただくことが必要です。
次に、開発するサービスでのアクセシビリティ方針を定めます。例えば、アクセシビリティに関するJIS規格やWCAGで定められているレベルや対応度を示します。
最後に、ここまで検討してきた内容を、プロポーザル、見積書、要件に盛り込みます。
2. デザインフェーズでやるべきこと
その次のデザインフェーズでは、WCAGのガイドラインに沿ったいくつかの作業が必要です。
例えば、情報を伝えるために、色が唯一の手段になるようなデザインを避けるようにします。
また、よく話題になりますが、UIやコントロールなどは、前景色と背景色のコントラストを確保したデザインにします。
ダークモードのデザインも重要です。ダークモードは、「羞明」と呼ばれる、ディスプレイの眩しさが痛みと感じるユーザーにとっては必要です。
WCAG2.1には、そのほかにキーボードフォーカスの可視化やデザインに関する達成基準がいくつかありますので、方針で決めたWCAGの適合レベルの達成基準にそってデザインに反映すべき項目を洗い出して対応していきます。
3. 画面実装でやるべきこと
次の画面実装のフェーズでは、デザイン以外のさまざまな事柄に対応する必要があります。
Webアプリケーションの場合は、画面全体を正しいHTMLでマークアップすることが必要です。
最近の、Reactなどのフロントエンド実装では、コンポーネントと呼ばれる部品ごとにアクセシビリティのチェックが行わることはありますが、画面全体のDOMが妥当な文章構成になっているの確認が重要です。
また、画像などの非テキストコンテンツにalt属性のような代替テキストの設定が必要ですし、すべての操作がキーボードで操作できるような対応も必要です。
WCAG2.1には、その他にもフォームへのラベル設定など、single Aであっても必要な対応がいくつかありますので、適合レベルの達成基準に沿った対応を実施する必要があります。
4. テストでやるべきこと
テストフェーズでは、ここまで実装を行ってきたものについて、テストを実施します。
大きくは単体テスト、E2Eテストがあります。単体テストは、いわゆるコンポーネントと呼ばれる画面部品単位でのアクセシビリティのチェックを行います。
ある程度、画面の開発が進んだらE2Eテストでアクセシビリティのテストを実施します。これは、プログラムでブラウザを自動制御して画面全体のDOMをチェックする方法が用いられます。
可能であれば、障害者によるユーザーテストができれば理想です。まずは、MVPなどのプロトタイプの段階で最初の意見をうかがって、完成後に、シナリオテストができることが理想です。テストしていただく当事者の方が、どのような障害をお持ちなのかによってもお困り事が異なるので、製品の方向性とかとともにシナリオの検討が必要かなと思います。
5. 運用フェーズでやるべきこと
無事にサービスのリリースが終わり、本番運用のフェーズに入った後もやるべきことがあります。ユーザーからのフィードバックを受ける仕組みとフィードバックを改善に生かす体制です。
JIS X 8314-3の附属書にもありますが「公開した後も高齢者・障害者からの意見収集に努めて問題が指摘された場合には対応方法を検討して可能なことから対応する」ようにということが求められています。
例えば、障害当事者の方がリリースされたサービスのアクセシビリティの問題に直面し「障壁を除去してほしい」というお申し出をフィードバックしていただいた場合には、障害者差別解消法に基づいて合理的配慮の提供が求められます。
そういうことも含めて、受託開発の場合はお客様にそういう体制を整備していただく必要です。
今後に向けて
先日、障害者差別解消法が改正され、2024年4月1日から施行されることが決まりました。
これから民間企業も含め、より多くの受託開発サービスにおいて環境の整備としてのアクセシビリティ向上の必要性が高まります。
私たちも、これから受託開発させていただくお客様に、アクセシビリティの重要性を説明し、より多くのアクセシビリティ・サイクルをつなげていきたいなと思っています。
17
