伊原さんと話すアクセシビリティ 前編 アクセシビリティへのエンジニアの立場と現実

freee株式会社の伊原 力也さんをゲストにお迎えした、アクセシビリティをめぐる座談会の様子をお伝えします。今回は、アクセシビリティに対するエンジニアの立場や、実際にアクセシビリティ案件がどのような状況なのか、考えてみます。

発行

  • 中村 享介
  • 外村 奈津子
  • 坂巻 翔大郎
  • 矢倉 眞隆
伊原さんと話すアクセシビリティ シリーズの記事一覧

はじめに

今回の座談会は、アクセシビリティに造詣が深く、多くの講演会やカンファレンスで登壇されている、freee株式会社の伊原 力也さんをお迎えしました。

座談会のそもそものきっかけは、伊原さんがTwitterで「よく、"それだけ言うことがあるなら、ブログを書け"と言われている」と発言されていたことです。ピクセルグリッドのスタッフは、伊原さんがどんなことを言いたいのか、どんな思いをお持ちなのか、ぜひCodeGridでお話いただきたいと思い、座談会が実現しました。

現在のWeb業界のアクセシビリティとエンジニアの状況、アクセシビリティ対応を訴求することについて、そしてアクセシビリティとユーザーについてなど、伊原さんとピクセルグリッドのスタッフが、かなり突っ込んでお話しました。その様子を、3回に分けてお届けします。

参加者は以下になります。

  • 伊原 力也 氏(freee株式会社:UXデザイナー)
  • 中村 享介(株式会社ピクセルグリッド:代表取締役/フロントエンド・エンジニア)
  • 坂巻 翔大郎(株式会社ピクセルグリッド:フロントエンド・エンジニア)
  • 矢倉 眞隆(株式会社ピクセルグリッド:フロントエンド・エンジニア)

進行は、ピクセルグリッドの編集、外村 奈津子が担当しました。それでは、どうぞお楽しみください。

アクセシビリティを手がける人が少ない理由

——今日はご参加ありがとうございます。今回の座談会は、伊原さんのツイートから、「どんなことをお話したいのだろう?」と思ってお声がけしたらご快諾いただいて実現しました。ありがとうございます。

伊原:僕はアクセシビリティの話ばっかりTwitterに書いているので、そんなに書くことがあるんだったら、ブログにまとめて書けば? っていう話になりやすいんです。でも、ブログを書こうとすると急にハードルが上がるんですよ。マサカリが飛んできてもちゃんと返せるように、適当なこと書いちゃいけないし(笑)。

アクセシビリティのことを突っ込んで考えている人があんまり多くないからブログ記事にしてみたら?ってことなのかもしれないけれど。

——アクセシビリティのことを考えている人が少ない?

伊原:アクセシビリティをやらなきゃいけないなと思って、勉強したいっていう人はだいぶ増えたなって印象はあるんですけど、そこから先はどうしたらいいのかわからないと言っている人が多いっていう状況には、ずっと興味がありますね。

——ああ、アクセシビリティ案件を手がけたいと思っている人は増えたけれど、実際に案件をやりました!ってところまでは行ってないということですね。

矢倉:どうしたらいいのかな。

伊原:『デザイニングWebアクセシビリティ』(ボーンデジタル)っていう本を出版したんですが、あの本を書いた動機は、「この案件でアクセシビリティを確保したいんですけど、どうしたらいいですか? ガイドライン読んでもまったくわかりません。むしろ読めません」と頻繁に質問されたのがきっかけなんです。それに答えるために何回も何回も同じことを答えているので、それを書籍にまとめようと思ったわけです。で、太田さん*と一緒に書かせてもらいました。

*注:太田さん

お話の中に出てきた「太田さん」とは、弁護士ドットコムに所属しているアクセシビリティエンジニアの太田 良典 氏のことです。ウェブアクセシビリティ基盤委員会(WAIC)の委員としても活動し、CodeGridにも寄稿いただいています。

ガイドラインを読む前に、まずあの書籍を読んで、アクセシビリティがわかるようになるという点では一定の成果があったと思います。

実際にアクセシビリティに取り組む人も僕の観測範囲の限りでは増えてきたと思います。それは自分よりも若い世代にも増えてきているし、新卒の人でも読みましたっていう人も増えてきています。

