はじめに

2018年9月14日に新宿グランドタワーで開催されたWordCamp Tokyo 2018 に参加してきました。WordCamp は WordPress にかんするイベントで、私もこれまで何回か参加したことがあります。この記事では、参加したセッションの感想を書いていきます。ちなみに、この記事は WordPress の新しいエディタである Gutenberg を用いて書かれています。

各セッションの感想

State of the Web

こちらは PixelGrid の矢倉眞隆さんによっておこなわれたセッションです。矢倉さんといえば、Web標準のころから私の中では超偉大なお方。公式ブログでも「基調講演」と言われているようなセッションで、Web の現状について話してくださいました。

実務で Web にふれていると、どうしても Web の良さなどについて、忘れがちになってしまう傾向があるので、あらためて現状の Web のいいところと足りないところを知ることができてよかったです。

セッションの中で、一番おっと思ったのは、Google の興味がインドに向いているというところです。ネット人口がまだそんなに多くなく、これから伸びしろのあるインドは、通信環境がとても貧弱なので、AMP や PWA でリーチしていくという話でした。これには納得感しかありませんでした。

WP REST API と React で始めるリモートワークでの有料 Web メディア開発

島田俊介さんのセッション。ブースを回り終わって、少し時間ができたので、本当の終盤だけ飛び込みで参加させていただいた。クーリエジャポンと EXPAT というメディアがあって、両方で WordPress を利用しており、データの受け渡しに REST API を利用しているというざっくりとした話しかわからなかった。

また、おっと思ったのはリモートワークの話。なにか自分がアクションを起こした際は、かならずクライアントの Slack に通知が飛ぶようになっているが、今の所それについてのクレームは出ていないらしい。クライアントいわく、「何をしているかわからないよりいい」とのこと。たしかに、同じ職場の同僚の進捗もいつも気になっているし、顔が見えない環境ならなおさら不安になるのだなあと。共有大事だなとあらためて感じました。

より便利に、効率よく ! WordPress 次期エディター「Gutenberg」の基本的な操作を知って、今日から使い始めよう

Tetsuya Imamuraさんによるセッションで、WordPress の新エディタ Gutenberg に関するセッションです。おそらく、今回注目度の高いセッションのひとつだったのではなかったでしょうか。スライドはこちら。

実際の Gutenberg の画面を使って、編集はどのように行うのかや各箇所の動作、これから実用するにあたっての準備を説明してくださいました。15分という短いセッションだったのですが、Gutenberg を全然さわっていなかった私には、概要をつかむには十分な内容でした。

Google 検索最新情報 2018！新しい Search Console の活用法

Google の金谷武明さんによるセッション。金谷さんは有名人なので、色々なところでお見かけします。セッションの中では、Google の取り組みを説明したあとに、新しい Search Console の説明をしてくださいました。

AMP の WordPressプラグインは、本サイトでも導入しています。色々懸念する事項はあるのですが、上述のインドの話なども含め、Web の高速化という点では、かなり重要になってくると思います。また、https については、Google が出している透明性レポートに基づき、他国に比べて日本が遅れていることについて説明していただきました。

新しい Search Console については業務でやっとさわりはじめた段階なので、各レポートの見方と気にするべきポイントを聞けたので、大変有意義でした。

Challenge PWA!! Web の舞台はホーム画面へ進撃する !

進藤龍之介さんによる PWA に関するセッション。最初の矢倉さんのセッションでもふれられていたこの PWA について説明したあとに、実際どうすれば、PWA 化ができるかを実際の画面をもとに説明してくださいました。

PWA の説明自体は先に聞いてしまっていたので、新しく知ることはなかったのですが、実際の PWA 化の手順については、うっすらと知っているだけでちゃんとした知識がなかったので、実際のファイルを拝見することができ、とてもためになりました。

PWA の構成は、コンテンツと Manifest、Service Worker の3点。コンテンツは必ずhttpsでなくてはならない。WordPress であれば、オフライン用の固定ページを作成する。Manifest は、json形式でアイコンなどの設定を記述する。Service Worker では、キャッシュの制御や PUSH 通知の設定を行う。

