a11yやユーザビリティまで手が回ってないということについて
#a11y
スタートアップにおけるアクセシビリティはプロダクト品質と速度への投資
多くのプロジェクトがソフトウェア的でない、いわゆる製造業的な考え方の延長線である
---
@cubbit2: アクセシビリティ、正直私はまったく手が回ってないです
余裕があればやりたいのですが、実装する側も知識は足りないし、顧客がそこに必要性を求めてくれないとどうにもならないところがあります
優先順位としてはどうしても最後のほうになってしまうし、そしてその順番は決して回ってこない……
同じくkoushisa.icon
@takepepe: 情報提供側として、提供したい情報を、意図通りの情報構造で提供するため（デザイン通りに画面実装するのとなんら変わらないという認識）
@ymrl: お金の話ではないけど、QAプロセスにa11yチェックを組み込んだら、これまで「挙動になんか違和感あるけど機能要件は満たしているのでスルー」とされていたような、微妙な不具合未満みたいな事項が、a11yの観点でバシバシ指摘されるようになったりしました #uit_meetup
@VoQn: 自分も今じゃStyledComponentベースでCSSは書くようになっちゃったけれど、CSS Modules にしろ CSS in JS を無批判に称揚してるエンジニア諸氏に「UsserStyleSheetを一切書けないような仕組みにしちゃってるコトに対してジレンマ覚えてないんか？」みたいな鬱屈した感情は持っている
@VoQn: ちゃんと一度は時間とって考えてほしいんだわ。
「これが本当にユーザビリティやアクセシビリティを考慮したアウトプットか？？？」
https://pbs.twimg.com/media/EjmO2BvU8AAYtCk.jpg
たしかになぁ、耳が痛いkoushisa.icon
#CSS_in_JS #CSS
@mizchi: これを復活させるためにはアクセシビリティのUI抽象モデルを開発者側に露出させて、外部から操作できるようにする必要があると思ってるけど、vscode とかがそうなってるが拡張可能なコマンドシステムというのが実装が難しい
---
見落とされがちだけどform, inputタグ本来の機能をどれだけ活かせるか、は大事な指標だと思うkoushisa.icon