あの書籍が出る以前の状況だと、アクセシビリティっていうと、大企業のウェブ担当者とか、SIで公共団体系の案件を頑張っている人たちが取り組んでいるものという印象があったんです。でも書籍を出版していろいろなところで登壇していると、だんだんプレイヤーが変わってきたなと思っています。

矢倉:ああ、コードを実際に書く人の意識が変わってきたんですね。

伊原:そうそう。自分の体感的には増えたかな、って思っています。あの書籍を読むじゃないですか。すると「自分も頑張ってやろう!」って思ってもらえる。そこまでは良かった。でも、その結果が「やらせてもらえない」っていうふうになるみたいなんです。

矢倉:やろうとするとそうなるよね。

伊原:そう、やろうとすると「そういうのは、いいから」って言われるんです。

中村:あるある話ですね。そんな細かいことはいいから、早くつくってくれとかね。

矢倉:あとは、制作のうえでアクセシビリティ確保のことを考えはじめないといけない段階があるんですが、それがすでに過ぎていると、限界が見えてきたりします。

フロントエンド・エンジニアの憂鬱

伊原:そう。いちばんアクセシビリティに興味を持つ人って、ダントツにフロントエンドを担当している人なんですよ。マークアップをしているから。典型的なアクセシビリティ確保の例って、マークアップをきちんとすると、スクリーンリーダーが読むってことじゃないですか。

なので、そこを頑張りたいって思うけれど、「altは俺が書くのか?」っていう疑問が出てくる(笑)。「原稿書いてくれる人はalt書いてくれないのか?」という気持ちになる。そして、このデザインを実装して、コンテンツがきちんと読み上げられるようにするのは無理だという状況になったりします。

その次の段階として「それならば、デザイナーやディレクターと一緒にやろう!」と思うわけです。心あるデザイナーやディレクターだったら「じゃあ、できる案件でやってみようか」って思ってくれます。ただ、これが人によっては超えにくい、第一の壁なんです。

——なんだか、ゲームみたいですね。

矢倉:心ないやつらばっかりですからね(笑)。

伊原:そう。一人で頑張ってて、この後どうしたらいいんでしょう? っていう、このパターンがまず多いんです。

矢倉:新しい何かをやるときのパターン。

伊原:うん、アクセシビリティの代わりに、UXでも、ユーザビリティでも、ライティングでもどんな言葉でもいいと思うんだけど、新しい何かをやるときの現象ですよね。自分だけのパートではどうにもできなくて、他の人と一緒にやらないと無理ってなる。しかし、意義をわかってもらうのが難しい。

でも、そういうことに気づく人っていうのは、だいたい現場で直接触れている人が先になるから、技術職の人が多いんですよね。そうすると、社内で味方をつけるという……。

——政治力(笑)?

矢倉:コミュニケーション力、かな(笑)。

伊原:そう、そういった力を使っていく必要がある。でないと、営業とかマーケティングにはアクセシビリティに詳しくない人が多いから、アクセシビリティを頑張りたい技術職の人は悶々とした日々を過ごすことになりがちですよね。ただ、このあたりまで行ける人は増えてきたかな。

受託案件のアクセシビリティ要件

矢倉:さっき、伊原さんが言っていたようなアクセシビリティに興味を持っている人って、受託会社の人が多いのかな。

受託案件になってしまうと、ステークホルダーが近くにいないですよね。たとえば、アクセシビリティ要件として、コントラスト比が足りないから、それを修正しようと思っても、そのままだとブランディングガイドラインに抵触する場合、コミュニケーションが取りにくい。

一方で、自社サービスの場合は、プロダクトラインにのるまでが近いから、比較的やりやすいのかなという気もしますね。まあ、会社によっても違うかと思います。かなりサイト制作の上流から関わるようなBA(ビジネス・アーキテクツ)とかコンセントのような企業は、受託案件でもクライアントと一緒にできるかもしれないですけど。

伊原:現状として、ウェブ制作は受託メインの会社が請け負っている場合が多い。事業会社の中で自社でサイトを内製できる体制を持っている企業はそこまで多くないと思います。サイト制作だけが直接の収入源じゃなかったりもするので。そうすると、いきおい社外に頼んでいるケースが多い。なのでウェブをつくっている人の多くは受託なわけです。