キャッシュの有効期限の点で悩みどころがあるが、それを解決するための WordPress プラグイン「PWA for WordPress」をスピーカーの進藤さんが作成されているので、WordPress のサイトを PWA にする際は、そのプラグインを使う。

かなり内容盛りだくさんで、時間もいっぱいいっぱいのセッションでしたが、とても満足感がありました。今回、一番ためになったセッションかもしれません。Challenge PWA!! WordCamp Tokyo 2018のスライドもご参照ください。

Gutenberg 解体新書

宇都宮諒さんによる、Gutenberg の技術的な内容に関するセッションです。当日の発表に使われたスライドはこちら。

Gutenberg 自体はほぼ JavaScript でできていて、dependencies は React.js、jQueryなどで、devDependencies は、Babel や webpack。React.js で用いられる JSXという形式の書式についてや、ブラウザでそのまま実行できないその形式をトランスパイルする Babelなどについて、それぞれの仕組みや働きを理解することができました。

そのあとに、Gutenberg のブロック API  について説明していただきました。さきほどの、JSX 形式がばんばん出てきたので、学ばないといけないと感じました。私のフロントエンド関連の知識が、2015年ぐらいで止まってしまっているので、早く追いつかなければという気持ちになりました。

そして、スライドの最後で紹介された、”Learn JavaScript, deeply”という WordPress の開発者である Matt Mullenweg の言葉の通り、今後は JavaScript をより学んでいく必要があるとあらためて感じました。SEO 方面でもそういう話がありましたし。 → テクニカルSEOの上級者になりたいならJavaScriptに精通すべし

事例から見る、アクセシブルな WordPress サイトの運用現場の実際

上記のセッションが規定の時間より少し早く終わりましたので、柴田宣史さんのアクセシビリティに関するセッションの部屋に急いで入ったのですが、時すでに遅し最後のスライドが表示されていました。

Gutenberg 解体新書とこのセッションのどちらを受講しようかずっと悩んでいたので、かなり悔しい感じではありましたが、登壇者の柴田さんが以前、アクセシビリティの情報サイト「Accsell」のポッドキャストに出演されていた際に話されていた『JIS X 8341-3:2016, WCAG 2.0早見表／逆引き表』をもらうことができ、それはとても嬉しかったです。

おわりに

今回もとても有意義な会でした。運営にかんしても、開場直後の長蛇の入場列以外、大きな問題はなかったと思います。運営の方々、ありがとうございました。

個人的には、Google の動きをこれまで以上に気にしていく必要性があると感じました。それと同時に、WordPress を含めた Web の仕事をしていくなら、JavaScript をどんどん学んでいかなければという決心を新たにしました。

概要

ARIA in HTML で main のように暗黙的な ARIAセマンティックがある要素では、同じ意味を持つ role 属性が非推奨になったので、ゆくゆくは外していく流れ。だけど、今現在は古いブラウザの対応などがあるので、まだまだ role 属性は外せなさそう。

<main role=”main”> という記述が非推奨に

ミツエーリンクスさんのアクセシビリティBlog で、ARIA in HTML（日本語訳）というものの草案が4月14日に発表されたことを知りました。HTML5.1 において、WAI-ARIA をどのように使っていけばいいかが書かれている文書のようです。で、記事を読み進めていく中で気になった点が一つあったのでメモ。

お！HTML5.1 では、暗黙的に ARIAセマンティックが規定されている要素に対して、それと同様の意味を持つ role 属性などを付けるのは非推奨になる流れのようです。引用した記事内では main 要素の例が挙げられています。では、<main role="main"> は <main> と書くという話ですが、header 要素に role="banner" をつけたり、footer 要素に role="contentinfo" をつけるのも非推奨になるのでしょうか。

ARIA in HTML で確認

どの要素に対して、どの role属性を使用してもいいか、はたまた使用すべきではないかは ARIA in HTML にちゃんと書いてあるようです。ARIA in HTML の中の 2. Document conformance requirements for use of ARIA attributes in HTML（日本語訳）という項目の中にあります。3列の表組みがあって、1列目は対象となる HTML の要素。2列目が暗黙的に規定されている ARIAセマンティック。これには「SHOULD NOT be used」と書かれています。使うなと。3列目は、ARIA のロール、ステート、プロパティー。こちらは「MAY be used」なので、使ってもいいよとのこと。

