HTMLを直接読み書きせず、スクリーンリーダーも使わずに、アクセシビリティを向上させられないだろうか（と思ってブラウザ拡張を作ってる） これまでの何年間か、Webアクセシビリティまわりのことをやってきた中で、「Webアクセシビリティに取り組む」上でいろいろな障壁を感じてきました。 「なぜWebアクセシビリティをやるのか」の理解を得る・得てもらうまでの障壁 イノベーター層・アーリーアダプター層な開発者（エンジニアやデザイナー）が取り組みを始める上での障壁 マジョリティ層が取り組みを始める上での障壁 今回はこの3つめの「マジョリティ層が取り組みを始める上での障壁」の話です。 残りの2つについては、私が執筆に参加したWebアプリケーションアクセシビリティが網羅的なガイドになってくれるはずです。しかしコイツは内容的にも物理的にもゴツすぎる問題があると思っていて、導入編としては見えにくい、読みにくい

Webアプリケーションで、大量のデータを表示したいときに使われる、「仮想スクロール」と呼ばれるテクニックがあります。 大量のデータを素直にDOMに挿入してしまうと、レンダリングの処理に非常に負荷がかかり、場合によってはブラウザをフリーズさせてしまったりします。そこで使われるのが「仮想スクロール」です。スクロール位置に応じて、視覚的に見える範囲のデータのみをDOMに挿入することで、レンダリング処理を最小限にするというものです。 この仮想スクロールについて、直感的にスクリーンリーダーでの閲覧に耐えられるのかの不安を感じました。しかし、あまりテーブルを仮想スクロールする場合についてのまとまった情報をWeb上で発見することができませんでした。 そこで、実際に仮想スクロールを採用した検証用のWebアプリケーションを作成し、スクリーンリーダーでの動作を確認してみることにしました。 「日本の郵便番号」ア

ASTをみてみよう この不思議な現象を調査するために、AST（Abstract Syntax Tree: 抽象構文木）の状態を見てみることにしました。ASTはソースコードを構文解析した結果をツリー構造にしたもので、AST Explorerを使うと簡単に見ることができます。 ({}) + "" のAST ({}) + "" のASTをみると、ひとつの　ExpressionStatement　となっているのがわかります。ExpressionStatement の leftは ObjectExpression 、 operator は + 、rightは Literal となっていて、たしかに Object と String の足し算になっています。これなら確かに"[object Object]" が返ってくるでしょう。 {} + ""のAST しかし、{} + "" のASTをみると、Bloc

筆者は、より多くのWebサイトやWebサービスが、より高いアクセシビリティをもつものになることを強く願っています。 （2024/02/04追記）もう少しわかりやすく書き直したものを投稿しました Webアクセシビリティと合理的配慮 「2024年からWebアクセシビリティ対応が義務化される」というようなことが書かれたWeb上の記事が増えているようです。 しかし、2024年1月現在、日本で「Webアクセシビリティ」について法的な義務が発生している・または2024年内に発生するようになる法的な根拠はおそらくありません。法律の改正が施行され、「やったほうがいい」度合いは高まっていると解釈できますが、「Webアクセシビリティは義務です」とまでは明言できないはずです。 ところが、「アクセシビリティ 義務化」などでWebを検索すると、「2024年にアクセシビリティが義務化します」と説明していたり、あるいは

こんにちは、この記事は Webアクセシビリティ Advent Calendar 2020 の6日目です。 すこし前に、同僚のエンジニアに「Webアプリケーションにドラッグ＆ドロップを使う機能を作ろうとしているんだけど、アクセシビリティは何をすればいいのかわからない」という相談をされる機会がありました。そのときの回答が、実はアクセシビリティを考える上ですごく大事なことだなと思ったので、ちょっと文章化してみることにしました。 相談されたのは「新しい機能で直感的な操作を実現するためにドラッグ＆ドロップを使いたいが、アクセシビリティチェックをパスできない気がする」というような内容でした。たしかに私の会社で運用しているチェックでは、キーボードやスクリーンリーダーによる動作チェックを行っているので、それらではドラッグ＆ドロップの操作ができそうには思えません。 彼のこの相談内容からは「良いものを作ろう」

react-modalのアクセシビリティまわりの実装について、ソースコードを読んでみたかったのでその記録を残します。 特にことわりがない限り、 v3.11.2 の内容に基きます。 ドキュメント react-modalのドキュメントには accessibility という項目があり、3つの機能について説明があります。 The app element Keyboard Navigation ARIA attributes The app element 主にスクリーンリーダーのユーザー向けの機能で、 aria-hidden 属性によって、モーダルが開いているときにページコンテンツを非表示と同じような状態にする機能です。視覚的にモーダルウインドウがページコンテンツの上に被さるように表示されている＝ページコンテンツが隠されているのを、スクリーンリーダー向けにはモーダル以外の部分に aria-hid

はじめに 私はデザイナー兼フロントエンドエンジニアというような立ち位置で、勤務するfreee株式会社のアクセシビリティガイドラインの作成に関わったり、アクセシビリティまわりの仕組みの整備や社内エバンジェリストみたいなことをしています。 もともと私はWebアクセシビリティという分野が、重要なものである以上に技術や考え方として面白いと思ってやっているうちに気付いたら仕事で大きなウェイトを占めるようになってしまったタイプの人です。しかし、そうではない人たちにその重要さを説明したり、対応をお願いしたり、そのための資料を作ったりしているうちに、「やっぱWebアクセシビリティって難しいんだなぁ」と思うようになってきたので、それについて書いてみようと思います。 なお、背景を説明するうえで必要なので社名を出しましたが、あくまでこの文章は個人の見解であり、所属組織とは関係がありません。 誰のためにやるのかが

この文章について これは Front-End Study #3「『当たり前』をつくりだすWebアクセシビリティ」で基調講演をするにあたって、登壇内容を整理するために書いたものです。登壇内容とは一部に差異があります。 イベント映像 この文章はむちゃくちゃに長いので、登壇映像を見たほうがいいかもしれません。わたしの発表は13:23くらいから30分ちょっとです 登壇資料（内容は同一です） https://speakerdeck.com/ymrl/webenziniatosite-imazhi-tuteokitai-webakusesibiritei https://docs.google.com/presentation/d/1uhCvhh6sZCPUnReSBVDjvGfNAOTKbZ5Sxs8fYMlxMsI/edit?usp=sharing 目的 Web業界で「エンジニア」の肩書で仕事して