それで、矢倉くんがいうように、ほとんどの会社はRFP(提案依頼書)要件にアクセシビリティ要件とかは入れないので、頼まれないんですよね。

頼まれないからやらないっていう非常にシンプルな理由なんです(笑)。「頼まれないから、やらない」、「やらないから、やれない」、「やれないけれど、やりたい」。

アクセシビリティが重要だと言っている多くは技術者なので、他の職種の人を巻き込むとなると、結局、その会社のサービスメニューとして、アクセシビリティを入れるかどうかっていう問題になるんです。でも、先ほど言ったように、クライアントから頼まれないんだとしたら、それをメニューにするの? って話になっちゃうんです。

経営者がドライに見れば、やる価値のないことってなっちゃいますよね。そういう会社に所属していれば、アクセシビリティ案件に関わることはない、という完璧なラインができあがっている(笑)。

——ニーズはないんでしょうか。

伊原:いや、頼まれる案件だって当然あるし、アクセシビリティを確保できるってことが、高品質っていうことを主張するための武器にもなると思うんです。アクセシビリティで取れる市場っていうのはある。

でも、発注側や、経営者の大多数の人はアクセシビリティっていう概念自体を知らなかったりするので、それを武器にしようとは思えないですよね。自分から武器にしようと動く人はそう多くはない。

会社の評価基準にアクセシビリティ関連技術を設ける

「アクセシビリティを頑張りたい技術職の人は悶々としてしまう」と話しましたが、アクセシビリティに対する知見を評価基準にしている会社もあります。たとえば、サイバーエージェントはエンジニアの評価基準にアクセシビリティに対する知見がある、実装例があるというのを入れているそうです。エンジニアとして、ある一定以上のレベルを目指すなら、標準技術の知見のひとつとして、アクセシビリティもわかっていないといけないというアプローチにしてますね。

サイバーエージェントは、プロダクトごとにガイドラインを作り、公開もしています。そういう場作りができているのがすごいと思います。(伊原さん、談)

※2017年の資料ですが、同社のメディア事業での取り組みの概略がわかります。

やりたいからやる人と、やりたくてもできない人

矢倉:エンジニアはアクセシビリティをやりたいから、自社サービス系の会社に行く人もいると思う。技術的に自分がある程度、裁量を持てるようなところ。

——できない会社から自分が出て、できる会社へ行くってことです?

矢倉:そう。そういうのが多少最近の人の動きにはあるのかなって思ってます。一方で、受託コンプレックスも感じます。「君らは自分のところのサービスがあるからいいよねー」みたいな。

全員:(笑)

矢倉:去年だったかな、noteに「フロントエンドエンジニアから、デザイナーさんに意識してほしい10のこと」っていうけっこう具体的な要望が書いてある文章が載ったんですけど、その文章に対する反応がいろいろあって、2つの傾向があったような気がします。

「そういうのを実現するにはプロダクトの初期段階でフィードバックを細かくしていけばいい」っていう意見と、そのnoteに書かれていた要望に同調するというか、「そういうので困っているっていうのはわかるよ」っていう同情があったんです。

前者は自社サービスをやっている人とか、上流での設計をやっている人が多いんですよ。僕は受託の会社にいることや、デザイナーではないっていうことと、イケてないデザインを数多く目にしてはきているから、どちらかというと後者の反応なんです。おそらくこのnoteを書いた人も受託をやっているのかなと推測しました。ご本人はそのあたりは明らかにしてないですけど。

伊原:僕も受託の方かなって思った。

矢倉:その反応の違いを見てて感じたのは、アクセシビリティを頑張りたいと思っている人の中にも「やりたくて、できる層」と「やりたくても、できない層」が生まれてしまっていないのかなという不安です。

伊原:ディレクターやデザイナーから「渡され」がちなんだよね、受託は。「ここまでやったから、あと組んでね」って。そうやって渡されたのを見て、これじゃできないよってなって、さっきnoteの記事になると思うんです。アクセシビリティも同じで、ある程度まで進んじゃったものが渡されて、そこから「どうする?」っていうふうになっちゃうんです。つまり、渡されたときにはもう勝負は決まっている。

矢倉:それはかなり多いね。