先ほど例に挙げられていた main 要素を見てみると、2列目には role="main"、3列目には No role / global aria-* attributes と書かれています。「暗黙的に role="main" という ARIAセマンティックが規定されているので、使っていいロールは無いよ。aria-label とかのグローバルなステートやプロパティーは使っていいよ」ということのようです。

では、前の項で挙がった header だったり footer だったりはどうなるのか。header は2列目に If not a descendant of an article or section element role=banner, otherwise NONE、3列目は先ほどの main にもあったように global aria-* attributes と書かれています。「article と section の子孫じゃない場合は暗黙的に role="banner"。それ以外の場合はデフォルトの ARIAセマンティックを持ちません。グローバルなステートやプロパティーは使っていいよ」ということらしいです。

article と section の子孫じゃない場合、つまりサイトのヘッダーとして header を使うみたいな時は暗黙的に role="banner" という ARIAセマンティックが規定されるということでしょうか。逆に、article と section の子孫の場合、例えば記事タイトルとか投稿日時などのメタ情報を記事内に記載する場合に使う header は ARIAセマンティックを持たない。暗黙的な ARIAセマンティックを持っている要素に対して、role 属性を付けるのは非推奨ということなので、サイトのヘッダーとして使う時は role="banner" を付けるのは非推奨になるようです。

footer の場合も role="banner" が role="contentinfo" に変わっただけで同じです。 コピーライトや作者の連絡先を載せているサイトのフッターとしての footer には暗黙の role="contentinfo" を付けるのは非推奨になるようです。

role 属性は補助輪

先日買った書籍「コーディングWebアクセシビリティ」の P90からP99「4-2 有名なランドマーク」という節に、role 属性に関することが書かれています。特に重要だと思ったのは、暗黙的なARIAセマンティックを持つ要素に対して role 属性を付けるのは、自転車に補助輪を付けているようなものという箇所です。

role 属性無しの HTML 単体でアクセシブルな状態ならばそれでよいのですが、今現在はそのような状態ではありません。書籍内に補助輪は、補助輪なしで走れるようになるまで自転車のタイヤを支えるためにあるのです。とあります。ARIA in HTML を参照するように書かれている HTML5.1 はまだ草案段階ですし、古いブラウザのサポートもあるので、今現在はまだまだ role 属性という補助輪なしで走れるような環境ではありません。時期尚早だと思います。

ということで、role 属性という補助輪を今すぐに外せるとは全く思いませんが、後々はこうなっていくということを覚えておきたいがためのメモでした。

ブログ改善シリーズ。今回は、リンク箇所に下線を表示する改善を行いました。これ自体は全く難しいことではないのですが、何故そうしたかを書いていきます。

改善前

まず改善前の画像を見ていただきたいと思います。リンクは青色、通常の文字は黒色。一応、リンクと通常の文字は見分けられる。ちなみに、もう修正済なのですが、以前はリンクにホバーすると下線が引かれるようになっていました。

一見何も問題ないように見えますし、このようなスタイルのウェブサイトはいくつも見てきました。が、アクセシブルかどうかでいうと、問題があるようです。

達成基準

当然、色の使用に関しても、しっかり JIS X 8341-3:2010 では達成基準が設けられています。

前の記事でも参照させていただいた、インフォアクシアの植木さんのJIS X 8341-3:2010を『日本語訳』してみる！～Webアクセシビリティの基本の『キ』～ というスライド（PDF） の 96 ページを参照すると、上記の文章は色の違いが分からなくても理解できるようにするという意味のようです。

グレースケールでこのブログを見てみる

では、色の違いが分からない状態で、このブログを見てみるとどうなるか確認してみます。(un)clrd というブラウザの画面をグレースケールにできるアドオンがあります。Chrome 用と Firefox用があります。このアドオンで私のブログをグレーにして見てみます。

グレースケールにすると、リンクであることがわかりづらくなります。太字にはなっているけど、これだと <strong> による強調と区別がつかないので NG 。

改善後

この状態を改善するために、リンクに下線をつけました。以下が改善後のブログをグレースケールで見た画面です。

これで、色の違いが分からない環境で見ているユーザーさんでも、通常の文字とリンクの違いがわかりやすくなりました。