2017年10月
2017年10月31日(火曜日)
退職のご報告
公開: 2017年10月31日18時5分頃
既にご存知の方はご存知かと思いますが、本日をもって株式会社ビジネス･アーキテクツを退職することになりました。
思い起こせば、2001年の8月に「フルCSSで大規模企業サイトを作りたい」と言われて入社してから16年以上勤めたことになります。支えてくださった皆様、本当にありがとうございました。
入社した当時は本当にHTMLの知識しかなかったのですが、いろいろな方と一緒に仕事をしていく中で、さまざまなことを教わりました。印刷物のマージンや字詰めが気になるようになったのもBAに入ってからの話です。このあたり、たまキャリ#1「会社を変えず、中身を変え続けてきた人」 (www.dsp.co.jp)で少しお話ししましたので、興味のある方は見ていただければと思います。
さて今後ですが、実は決まっていません。
個人的には、Webのアクセシビリティとセキュリティの分野に関心があるのですが、その両方を活かせて、かつ講演や執筆なども自由にできそうな職場というのはなかなか難しいかもしれません。何か面白そうな話がありましたら、ぜひお聞かせいただきたいと思います。
- 「退職のご報告」にコメントを書く
関連する話題: BA
2017年10月25日(水曜日)
アクセシビリティの専門家の言うことは唯一の正解ではない
公開: 2017年10月25日22時5分頃
11月発売予定の「インクルーシブHTML+CSS&JavaScript - 多様なユーザーニーズに応えるフロントエンドデザインパターン (www.amazon.co.jp)
選択肢は、視覚的にも非視覚的にもユーザーにわかりやすく表示することが重要です。音声によるアクセシビリティの専門家は違うことを言っているかもしれませんが、実際のところ、このやり方は間違っている、このやり方でなければならない、というようなことは言えません。何が最も効果的なソリューションなのか考えることは、みなさんのデザイナーとしての判断になります。
正直ちょっと何を言っているのか分かりにくいかもしれませんが、アクセシビリティを向上させるための方法は一つではないということ、特に、専門家の言っていることが唯一の正解ではない、ということを言っています。
結局のところ、Webコンテンツは誰かに何かを伝えるために作られています。発信者には伝えたいことがあるはずですが、それがどのように伝わればベストなのかは、最終的には発信者にしか分からないことです。
さて、少し前の話になりますが、このような記事が話題になりました。
- 【アクセシビリティ】HTML/CSSで突っ込まれた点をメモメモ (bashalog.c-brains.jp)
専門家の指摘ということなのですが、これはなかなか興味深いですね。見出しの上に画像を置いている個所について、以下のような指摘があったとしています。
見出しに関連している画像が見出しより前に記述されています。現在の状態ですと、適切な構造がユーザーに伝わりません。見出しに関連しているコンテンツは見出しよりあとに記述します。
実際の指摘がこれだけだったのかはわかりませんが、これでは説明不足でしょう。「適切な構造」とはいったい何なのでしょうか。見出しの上に画像があるというのは一般的によく見られる構造で、これをただ不適切だと言われても、意味が良くわからないですね。
おそらく指摘者が言いたかったのは、見出しジャンプ機能との親和性の問題だと思います。スクリーンリーダーの利用者は、見出しにジャンプする機能を利用してコンテンツを読むことがあります。見出しにジャンプした後、通常は見出しの下にあるテキストを読んでいくことになりますので、見出しの上に要素があっても読み飛ばされてしまう可能性があります。
ではどうすればよいのでしょうか。引用元の記事では以下の様に述べられています。
よって、HTMLは以下の様に書かないといけません。
<div>
<h2>見出し</h2>
<img src="xxxxxx.jpg" alt="">
<p>テキストテキスト・・・・</p>
</div>「これでは見出しが画像の上になっちゃう！」と思われるかもしれませんが、そこはCSSでflex等を用いて順番を入れ替えればOKです。
見た目は変えず、HTMLのソースコードの順番だけ入れ替えれば問題ないという判断のようです。
ちょっと待ってください。こんなに簡単に入れ替えるという判断をしてしまって良いのでしょうか。WCAG 2.0には以下のような達成基準があります。
1.3.2 意味のある順序: コンテンツが提示されている順序が意味に影響を及ぼす場合には、正しく読む順序はプログラムによる解釈が可能である。 (レベル A)
見た目の順序とソースコードの順番が食い違うと、見た目の順序と読み上げの順序が異なることになります。順序に意味があれば、それは問題になります。
とはいえ、ここで挙げられている事例に限って言えば、おそらく大きな問題はないでしょう。というのも、この例では画像の代替テキストが空 (alt="") だからです。この画像は装飾であり、情報を伝えようとするものではないということでしょうから、これが見出しの上にあるか下にあるかによってコンテンツの意味が変わってくることはないと言えます。
※と同時に、読み飛ばされても問題ないと言えるので、見出しの下に持ってくる必要もないと言えます。
では、この画像に意味があったとしたらどうでしょうか。あるいは画像ではなく、テキストだったらどうでしょう。見出しの上にテキストが置かれることはしばしばあります。典型的な例は、商品名の前にキャッチフレーズがついていて、それが小さく表示されているような場合です。見出し上のサブタイトルとして扱って、以下のようにすることがあるのではないでしょうか。
<p class="subtitle">キャッチフレーズ</p>
<h2>商品名</h2>
<p>説明</p>
これを以下のように入れ替えてしまって良いのかということです。
<h2>商品名</h2>
<p class="subtitle">キャッチフレーズ</p>
<p>説明</p>
この場合、なぜこのような書き方にしているのかがポイントになります。単純に商品名として表記するのではなく、わざわざサブタイトルにして見せ方を変えているのは、そうする理由があるからです。特に、実物がそうなっているという場合があって、これは簡単には変えられません。実物の商品ラベルで見出しの前に小さくキャッチフレーズを表示していれば、Webでも同じように表記したい、と考えるのは自然です。ユーザーにとっても、目にするものがそろっていたほうが良いはずです。
このような場合、順序には意味があるといえるでしょう。ソースコードの順番を入れ替えれば、読み上げの際には実物の表記と異なる読み上げになってしまい、逆にアクセシビリティ上の問題が生じることになります。
ではどうするかということですが、すぐに思いつくのは見出しの中に入れるという方法です。
<h2><span class="subtitle">キャッチフレーズ</span> 商品名</h2>
<p>説明</p>
これは一見よさそうですが、見出しが長くなるという問題があります。長いキャッチフレーズが来たらどうなるのか考えてみてください。視覚的には、キャッチフレーズは小さな文字で表示されるのでしょうが、スクリーンリーダーでは見出しと同じように読むことになります。見出しにジャンプしたとき、まずキャッチフレーズが読まれる、という状態が本当に使いやすいのかどうか、慎重に考える必要があるでしょう。
small要素を考えた方もいらっしゃるかもしれません。
<h2><small>キャッチフレーズ</small> 商品名</h2>
<p>説明</p>
これは結果としては同じで、少なくとも今のところは、スクリーンリーダーがsmall要素を特別扱いすることはありません。
WAI-ARIAを駆使する方法もあります。属性をいくつか付け足すと、マークアップの大枠の構造は変えずに、見出しのところでサブタイトルを読ませることができます (参考: ARIA9: 複数の語句をつなげて一つのラベルにするために、aria-labelledby を使用する (waic.jp))。
<p class="subtitle" id="sub_01">キャッチフレーズ</p>
<h2 aria-labelledby="sub_01 main_01" id="main_01">商品名</h2>
<p>説明</p>
正直こんなIDだらけにしたくないというのもありますし、対応状況の不安もあります。Firefox+NVDAでは意図通りに動作しましたが、Edgeではうまくいかないようです。
※Edge+NVDAでは見出しのところで「ブランク」と読まれてしまいました。あるいはEdgeがaria-labelledbyの複数指定に対応していないのかもしれません。
……と、いろいろ考えてみましたが、さまざまな方法があり、それぞれに長所と短所があるわけです。ここでもう一度、冒頭に紹介した「インクルーシブHTML+CSS&JavaScript (www.amazon.co.jp)
何が最も効果的なソリューションなのか考えることは、みなさんのデザイナーとしての判断になります。
何が最良なのかを考えるのは、アクセシビリティの専門家の仕事ではなく、コンテンツ制作者であるデザイナーの仕事だということです。コンテンツ制作者は、ユーザーに何を伝えたいのか、何がどのように伝わるのが良いのかということを考えたうえで、ソリューションを選択するのです。
それに対して、第三者の立場でチェックを行うアクセシビリティの専門家には、コンテンツ制作者、特にビジュアルデザイナーの意図は分からないことがほとんどです。コンテンツの完成後に第三者がチェックするという形をとる限り、どういう意図でこのような見た目にしたのか、この要素は本当に必要なのか、順番を変えて良いのかダメなのか、といったことを知るのは難しいことが多いでしょう。
専門家によるチェックというのは、あくまでこういう制約のもとに行われているものです。指摘の中には、「おそらくこういう意図だろう」という想像に基づいたものも多くあり、それは絶対ではないということに注意してください。
2017年10月24日(火曜日)
「インクルーシブHTML+CSS&JavaScript」11月4日発売予定
公開: 2017年10月24日22時0分頃
こんな本が出ることになりました。11月4日発売予定です。
- インクルーシブHTML+CSS&JavaScript - 多様なユーザーニーズに応えるフロントエンドデザインパターン (www.amazon.co.jp)
原著者のヘイドンさんは、「コーディングWebアクセシビリティ (www.amazon.co.jp)
前著はWAI-ARIAの入門的な位置づけで、分量も少なく、軽く読みやすい構成になっていました。コード例もありましたが入門的な例でしたので、現場で使うには少し物足りない印象もあったのではないでしょうか。
それに対し、この本では、現場で実際に使えるようなパターンを紹介しています。ブログ記事、ナビゲーションボタン、商品リスト、フィルターウィジェット、登録フォームなどは、マークアップの現場でも実際に扱う機会が多いものでしょう。まずHTMLを書いてから、そこにCSSとJavaScriptを適用していくというのが本書の基本的な方法論ですが、なぜその要素を選択し、どのようなJavaScript実装を適用するのか、といったことが順を追って書かれていて、実際に手を動かしながら追うことができるような構成です。ハンズオンの講習に使うこともできるでしょう。
私は監訳としてクレジットされていますが、全体の訳文の調整、訳注の執筆などもしています。ちまたでは訳注が多い本だと噂されているようですが、手元のデータの文字数をおおざっぱにカウントしてみたところ、訳注が占める割合は12%弱のようです。他の本がどうなのかはよく分かりませんが、1割以上が訳注なので、それなりに多いようには思います。
訳注が増えた原因のひとつは、時の流れです。原著の発売は2016年10月なので、執筆はその少し前になると思いますが、HTMLの仕様が変わったり、当時は実装されていなかった機能が実装されたり、スクリーンリーダーの対応が進んでいたりと、さまざまな変化がありました。本当に変化が早いものです。
なお、この本で語られている実装方法は、あくまで方法のひとつでしかないことに注意してください。他にもさまざまな方法がありますし、他の方法がダメだというわけではありません。さまざまな方法にはそれぞれ一長一短があり、原著者の主張する実装方法にも長所だけでなく短所があります。この本の実装方法をベースに、短所について議論していただいたり、より良い案を出していただくのも良いでしょう。「この方が良いのでは?」といった感想を持たれた方は、ぜひ共有いただき、議論を深めていただきたいと思います。
※なお余談ですが、監訳者の間では、原著者の主張に賛同できない部分に対してもっと訳注をつけてはどうかという議論がありました。しかし、原著者に反論できないような形でdisってしまうのもどうかと思ったのと、本の外の世界 (ブログやSNSなど) で議論が深まる方が建設的なのではないかという観点から、そのような訳注は控えめにしています (とはいえ短所の説明が不足していると思われたところには訳注を入れています)。
- 前(古い): 2017年7月のえび日記
- 次(新しい): 2017年11月のえび日記