伊原:そう。実装段階でできることってあんまり残ってないんですよね。でも、その手前まではアクセシビリティをよくわかってない人が作っていることも多くて。これが自社サービスだと、頼んでくる人と頼まれる人は同じ組織なんです。

僕自身はfreeeのプロダクトマネージャーであり、UXデザイナーなので、アクセシビリティを推進することに対しての異議はあまりないんです。やれることをやりましょうっていうのは一気通貫でできるんですよね。

受託になると、まずお客さんの中で「頼む/頼まない」があって、頼まれたとしてもそれが「できる/できない」、さらに「やる/やらない」がある。制作工程の最終工程の人がどうにかしなきゃいけないって思っていても、「頼まない/できない/やらない」になったときに、最終工程の人ができるわけない(笑)。

じゃあ、できる現場に行こうって言っても、ウェブアクセシビリティを推進していきますって言っている事業会社は、日本では、数社しかないんです。知っている限りで10社くらいしかないんじゃないかな。

アクセシビリティ案件はちゃんと存在する

中村:どうしたらいいんでしょうね。

伊原:たとえば「自治体案件」では、アクセシビリティ要件の実現を求められるんですよ。

矢倉:そう、達成基準がAA(ダブルエー)なんです。実は、覚悟が必要だからな、っていうくらいのレベルを求められる。

伊原:「みんなの公共サイト運用ガイドライン」というのがあるんですが、これが達成基準AAを求めている。で、どの公共団体がどの程度取り組んでいるかが今年の3月に調査結果として公開されているんですよね。だから、アクセシビリティ施策をやってないっていうのはわかってしまいます。また、その根拠となる障害者差別解消法(障害を理由とする差別の解消の推進に関する法律)もすでに施行されているので、もうアクセシビリティ対応をやらなければならない状況にはなっています。

WCAG達成基準

お話中に出てきた「AA」は、Web Content Accessibility Guidelines (WCAG) 2.0(日本語訳)における達成基準を表すものです。A(シングルエー)、AA(ダブルエー)、AAA(トリプルエー)とありますが、どのように達成基準が考えられているかは、同ガイドラインを次の箇所を参照してください。

なお、WCAGの仕様書のソースを見てみると、仕様策定者が達成基準をどのように考えているか読み解くことができるかもしれません。

スクリーンショット:WCAG 2.0ガイドラインのHTML抜粋

ガイドラインの説明文(.guideline)の下にある、レベルAの説明文は.req(=require、必須)、レベルAAの説明文は.bp(=best practice、ベストプラクティス)レベルAAAの説明文は.additional(=additional、付加的)で、それぞれ囲まれているのがわかります。

伊原:自治体案件では、アクセシビリティは必ずRFPには必ず入っているし、入札サーチとかをみると、アクセシビリティ案件をちょっと検索しても200件はあるんです。ただ、「おいしい仕事なのか」という問題はあります。そもそも自治体案件って、かなり覚悟がないと取れないんですよね。

——それは安いってことですか?

伊原:そうです。安い、そして、最初に予算金額が固定されてます。基本的には「逃げ出したい案件」です(笑)。制作する前にスコープを決めて、決して金額は変更できないんです。ピクセルグリッドさん、受けないでしょう(笑)?

矢倉:ビジネス的なことはもちろんあるけど、僕らの会社の規模は小さいからそういう案件を受けられるだけの体制がない。

中村:うん、今のところ、それ以外の仕事でリソースが埋まってしまっていますからね。

伊原:そう。だから、体力があって、場合によっては儲からないかもしれない案件があったとしても、他の案件で収支の辻褄が合わせられるようなところじゃないと、自治体系の案件は取れない。そうなると、大手の制作会社か、自治体案件を専門にやっている企業しか取れなくなってしまう。案件数は多いけれど、取れる企業が少ない。

——仕事がないわけではないということですね。

伊原:アクセシビリティ案件がない、というのは嘘ですね。

民間でも公共色が強い、学校とか、病院とか、グローバル企業は、やらないといけない理由はあるし、やったほうがユーザーが増えるとは言えるとは思うんですね。クライアントが気づいていなくても、こちらから提案すれば、「やったほうがいいね」となるケースはあると思います。

