freeeアクセシビリティー・ガイドラインVer. 202011.0を公開しました

こんにちは、freeeのアクセシビリティーおじさんというよりはガイドラインおじさんの中根です。
LiDARスキャンに惹かれてついうっかりiPhone 12Proを発注したのは良いのですが、とりあえずケースだけ届いて何とも言えない気持ちになっています。ちなみに次に届くのはMagSafeの充電器らしいです……。

さて、今回もfreeeアクセシビリティー・ガイドラインの更新情報をお届けします。 なお、本稿で触れていない変更もありますので、リリース・ノートも合わせてご覧ください。

WCAG 2.1との対応を確認

まず、今回は新たに以下の情報を追加しました:

前者は、WCAG 2.1の各達成基準について、「この達成基準を満たすにはfreeeのガイドラインのどれを満たせば良いんだ?」と思った時に参照できる一覧表です。

後者は、このガイドラインの優先度とWCAG 2.1の各達成基準の適合レベルの関係などについて示しています。
というのもよく分からない説明な気がするので、この情報の冒頭部分を引用します:

各ガイドラインには、[MUST]または[SHOULD]のいずれかの優先度を割り振っています。

この優先度の決定に当たって、まずWCAG 2.1の各達成基準を精査しました。 各達成基準に割り当てられている適合レベルについて、freeeのプロダクトの性質などを考慮して見直し、一部の達成基準についてはWCAG 2.1が示すものとは異なる適合レベルを前提とすることにしました。

ここでは、見直しの結果WCAG 2.1が示しているものとは異なる適合レベルを前提とすることになった達成基準の一覧と、適合レベルを見直した理由を示します。

どうでもいいことですが、このガイドラインのソースの記述に使っているreStructuredTextでこれらの表を作るのは、もうそれは大変な作業でした。特に一度作ったものを更新するのは、面倒この上ない感じです。
もう二度と更新したくありません……。

ガイドラインの見直し

上記の情報をまとめる過程で、いくつかのガイドラインについて見直しを実施しました。

場合によっては、過去のチェック結果との整合性がなくなることも考えられますので、ガイドラインを活用してくださっている場合にはぜひご確認ください。

画像化されたテキストに関するガイドライン

まず、画像化されたテキストに関する以下のガイドラインを見直しました:

[MUST]画像化されたテキストを用いないと実現できない表現が不可欠な場合(例:ロゴ)を除いて、文字情報は画像化せず、テキスト・データで提供する。画像化されたテキストを用いる場合は、以下に示すコントラスト比に関する要件と、代替情報に関する要件を満たす。

その結果、このガイドラインは以下のように変更しました:

[SHOULD]画像化されたテキストを用いないと実現できない表現が不可欠な場合(例:ロゴ)を除いて、文字情報は画像化せず、テキスト・データで提供する。

これまでは、以下のいずれかを満たすと[MUST]の条件を満たしているということになりました:

  • 画像化されたテキストが使われていない
  • 使われている画像化されたテキストが、コントラスト比や代替情報に関するガイドラインを満たしている

できるだけ画像化されたテキストは使うべきではないという考えに基づいてこのようになっていました。

しかし、実際にコンテンツのアクセシビリティーに与える影響の大きさを考えると、この2つの条件を同等なものとするのは必ずしも適切ではないだろうと考えました。 WCAGでもこの2つの条件は異なる適合レベル(前者がAA、後者がA)となっているわけで、同等ではないという判断は妥当そうです。 ということで、ここは素直にWCAGに合わせることにしました。

この結果、これまで[SHOULD]の項目をすべて満たしているとされていたコンテンツであっても、もし画像化されたテキストが使われていれば[SHOULD]を満たさない状態であるという判断になってしまいますのでご注意ください。

動画の音声解説に関するガイドライン

これまで動画の音声解説に関するガイドラインとして、以下がありました:

[MUST]テキストの代替情報ではない音声・映像コンテンツにおいて、映像がある収録済みコンテンツの場合、映像の内容が分かるような同期した音声情報、またはテキストによる説明を提供する。

つまり、その動画以外に同等の情報を提供しているテキスト・コンテンツがない場合は、映像を見られない人にも理解できるように音声解説を付けることが求められています。

WCAGでは、これに加えて、同等のテキスト・コンテンツがある場合でも音声解説を付けることを適合レベルAAで求めていますが、freeeアクセシビリティー・ガイドラインにはこれに相当するガイドラインがありませんでした。

そこで今回、以下のガイドラインを新たに追加しました:

[SHOULD]すべての音声・映像コンテンツにおいて、映像がある収録済みコンテンツの場合、映像の内容が分かるような同期した音声情報を提供する。

