読者です 読者をやめる 読者になる 読者になる

おるたなブログ

デザインとかプログラミングとか

「Frontrend Vol.9 - 春の新人歓迎 マークアップ/アクセシビリティのキホン」に参加してきた

放置してたブログですが久しぶりに更新します。

frontrend.connpass.com

「Frontrend Vol.9 - 春の新人歓迎 マークアップ/アクセシビリティのキホン」というイベントにブログ絶対に書くパーソン枠として参加してきました。

テーマとして自分も最近取り組みはじめていた「アクセシビリティ」がキーワードに入っていたため非常にワクワクしながら参加しました。
また春ということで「新人歓迎」のワードの通り比較的易しめの発表が多かったです。

当日の録画がありがたいことにFRESH!にて公開されています。 Frontrend Vol.9 - 春の新人歓迎 マークアップ/アクセシビリティのキホン | FRESH!(フレッシュ) - 生放送がログイン不要・高画質で見放題

発表の内容についてはネットで得られるので割愛し、自分が思ったことを中心に書いていこうと思います。

継続的にアクセシビリティを高めるために ~ まずは無理なく基本を押さえる ~

masup.net スライド

@masuP9 さんによるアクセシビリティについての発表が一発目でした。

アクセシビリティは誰がやるもの?

img要素のaltプロパティに指定する文字列は、画像の視覚的情報をそのまんま文字列として記入するのではなく、ちゃんとした「代替」としてテキストを記述する必要があります。 会社のロゴ画像があったとして、 alt="ロゴ" は適切ではなく alt="会社名" とするべきです。 (ちょっと良い例思いつかず…)
画像がそのコンテンツの中でどういった意味を持つのか、エンジニアだけでは判断してを設定するのは難しい一面があります。

懇親会でお話伺った際に「altはcontents authorが書くべき」のような趣旨のことをお聞きし、 「あ、アクセシビリティは当然ながらエンジニアだけで完結するものではないんだな」 と改めて納得しました。

また発表でおっしゃってた「キャラ作り」、アクセシビリティおじさんとしての認知=だれかが思い立ったときに相談できる状況・環境を作ることについて非常に大切ですね。

プロジェクトごとのガイドライン

自分も今参加しているプロジェクトで小さなアクセシビリティガイドラインを書き始めたところです。
レビューで指摘事項として「ここはボタンを使ってくれ」「Labelにはid絶対」のような項目をあげても 指摘される側からは「知らなかった」「そういうルールは何をみれば良いの?」など戸惑いの声が上がってきます。
※フロントエンド主語でかすぎ問題に起因する

プロジェクトに合わせて頻出するポイントを説明と具体的なコードをセットでガイドラインとして提示し、アクセシビリティについて知識を深めてもらうことは アクセシビリティにチームとして取り組んでいく一つの方法かなと思います。

特にエンジニアにとってはGood&Badをコードで表現するのはわかりやすく感じるのだと思います。

もちろん仕様をしっかり読み解ける力をつけるのが一番良いことにはこしたことはありません。

@masuP9 さんが現在作成をすすめているアクセシビリティガイドラインGithubでそのうち公開予定とのことでとても楽しみにしています。
Forkして一部がっつり参考にする予感

コンポーネントによる解決

とはいえ、完璧なアクセシブルなコードを記述しきることもなかなか難しいと思っており、
一つの解決策として、アクセシビリティ対応済みのJSコンポーネントを使ってもらうという手段があります。

// Reactコンポーネント
export default Link extends React.Component {
  render() {
    if (this.props.href) {
      return (
        <a href={this.props.href}>
          {this.props.text}
        </a>
      );
    } else {
      return (
        <button type="button" onClick={this.props.onClick}>
        {this.props.text}
        </button>
      );
    }
  }
}

簡単なサンプル書いてみましたが、こんな感じの解決もアリなのかなと思います。

React.jsなどのフレームワークを仕様しているとうっかりhrefをもたないa要素を記述してしまうこともあります。 なのでReactコンポーネントでhrefの有無でハイパーリンクなのかもしくはボタンなのか?を判断して適切な要素を返すようにします。

