2023.03.08@高まるウェブアクセシビリティの需要ーfreee×ニューズピックスー〜フロントエンド最前線〜

NewsPicks での事例紹介
Web Frontend Engineer@NewsPicks / イイダユカコ
2023.03.08@高まるウェブアクセシビリティの需要ー
freee×ニューズピックスー〜フロントエンド最前線〜

01 自己紹介
©NewsPicks Inc. All Rights Reserved.
イイダユカコ
NewsPicks Web エンジニア
経歴
2013年に株式会社サイバーエージェントに入社し、サーバサイドエンジニアを
経て、2015年よりフロントエンドエンジニアとして従事。 2019年9月より株式会
社ニューズピックスにて、 Web フロントエンドをメインに担当。現在はニューズ
ピックスの Web プロダクトに関するリアーキテクチャプロジェクトとリニューアル
プロジェクトに携わる。
推進する中で Observability や Accessibility などの普及を図っています。

02 NewsPicks の紹介
プラットフォーム
日本・世界の
重要な経済ニュースを
ワンストップで提供
メディア
NewsPicks オリジナルコンテ
ンツ（記事・動画）で経済がわ
かる
NewsPicksは、ソーシャル経済メディアとして、
プラットフォーム・メディア・コミュニティが融合した、
新しいメディア体験を提供しています。
コミュニティ
専門家や当事者のコメント・発
信でニュースを
多角的に理解
newspicks.com
経済を、もっとおもしろく。

01
事例紹介
（当日の前半5分で紹介した内容です）

● NewsPicks（サービス）は2013年9月よりサービス提供を開始、 2014年6月より Web サービスの提供を開始
● 2021年7月より、Web Product を現行基盤から新基盤へ page 毎に移行開始（リアーキテクチャ Project）
○ 使用技術: Next.js (React) / TypeScript / GraphQL
● 2022年より、並行してデザイン刷新も推進（リニューアル Project）
● 基盤やユーザー体験を整えていく上で重要視しているのは、 ”Web Product の品質の底上げ ”
○ “品質” を構成する一つの要素に a11y の観点も取り入れている
■ 例: チーム OKR に Lighthouse のスコアを設定する
■ 例: NewsPicks におけるアクセシビリティガイドラインを作成する
02 Web Product の現在地を共有
【補足】現在の Web Reader Experiencr Unit のチーム構成
● Web フロントエンド担当 : 3名（新メンバーが入り、後半には 4名になる予定）
● サーバー担当 : 1名
● Embedded SRE 担当: 1名＋インターン生 1名
● デザイナー: Web 担当者が1名＋インターン生 1名＋兼務が 1名

> 2022年より、並行して page 毎のデザイン刷新も推進（リニューアル Project）
03
● 正直なところ、現行基盤はアクセシブルでない部分が多い状態
○ UI 的な問題や実装的な問題を多く含む
● リニューアル project 進行中の状態
○ デザイン時: 対象のデザインレビュー時にエンジニアから FB（フィードバック）
○ 実装時: PR 上でお互いの知識を元にチェックしレビュー時にコメントとして記入
○ 自動テスト: 全ての新基盤 component に対して jest-axe を用いて PR 毎にテスト
● リニューアル project をきっかけに新しいデザイン仕様が増え、デザイナー陣からの提案で design system project が始動
● 成果物がより安定的に、よりアクセシブルである状態にしたいという狙いから、
エンジニア側からアクセシビリティガイドライン project が始動
アクセシビリティガイドライン project 始動のきっかけ

大目的は、「成果物がより安定的に、よりアクセシブルである状態」にすべく、
● 誰でもチェックできて、誰でもアクセスブルにデザイン /実装できる a11y 項目のチェックリストの形式になっている
○ デザイン時に組み込めるようにチェックできる
● 成果物に対してどの程度アクセスブルかのチェックが可能になっている
○ どの component でどのルールが適用されているのか理解できる
○ 任意のページでの達成率はどうなっているか理解できる
○ 改善できるポイントがどこにあるか理解できる
を達成すること
04 ガイドラインの大目的