動画コンテンツがある場合には、チェック結果に影響する可能性があります。

なお、参考情報の中でも触れていますが、元々動画に含まれている音声から、映像の内容を充分に推測できるような場合は、音声解説を追加する必要はありません。

ショートカット・キーに関するガイドラインの優先度の変更

ショートカット・キーに関するガイドラインについて、優先度をWCAG 2.1に合わせて[SHOULD]から[MUST]に変更しました:

ショートカット・キーを提供しているコンテンツにおいては、チェック結果に影響する場合があります。

引き続きご意見などお待ちしています

今回の変更についても、それ以外の部分についても、ご意見やお気付きの点など、GitHubリポジトリーのIssuesやPull Requestsでお知らせください。

2020年も開発合宿を開催しました

初めまして、2019年に新卒入社して、現在は会計 freee のワークフロー周りの開発をしているすぎけん(@sugiken_bike)です。

2020年10月下旬。開発合宿を開催しました。

晴海会場で人同士の距離をおいた集合写真
晴海会場

東品川会場で人同士の距離をおいた集合写真
東品川会場

有馬会場で全員マスクの集合写真
有馬会場

開発合宿は freee 開発陣にとって年に一度の一大イベントです。普段の業務から離れて、各々が自身の開発力で様々な課題に短期集中で取り組む freee 開発陣の自己表現の場と言っても過言ではありません。
2019年の開催の様子はこちらの記事 をご覧ください!

ご存知の通り、今年はコロナウイルスの脅威があるなかで人が集まる開発合宿を開催するというかなりチャレンジングな試みでした。 このコロナ禍で伝統を途絶えさせずに如何に開催をしたのか、その合宿の様子と運営の感想をご紹介します。

コロナ禍での freee 開発陣の働き方

freee ではコロナウイルスの広がりを受け、3月から全社的にリモートワークを開始しました。その後コロナ情勢も変化して、8月頃には部分的に出社が解禁されて、希望者はオフィスで働くのが許可されました。出社に事前申請などは必要なく、気分やたまに必要に駆られて出社している人が多いです。チームにもよりますが、リモートで働いている人が9割くらいですので、出社してもチームメンバーと必ずしも顔を合わせるとは限りません。

このように freee ではまだまだリモート中心で働いており、多くの人が一堂に会して働く Before コロナの働き方には戻っていません。

開発合宿開催を検討

まず開発合宿をやるのかやらないのかを話し合いました。企画開始は6月下旬で、この頃東京都では一日の新規感染者数が50人前後の時期でした。ここ最近よりかは低水準ですが、当時はこれでも十分脅威を感じていたのを覚えています。また他社の事例を参考にしても、やはり従来の合宿形式での開催はせずに、リモートで開催したという情報を耳にしました。

反面、いくつかのポジティブな外部要因もありました。

  • 政府が GoTo キャンペーンの企画を進めていた
  • 社内でも一部出社解禁の話が進み始めていた

コロナに対する根拠のない不安が徐々に払拭され、適切な予防方法(3密対策など)が分かってきていたため、感染の広がりを注視しながら、今年も開催する方針で決定しました。

みんな開発合宿に参加したいのか

開催する方針になった矢先の7月中旬頃、東京での新規感染者数が 200 人/日を超える日々が続きました。こういった状況は長くは続きませんでしたが、開催可能かが不安になると同時に、そもそも開催するとしても社員は参加してくれるのだろうかという疑問が浮かんできました。

そこで例年になく事前アンケートを取り、参加の意向を確認することとしました。その結果宿泊希望者は 40 人弱という結果に(例年は100人ほど)。これくらいの人数であれば十分に3密対策などを行った上で開催できると判断することができました。

リモートはニューノーマル

続いて考えたのが開催形式です。例年は宿泊組と、一部本社オフィスで働く組がいるという形式でした。あくまで宿泊組がメインのため、本社組へのケアはほとんど何もしていませんでした。

しかし、with コロナでは違います。リモートがニューノーマルとなった以上、開発合宿を宿泊組のためだけに開催するのは時代遅れです。

そこで開発合宿委員会ではリモート組にも開発合宿を味わってもらおうと開発合宿気分コースを設けることとしました。

リモート組のために考えたこと

リモートで参加するメンバーにも開発合宿を楽しんでもらおうと、委員会メンバーで考えたアイディアがこちらです!

  • 高い肉送ろう
  • 温泉の素送ろう
  • リフレッシュ手当支給
  • タンクローリーで温泉の湯を送ろう
  • オンラインハッカソンみたいにしよう