中村:「やろう」ってなるのは、バプリックな性格を持っているという自覚からなるのか、それとも晒されるからやらなくちゃなのか、どっちかなあって思っていて、やらない業界があったら、そこから探していったらいいんじゃないかと思ったりします。

伊原:自分の横(同業者)を見て、やっているところが多ければ、うちもやらなくちゃってことにはなりますよね。民間だと、銀行とか、通信会社はやります。たとえば、ソフトバンクとか、NTTドコモとか。

航空系だと、アメリカにはACAA*っていう法律があって、アメリカに離発着する航空会社はすべてアクセシビリティを確保してくださいということになっているので、日本の航空会社は対応する必要があります。

*注:ACAA

日本語訳は「米国航空アクセス法」です。ここではANAの取り組みページを紹介します。

伊原:日本の民間企業では、障害者差別解消法において、「合理的配慮」が努力義務になっています。負担が重すぎない範囲で対応に努めてください、というのが「努力義務」なんです。これは、やらなくてもいいじゃんって言っているのと同じじゃないか、という話もあるのですが。

矢倉:目を向けるのにも体力が必要だしね。それに見合う成果、報酬というか。「社会的な意義がある」だけだと動きづらいかな。

ガイドラインの最低限は案外難しい

——頼むほうも困っちゃいますよね。受けてくれる会社が大手ばかりだと予算がないってことにもなりそう。「街のアクセシビリティ屋さん」じゃないけど(笑)、中小企業も頼めるようなところがあるとうれしい。最低限のアクセシビリティを確保してくれるような……

矢倉:「最低限」っていうのがちょっと難しいんですよね。たとえば、達成基準のA(シングルエー)を「最低限」って言われると、それはそれでだいぶつらいんですよね。

伊原:あれは、だいぶきついよね。Aは、Aじゃないよ(笑)。

中村:Aを達成していたら、けっこう頑張ったよねっていうレベルですよ。Aっていうと、基本みたいに思えるかもしれないけど、だいぶ達成するのが大変です。普通の人がイメージする基本のアクセシビリティのラインがあるとすると、そのはるか上にAがあります。

伊原:かなり上です。これからfreeeでもAを目指しますけど、かなり頑張らないとな、って気持ちです。

中村:僕らも普段サイトをつくるときに「さあ、目指すかな」っていう山の頂上にAがある(笑)。

伊原:Aはだいぶ厳しいし、じゃあ、その下の程度は? っていったら、明文化されているものがないんです。それはつくったほうがいいなって思ってます。

絆創膏じゃダメだから、アクセシビリティ、こわい

——うーん、それは大変。

矢倉:ガイドラインっていうけど、それが心理的なハードルになっちゃうところはありますよね。でも、情報が何もないよりはPDFでもあったほうがいいし、絆創膏みたいにちょっとずつでもいいと思うんですよ。

——絆創膏じゃダメなんですかね?

矢倉:いや、いいと思いますよ。

伊原:絆創膏で「アクセシビリティ対応やった」って言っちゃうと、こわいかもしれないっていう感覚があるんじゃないですか?

矢倉:ああ、つくる側から見ると、絆創膏あげたから「俺、医者だ」って言えるかっていう問題か。

伊原:そういう「アクセシビリティこわい」っていうのをなんとかしたいと思うんだけど。ガイドラインもこわいし、そのガイドラインに至っていないレベルで「やった」っていうのもこわい。実際、そのレベルで「アクセシビリティ対応、やったよ」っていうと、確かにいろいろ言われたりするのを見かけているんですよね。

——今、中小企業の経営者みたいな気分になっているんですけど、お金出してできる範囲で対応してみたら、ちょっとはホメられたいですよね(笑)。

伊原:まずは、やったというだけでえらいと思うんです。

矢倉:めっちゃ害になることって、まあ、たぶん少なくて。堂々と広報して、それがちょっと間違ってた場合に、多少炎上ぎみにはなる(笑)。

小さい会社ほどアクセシビリティが刺さる

伊原:外村さんがいうような「カジュアルに頼んでいいですよ」っていう制作会社が少ないんですよね。巨大な企業が、大きな制作会社に頼むっていう図式か、自治体が自治体対応している制作会社に頼むっていう2ルートになりがち。

例外なのは、時代工房さんとか、アルファサードさんとかかな。規模はそんなに大きくないですけど、たとえば時代工房さんは自治体の案件をやっていますね。