WCAG のセクション番号ベースではなく、ルールベースのチェック項目を管理
以下の4種類のページを Notion を使って管理し、ガイドラインとする
05 具体的なガイドライン構成
チェック項目一覧ページ毎にまとめた
チェック項目一覧
component 毎にまとめた
ルール個別解説
● 一行につき全角40文字以上にならないようにする
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
✔
✔
✔
✔
✗
✔
達成度: XX %
記事 page
( newspicls.com/XX )
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
● XXXXXXXXX
✔
✔
✔
✔
✗
✔
達成度: XX %
記事カード component
概要
…
具体例
…
テスト・チェック方法
…
実装方法
…
参考リンク
…
一行につき全角 40文字以上
にならないようにする

ルールの定義を Notion database を用いて管理する
06 具体的なガイドライン構成
カテゴリチェック項目適合レベルチェックフェーズ WCAG2.1
セクション番号
対象となる
component
対象となる
page
フォーム
画像
自動テスト
A
XX になってない
XX ができるデザイン仕様ﬁx時
A
1.3.1 1.3.4 comA comB pageA
pageB
comB
Notion database の共通項目（props）を用いて table を ﬁlter し、
各ガイドラインのページ趣旨に応じて参照できるようにする
1.3.1
＊メンテナンス性を向上させたいという思いから、このような使い方にしました！作って終わらない、コスト低く持続可能なメンテナンス性って大事！

理想現実
a11y ガイドラインに設定しているものが実装に全て反映され
ている
ガイドライン作成中につき、まだまだ実装反映できてない
箇所も多い。自動テストや担当者が気づいたものは反映
できている状態。
a11y コミュニティを作れていて、グループ会社を巻き込んで互
いに相談できている
Slack チャンネル #y-a11y は存在しつつ、ほぼ固定メン
バーの不定期発信場となっている
支援技術利用者によるテストを定期的に行いたいリリース前テスト時に実装者が気づいた部分を確認する程
度しかできていない
a11y ガイドラインを公開し、 a11y 分野に貢献できている状態まだまだ社内限定公開のステータス
07 弊チームでの a11y 活動の理想と現実
正直、まだまだ「理想」まで長い道のりが待っている印象 😇

02
パネルディスカッション
（当日のメインでお話した内容です）

プロダクトにウェブアクセシビリティを取り入
れるためにやったこと

01 プロダクトにウェブアクセシビリティを取り入れるためにやったこと
1-1. 参考にしているプロダクトは？
WCAG を直接見ることもありますが、どういった解釈
をしているか知りたいときは、実際のプロダクトに対し
て作成されたガイドラインを参照することが多いで
す。
実装としてどうアウトプットされたかを知りたい際は、
同じくメディア事業をされている note さんの実装や、
UI library である MUI（Material UI）や Chakra UI
を参考にしています。
ガイドライン
実装

01 プロダクトにウェブアクセシビリティを取り入れるためにやったこと
「何をやってるかわからない」を
徹底的に排除する
1-2. 苦労したこと/工夫したことは？
実際のプロダクト開発に繋がる
ガイドライン作成する
● デザイナー陣と寄り添う形で構成を考える
○ どうやったら使えそうと思うかについて、作成初
期段階からヒアリングさせてもらう
● 仕様策定フローへの取り入れやすさを考慮する
○ 取り入れるイメージを持ってもらえるようにどん
な形が理想化をすり合わせて進行
● Unit、division 、同グループのフロントエンドメンバーに
「意図」や「アウトプット」を共有できる形で進行する
● 「よくわからない」はやはり敬遠されがち
…細かいことも、
多少まとまってなくても、とりあえず出すようにする
苦労はこれからするんだと思っています！気合い入れてくぞ！

明日から始める
ウェブアクセシビリティへの一歩