普段家では食べられないようなお肉や、リラックスできる温泉にでも浸かってくださいという開発合宿委員会からの気持ちでした。

開発合宿の意義とは

しかし、リモート組のためのアイディアを発散させていくうちに「開発合宿の意義ってなんだっけ」という根源的な疑問に至りました。

確かに、例年の開発合宿で宿泊地を決める際には、

  • 温泉がある
  • 非日常感
  • リフレッシュできる
  • 美味しい食事

など、楽しいイベント要素も選定基準に含めていました。

しかし、冒頭に書いたように開発合宿はあくまで、 各々が自身の開発力で様々な課題に短期集中で取り組む freee 開発陣の自己表現の場 です。
楽しめるコンテンツの提供もしたいですが、開発合宿委員会が提供するコンテンツが集中を阻害してはいけません。止む無くリモート組が自由に使えてリフレッシュできる「食事代の補助」という形に落ち着きました。

宿泊組とリモート組の垣根をなくす

すでに社内でも使われている、 Remo というバーチャルオフィスを活用しました。開発合宿初日と 2 日目の朝に全体朝会を開いたり、リモート組と宿泊組で共同でプロジェクトに取り組むチームが Remo を活用していました。また、リモート組が一緒にリモートランチをする場所としても提供しました。

しかし、Remo は想定したより使われませんでした。普段の在宅勤務でも感じているかもしれませんが、お互いの状況が分からない状態で他人をビデオ会議に誘うのは若干緊張するし、遠慮もしてしまいます。ましてや開発合宿はそれぞれが集中して作業しているため、突然話しかけて良いものか躊躇ってしまいます。そして、それを気にして Slack で連絡を済ませてしまいます。 Slack でチャットしただけでは垣根がなくなったとは感じられません。

もう少し垣根をなくすために、休憩時間を委員会で設定して積極的に雑談をしてもらうなど、作業にプラスとなるような施策を準備すればよかったかもしれません。

宿泊組の3密対策

安全第一。行った対策を箇条書きで紹介します。

  • マスクの着用必須
  • 開催地の分散(東京で2ヶ所 関西で1ヶ所)
  • 1人1部屋(例年は大部屋)
  • 人数に対して会議室を倍以上のキャパシティを確保

会議室のキャパシティ条件は社内の規定に従いました。とにかく大人数が狭い空間に集まらないようにしました。

これらの条件を満たし、予算内に収まるホテルを様々検討した結果以下の3箇所で開催しました。

広い会議室の様子 人同士の距離を取り、1長机に1人で作業しました。

個室の机の写真 当然個室での開発も可能です。

食事の様子 東品川ではレストランではなく、会議室で食事をとり、3密を回避しました。

コロナ禍での開発合宿を終えて

コロナ禍で合宿イベントを開催するのは未知な部分が多く、どういった対策を取れば安全に開催できるのか、メンバーが楽しめる開発合宿にできるのか、本当に悩むことが多かったです。 結果的に3密対策を実施してトラブルもなく無事開催できてホッとしています。

対してニューノーマルであるリモート組は開発合宿感があまり感じられないという課題が残りました。 集中を妨げずに、開発合宿感を楽しめて、アウトプットもしてもらう。正直この矛盾の解決策はまだ分かりません。来年の開発合宿委員会に期待です!

課題は残りましたが、コロナ禍の開発合宿でも例年以上のアウトプットが集まりました。開発陣の頑張りはこれからどんどんユーザーに届いていきます!お楽しみに!

freee Tech Nightをオンラインでも開催し続けた話

こんにちは。freeeでITストラテジーというチームでIT戦略的なサムシングに挑戦し始めたみり(Twitter)です。

今日は有志で開催しているfreee Tech Nightというイベントについてご紹介します。

freee-tech-night.connpass.com

freee Tech Nightとは

きっかけは、ある一人のエンジニアの呼びかけでした。

「freeeエンジニアによる、エンジニアのための技術イベントをしたい!有志求ム!」

その呼びかけに集まったメンバーで知恵を出し合い、始まったのがfreee Tech Nightです。

freeeのエンジニアや利用している技術を知ってもらいたい!いろんな知見を共有しあって高めあいたい!という想いを抱いて2018年12月14日に初めてのイベントを開催し、100名近くの方に参加していただきました。

スクリーンの前で9人の集合写真
運営メンバー集合写真

毎回テーマを決め、freeeのエンジニア数名にプレゼンをしてもらい、その後freeeのエンジニア達と参加者の皆様で懇親会をするという形で3ヶ月に1回のペースでイベントを続けていました。