アルファサードさんはCMSを得意としているんですが、それに近いかたちで、システムベンダーがサイトのシステム化を受けつつ、アクセシビリティ対応もするっていうパターンが多いんですよね。アクセシブルな運用システムがつくれますっていうCMSを構築して、自治体に導入していくというスタイルですね。こういうお仕事の仕方だと、人数が多くなくても、対応していける。

もうひとり、おもしろいのが山本 和泉さんですね。彼女は小さい会社のウェブサイトをつくるコンサルティングをしていて、運用するのは自分たちにやってもらいたいので、サイト作成するとか、使いながら回すやり方を教えているんですけどね。「小さい会社ほどアクセシビリティは刺さる」って、彼女は言っているんですよ。なぜかというと、お客さんに障害当事者の方がいらっしゃるから。

全員:ああ、そうなんですね。へぇ。

伊原:スタッフや社長が実際にそういう方と出会っているんです。その人たちにも自分たちの店舗にちゃんと来てほしいと思っているんです。「じゃあ、サイトも使えるようにしたほうがいいよね」「そうだね」以上、なんです。

思うのは企業体が大きくなればなるほど、ユーザーから遠ざかっていくので、その必要性がわからなくなってくるんじゃないかなと。マーケットのパイを考え始めたり、ターゲットの属性を考え始めたりするときに、ユーザーのイメージが持ちにくくなるので、アクセシビリティ対応もなんとなく後回しにしてしまうっていうのがありそうなんです。

俺の店に来てくれる人で白杖を持っている人がいた。じゃあ、サイトはきちんと読み上げられるものにしようっていうのは、そりゃそうだよね、っていう話なんですよね。うちの美容院にくるお客さんには聴覚に障害のある人がいるから、動画には字幕をつけましょうは当たり前の話なんです。「あのお客さんには聞こえないから」って。

アクセシビリティ対応案件、小さく始めるには

伊原ウェブアクセシビリティ基盤委員会に出入りして3年経つんですけれど、案件はやっぱりあるんですよ。アクセシビリティ案件を抱えている民間のウェブ担当者はいるんですけど、どこに頼んでいいかわからないんですよ。

矢倉:たぶんね、「やってます」って言えるためには、何ができたらいいんだ? みたいな最初の一歩が踏み出せないと思うんだ。

伊原:いやそれはもう「できます」って勝手に言うんでしょう(笑)。結局、そうでしょう。

矢倉:うん、それから始めるしかないんじゃないかな。

——そうなんですか(笑)?

伊原:一番初めから、すでにやったことがあるなんて、矛盾だから(笑)。

——矛盾??

伊原:だってそうですよね。頼まれるには実績が必要だけど、頼まれなければ実績は積めない、っていうのは矛盾です(笑)。でもこれを突破する方法はあって、唯一、外部からの案件を受けないまま「できます」っていうなら、自社サイトでやるってことだと思うんです。

——あー、なるほど。

伊原:あるいは、仕事じゃなくてボランティアでやったものを取り上げるとか、でしかない。それはよく採用で「まず、自分のサイトをつくってこい」って言われるのと一緒ですよ。

やったことがある状態にするには、やってみるしかないんだけど、案件でやれないなら、自社サイトでやって、「やりました」っていうブログを書いて、メニュー化するっていう。

——それならできそうですよね。

伊原:うん、それならできそうでしょ。あとは、ブログの記事をイベントで登壇してしゃべるとかね。それこそ、ピクセルグリッドさんの戦略そのものですよ。技術的検証を外部でしゃべるっていう。

矢倉:まあ、でも自社サイトでも大変だよ(笑)。

伊原:うん、でもやりたいんだったら、それしかないですよね。

中村:それがいちばんやりやすいですよね。とりあえず、いろんな邪魔は入らないし、自分たちでやってみるっていうだけなので。それをやるなっていう人もいないし。まあ、大企業だったらわからないですけれど。

——今、ちょっとお話を聞いていたら、アクセシビリティ案件やりたいって思っても、規模の小さい会社にいたら、やれることがあんまりないのかな、って悲しい気持ちになっていたのですが、自社サイトがありましたね。それはできそう。