1人の場合
● build 待ちの間に本番環境のdev tools で
Lighthouse 動かしてみる
組織単位の場合
● 取り入れた情報を会社のSlack の times（分報）や
tech 系チャンネルに投下してみる
チームの場合
● component 実装に対してjest-axe 等自動テストツー
ルを導入
● テストの習慣化（GitHub Actions 等で毎 PR テストする
ようにする等）
2-1. 何から始めるのがベストか？
02 明日から始めるウェブアクセシビリティへの一歩

02 明日から始めるウェブアクセシビリティへの一歩
ガイドライン作成の進行と理想状態の仕様と
実装反映
「Web だけの挑戦/課題でない」という認識を
もっと広めたい
● 社内 a11y チャンネルにWeb フロントエンド勢以外の
メンバーも invite していきたい
○ iOS/Android 開発者、デザイナー、
PdM の方々
○ ありがたいことに、デザイナーメンバーやd&I 文脈で
興味を持ってくださってる方は社内に多いイメージな
ので、うまく巻き込みたい！
● ガイドライン輪読会の実施
2-2. 現在抱えている課題と、今後どのように進めていくのか？
● 今の project 的に、既存実装→ガイドライン→実装反映と
なっているが、理想的には、ガイドライン
→仕様落とし込み
→実装
● 理想のフローに追いつくよう、今はひたすらガイドライン化
と実装を進める形になっている

a11y 草の根運動
まだまだやっていくぞ！

03
質疑応答
（当日の後半でお話した内容です）

03 質疑応答
？前述した通り、NewsPicks の Web product では、GitHub
Actions を用いて、PR 毎に jest-axe のテストが走るようにして
います。
axe のテストが万能であるというわけではないのですが、自動テ
ストで気付くことのできる最低限のところをカバーするには良い
と思い、導入しています。
アクセシビリティ検証ツールの最新事情や、使い分け方。特に、
Google/Chromeでも採用されているDeque社のaxeの業界
内でのポジショニグ

03 質疑応答
？
プロダクト開発において KPI目標上で優先したい動線の UIと、ア
クセシビリティの観点で優先したい UIがあった場合、どのように
折り合いをつけますか？
多様なパターンがあると思うのですが、個人の経験上では、ア
クセシビリティ文脈で実装が難しい場合、そもそもの仕様が複雑
だったり、ユーザーが意図していない操作感になっていることが
多かったです。それ故、「アクセシビリティ的に実現が難しい」と
思う場合は、今一度仕様が複雑化していないか立ち返る機会だ
と考えるようにしています。もちろん全てにおいて言えることでは
ないのですが、一度メンバー全員で向き合ってみてもいいかもし
れないです。

03 質疑応答
？テックイベントのLPページ等でアクセシブルでない実装を見ると
「このイベント大丈夫かな」と来場者に思われないかやや不安に
なることがあります。そういった上で「アクセシブルな実装ができ
る受託開発を提供しています」というのは強みになると感じてい
ます！納品時にアクセシビリティ観点の検品書が入っていたり
するととてもかっこいいと感じました！応援しています！
受託開発側から「アクセシビリティやっておきますね！」と伝える
べきでしょうか？

04
おまけ

04 おまけ: 宣伝
テック情報、アウトプット中！是非お立ち寄りください！
会社紹介資料やエンジニアブログを公開中！
https://tech.newspicks.com/
デザイン系については note をチェックしてください 💁
https://note.com/newspicksdesign/
Podcast もしているので、よろしければご視聴ください 📻（出演
もお待ちしております 🙋）
カジュアル面談希望＆ Podcast 出演希望の方は
Twitter より @becyn に DM ください！

2023.03.08@高まるウェブアクセシビリティの需要ーfreee×ニューズピックスー〜フロントエンド最前線〜

More Related Content

Similar to 2023.03.08@高まるウェブアクセシビリティの需要ーfreee×ニューズピックスー〜フロントエンド最前線〜

2023.03.08@高まるウェブアクセシビリティの需要ーfreee×ニューズピックスー〜フロントエンド最前線〜