イベント開催も5回となり、順調に開催を続けていたfreee Tech Nightでしたが、突然暗雲がたちこめました。COVID-19の感染拡大に伴って、freee全社で突然のリモートワークが始まったのです。それによって当時計画していた第6回のイベントは中止となり、今後について考える必要ができてしまったのです。 

ふりてくおんらいんの始まり

全社でのリモートワークが始まり、運営メンバーで集まった時にfreee Tech Nightをこれからどうするかが話し合われました。

存続にネガティブな意見も出る中、それでもfreeeのエンジニアのことを世の中に発信したいとう想いが強く、オンラインでの開催ができるのか方法を探りました。そして、オンライン配信とりあえずやってみよう!ということになり、freee Tech Night Online 通称 ふりてくおんらいん がスタートしたのです。

オフラインイベントとの相違点

オンラインでイベントを開催するにあたって、そもそものコンテンツの中身が見直されました。

コンテンツ

もともとのfreee Tech Nightの構成は、freeeのエンジニアのプレゼンと質疑応答30分×3のあと懇親会という、2時間近くのイベントでした。

スライドをガッツリみながらプレゼンを聴き続けるだけなのは、視聴者側からしても結構大変ではないかという懸念があったのです。

オンラインだからこそ気軽に参加できるものにできないかということで、テーマを決め、司会とそのテーマに精通するfreeeのエンジニア2名とトーク30分というものになりました。

こちらは記念すべきふりてくおんらいん第1回目です。

freee Tech Night Online #1「3月1日のfreee全社員一斉リモートワークの裏側」動画

やってみてわかったことは、

  • Google Meetで話しているだけなので、登壇者が社内の雰囲気のまま話せる
  • スライドの準備が不要なので、気軽に登壇できる
  • 運営側は配信の際に気をつけなくてはいけないことがいろいろある
  • それでもオフラインのイベントよりもオンラインのイベントの方が準備が楽
  • 配信自体は機材などの関係で属人化してしまう

ということでした。

開催頻度

オフラインイベントは3ヶ月に1度の開催ペースでしたが、ふりてくおんらいんは月1の開催を目標にしています。COVID-19によってよりクローズドになってしまった中でも、freeeのエンジニアがどんなふうに働いているのか、どんなことをやっているのかを知ってもらいたかったためです。あとは、オフラインイベントほど準備が大変じゃないため、社内のメンバーにも気軽に登壇を頼めるようになったことも回数を増やせるようになった要因の一つでした。

新たなる挑戦

オンラインイベントになったことで消えたコンテンツが、懇親会です。 5回のおんらいん開催を経て、やはり参加者と交流するのも大事だし続けたいという思いがあったため、オンライン懇親会やりたいとだだをこねてみました。笑 ということで、ふりてくおんらいん第6回では、ライブ配信後にZoomでオンライン懇親会をひらきました。 最初は参加してくれる人がいないのではと冷や冷やしましたが、飛び入り参加もあり、登壇者と懇親会参加者がゆるゆるとお互いの話をできて、とても良いコミュニケーションの場になりました。 参加してくださった方にも好評だったことと、オンラインイベントで懇親会を行っているところは少ないということで、これからも続けてみたいと思います。

これから

ということで、回を重ねるたびにいろいろな工夫を続けているfreee Tech Nightですが、始まってからそろそろ2周年をむかえます。 2周年記念の特別イベントができないかなぁと考えながら、これからも配信を続けていきますので、みなさまどうぞチャンネル登録よろしくお願いします!

www.youtube.com

freeeアクセシビリティー・ガイドラインVer. 202010.0を公開しました

こんにちは、freeeのアクセシビリティーおじさん、中根です。某大手通販サイトを名乗る何者かから、そこに登録してあるのとは違う電話番号に「アカウント違反を検出しました」なるSMSが届いた今日この頃、皆さんもどうぞご注意ください。

さて、今回もfreeeアクセシビリティー・ガイドラインの更新情報をお届けします。 なお、本稿で触れていない変更もありますので、リリース・ノートも合わせてご覧ください。

そのチェックってどうやるの?に答えるべく

各ガイドラインを満たしているかどうかを確認するために示している「チェック内容」について、具体的にどのようにチェックを自死すれば良いのか分かりづらいという声が社内でありました。 たしかに、何らかのチェック・ツールやスクリーン・リーダーを使った経験が豊富な人ならともかく、「それってどうやってチェックするの?」という疑問を感じるチェック内容は少なくないように思います。