伊原:そのほかにも、まずはアクセシビリティを必要としそうなユーザーのヒアリングをするという手もあります。どんなふうに使ってますか? って。そのあとにアクセシビリティのガイドラインを見てもいいし、僕の本を読んでもいいし。そうやって貯めた知見を発信することはできると思いますね。

いずれにしろ、アクセシビリティ案件を受けるためには、サイトにそういう案件を受けられることを書いとかないといけない。

——でも、発注しようとする人は、もしかしたら「アクセシビリティ」って言葉は知らないかもしれないですよね?

伊原:そしたら「障害者」とか「高齢者」っていうキーワードでもいいんじゃないですか? 「障害がある人や高齢者にも使いやすいサイトがつくれます」って。アクセシビリティって言葉を知ってたら、もう業界側の人ですからね(笑)。あるいは「ユニバーサルデザイン」とかね。

ビジネスに結びつけたり、相手に発見してもらったりという文脈になってくると、アクセシビリティとはウェブの理念であってとか、障害者や高齢者に限られない、みたいな話は僕はいったん脇に置いていいと思っていて(笑)。それは、受注側がじわじわと発注側に伝えていく話であって、結果としてそうなっていればいいと思う。

——出会わないとねぇ。始まらないですものね。実際に、こうやったら言えるようになりましたっていうケースはあるんですか?

伊原フェンリルっていう会社がやってみてますね。あそこはデザイングループの中に、ユニバーサルデザインとかアクセシビリティをやってみたいって強く思っている人が何人かいて、自主的な勉強会をやったり、資格を取ったり、freeeの関西支社と大阪支社で合同の勉強会をやったり。

その中で、自分たちがつくったものをレビューしてもらったりして、だんだん知見をためて、UDをやる課をひとつつくりましたっていうのを書いて、立ち上げをしています。

(次回へ続く)

中村 享介
PixelGrid Inc.
Jamstackエンジニア

2009年、JavaScriptの会社として株式会社ピクセルグリッドを設立。 多数のWebリニューアル、新規立ち上げを取り仕切った経験を持ち、情報設計、フロントエンド、クラウド活用、開発フローの効率化を得意とする。 Webをより発展させるため、新しくブラウザに実装された機能の活用事例を数多く生み出しつつ、日々、クラウドサービスを利用した効率のよい制作・開発手法の試行錯誤を続けている。現在の興味はWeb Componentsを使ったマークアップの改善とJamstack。 著書に『WebクリエイティブのためのDOM Scripting』(単著:毎日コミュニケーションズ、2007年)など。ここ数年は書籍の執筆をせず、フロントエンド技術情報メディア「CodeGrid」で精力的に執筆活動を行っている。

外村 奈津子
PixelGrid Inc.
編集

情報出版社に在籍中、Mac雑誌、中高年向けフリーペーパー、コラムサイト運営、健康食雑誌、グラフィック・Web技術書籍編集、IT系ニュースサイトの編集記者を経験。その後フリーランスのエディター/ライターとして独立。2011年4月より株式会社ピクセルグリッドへ入社。ピクセルグリッドが提供するフロントエンド技術情報を提供するサービス「CodeGrid」の編集を担当している。

坂巻 翔大郎
PixelGrid Inc.
フロントエンド・エンジニア

大手ソフトウェアダウンロード販売会社、Web制作会社などで、マークアップエンジニア、プログラマ、サービス企画、ディレクターを経験。2013年、株式会社ピクセルグリッドに入社。HTML、CSS、JavaScriptなどをオールラウンドに担当。とりわけ、プログラマブルなCSSの設計、実装を得意とする。 趣味で作成したゲーム「CSS PANIC」は、JavaScriptを一切使わず、HTMLとCSSのみで実装。海外サイトで紹介されるなど話題となった。

矢倉 眞隆
PixelGrid Inc.
フロントエンド・エンジニア

2016年10月にピクセルグリッドへ入社。Web標準技術やブラウザの実装動向に明るく、イベントでの講演や雑誌・オンラインメディアへの原稿執筆、書籍の監修・監訳などを数多く経験。 Google Developer Expertとしても活動中。

Xにポストする Blueskyにポストする この記事の内容についての意見・感想を送る

全記事アクセス+月4回配信、月額880円(税込)

CodeGridを購読する

初めてお申し込みの方には、30日間無料でお使いいただけます