またCSSフレームワークのBootstrap、サンプルコードをみればわかりますがアクセシビリティを考慮したコンポーネントを提供しています。 div地獄や、汎用性を意識して無理やりなコードになってる部分もあるのですが、こういったものに試しに乗っかってみるのも手だと思います。

まとめ

Webの一番表層にある品質について目を向けれていないのは、プロとしてどうなんだろうとモヤモヤしていたところで、
個人的にあたりまえのこととして、自然にアクセシビリティに取り組んでいけるレベルを目指していきたい思っています。

そのために「まずは無理なく基本を押さえる」少しづつできることを広げていこうと思います。
チェックツールもいろいろあるみたいなので一度ボコボコに殴られてみるのも一興

あくせしびりてぃーーーーーーーーーーーーーーーーーーー
元ネタよくわからず

マークアップの最適解を見つけ出す方法

speakerdeck.com スライド

@KasumiMorita さんによる発表です。
スライドのデザインがとても素敵です。

楽しいマークアップ

マークアップ沼は一度はだれもがはまる沼ですね。

デザインに引きずられずにDOM構造を保つ

デザイン上では見栄えを優先した構造でも、HTMLを組む際は文章的に正しい構造でマークアップした上で、CSSでデザインを改めて整えるという内容で、 正直ここまでこだわっているのは、「つ、強い」と思いました。

スライドでは table-header-grouptable-footer-group を仕様したレイアウトの反転がでてきましたが、IE9も切れたことですしFlexboxを使うと調整が楽になるのかなと少し思いました。

プロジェクトごとに優先順位を決める

とはいえマークアップ至上主義ではいられない、納期は守らないというのはあたりまえで、様々な要求にたいして優先順位をきめていかなくてはいけません。
自分はなかなかコントロールができず頭が痛くなるような話です。

個人的にはそもそもWebというプラットフォームに乗っかるのなら、仕様やアクセシビリティの優先順位が上がるよう日頃から周りの人に対してコミュニケーションをとっていかないとなぁと思っています。
デザイナーさんもHTMLについて知らないことが多く、Webに適したデザインがあがってこないこともあります。
それについて指摘してHTMLはどんなもの?ということを知ってもらうのもフロントエンドエンジニアの役割ではないでしょうか。

クイズ

section予想でクイズ選択肢にすらかすらず残…念…

アウトラインチョットデキル

t.co スライド

@o_ti さんによるアウトラインについての発表です。

楽しいセクション沼

自分がHTML5を学び始めた入り口はsection要素だったのをよく覚えています。 なんとなくで書いていたHTMLが、sectionを正しく使うことで堅牢な構造に変わっていくのは快感でした。

sectionを学ぶことは、正しい文章構造について考える助けとなると自分は思っています。

section > h1によるセクショニング

すべてh1にするか階層にあわせたレベルで記述するように強く推奨されている

全く知らなかった仕様でおもわず会場で頭の悪いツイートをあげてしまいました。

たとえばWebシステムでつかわれるモーダルダイアログなどは、どの階層のセクションで使われるか予測がつきにくいため、 見出しのレベルが非常に決めづらいです。

h1 onlyで良いというのなら解決の糸口が見えるのかなと思いました。

これについては問題点もあり、 @kazuhito さんのブログで言及されてますので読んでみてください。

ありがとう

ありがとうアウトラインアルゴリズム

最後に

ところで、飛び込みLTで @magi1125 さんからInclusive Design Patternsの翻訳を出すよ!というお話がありました!
日本語版のタイトルはまだ決まってないとのことでどんなのになるのか楽しみです!
自分の中ではずっと前から 購 入 決 定 という感じでありました。
これを出してるSmashing MagazineはAtomic Designの良書を出してたりするのでチェックしとこうかなーと思ってます。

こうして深く掘っていけるHTMLは楽しいなぁと思いました。 「フロントエンドエンジニアだけど主戦場はJavaScript」という方でも、 HTMLの面白さを知ってほしいな〜と改めて思った次第です。

登壇者および運営の方々、本当にありがとうございました!