そこで、10月27日に公開したfreeeアクセシビリティー・ガイドラインVer. 202010.0では、いくつかのチェック内容について、NVDAやaxeを使ってどのようにチェックすれば良いのかという情報を追加しました。

axeって?

NVDAは、freeeのアクセシビリティー・チェックで標準環境としているスクリーン・リーダーで、既にスクリーン・リーダーを用いたチェックの実施方法という参考情報で紹介していますのでご存じの方も多いと思います。

一方axeについてはこれまで触れたことがなかったと思いますが、こちらは世界的にも広く使われているアクセシビリティーのチェック・ツールです。

今回の更新では、まずこのaxeのインストール方法や使い方を紹介する参考情報を追加しました:

具体的なチェック方法を例として紹介

さて、話を戻してチェックの方法についてです。

例えば、テキスト・カテゴリーの以下のガイドライン:

[SHOULD]段落単位など、比較的長いテキストの言語がhtml要素のlang属性で指定したものと異なる場合は、その部分に対して適切にlang属性を指定する。

のチェック内容として、チェックID 0921は以下のようになっています:

複数の言語が含まれているテキストについて、多言語対応している読み上げ環境を用いて読み上げさせたとき、適切な言語の音声エンジンで読み上げられる。

NVDAを用いてこのチェックを実施する方法の例として、以下を示しています:

  1. NVDAの音声設定で、「サポートされている場合自動的に言語を切り替える」と「サポートされている場合自動的に方言を切り替える」がチェックされている状態にする。
  2. ブラウズ・モードで上下矢印キーを用いて読み上げさせたとき、使用されている言語に応じて読み上げに用いられる音声が切り替わることを確認する。

まだ数は少ないですが、このようなチェック実施方法の例を、以下のページにまとめました:

そしてチェック・リストにも、同じ内容を掲載しています。

今後、チェック方法について分かりづらいという指摘があったものについては、随時これらのページに掲載していく予定です。

なお、上記のページに示したのは、タイトルにもあるようにあくまでも「例」です。 ですから、ここにある方法でなければチェックができないというわけでもありませんし、このようにすれば100パーセントチェックができるというわけでもありませんので、その点にはご注意ください。

ご注意 URLの変更について

このチェック実施方法の例を追加するに当たって、ファイル構成などを一部見直した結果、全チェック内容を掲載しているチェック・リストのURLを変えることになってしまいました。 もしリンクやブックマークなどしてくださっている方がいらっしゃいましたらご注意ください。

旧URL: https://a11y-guidelines.freee.co.jp/checks/index.html
新URL: https://a11y-guidelines.freee.co.jp/checks/checklist.html

参考情報を少し加筆

今回、いくつかの参考情報に加筆しています。 特に以下の2件については、コードのサンプルを追加してみました:

実はこれまで、コードのサンプルの掲載は以下のような理由でなるべく避けてきました。

  1. ページ中にコードを表示すると見通しが悪くなって読みづらくなりそう
  2. 読んですぐ試せるようにする方法をどうしよう(考えるのが面倒だった)
  3. コードをダウンロードできるようにしたいけど、ダウンロード用のコードとページ掲載用のコードの二重の管理が発生するのは嫌だ(いつか必ず一方だけを更新するという事故を起こす自信がある)

この中でも、特に3が一番大きな問題でした。 もちろん、ダウンロード用に用意したファイルをreStructuredTextのincludeディレクティブで読み込んでやれば、二重管理の問題は解消できるのですが、説明の中で使うために必ずしもそのファイル全体を掲載したいわけではないこともあるでしょうから、この方法は使えないだろうと思っていました。 (上記2件では、コードがあまり長くないのと、内容的に全体が必要なので、ファイル全体を掲載していますが。)

ところが、今回チェック実施方法の例の管理をいかに効率的にできるようにするかということを考える過程で、改めてreStructuredTextのincludeディレクティブについて調べてみたところ、僕が知らなかっただけで実はファイルを部分的にincludeしたり、includeしたファイルの内容に行番号を付けて表示したりする機能があったことが分かりました。 早速チェック実施方法の例からチェック・リストの内容を引用したり、チェック・リストにチェック実施方法の例を埋め込んだりするために使ってみたところ、これが思いの外うまくいきました。

ということで、このincludeディレクティブを大いに活用しつつ、HTMLファイルの生成時だけiframe要素を追加してそのサンプルを表示するようにしてみました。

今後は、コードがあった方が分かりやすいものについては積極的にコードを掲載していくことができそうです。

引き続きご意見などお待ちしています

今回の変更についても、それ以外の部分についても、ご意見やお気付きの点など、GitHubリポジトリーのIssuesやPull Requestsでお知らせください。