00:04
はい、10月15日土曜日ですね。
地獄は昨日もありました。
えー、本日の東京はちょっと曇りですけど、まあでも気温的にはそんなに寒くない。
まあ、ちょうど秋みたいな気温ですね。
はい、おはようございます。ひめみのkeethこと黒原です。
では、本日も朝活を始めていきたいと思います。
はーい、えー、今日はですね、タイトルがあります。
「プロトタイピング to learn」っていう記事ですね。
まあ、日本訳するとそのままですけど、
学ぶためのプロトタイピングっていう記事ですね。
読んでいこうと思います。
プロトタイピングの有用性とか、プロトタイピングの種類、役割、対象とすべき範囲など、
さまざまな観点からの利点を語られているそうなので、
それをちょっと読んでいこうかなと思っています。
はい、もしそれで時間がもし余ればですね、
なんか別の記事いくつか読みたいんですけど、
えー、まあ本当に技術的な記事も読みたいんですけどね、
ソースコードだらけなので、なかなか読みづらいなーっていうところもあって、
なるべく日本語だけ、日本語じゃですね、文章だけのものを読んでるんですけど、
もう一個、もし時間が余ったら、
ベタアクセシブルネームですね。
はい、まあそのままですね、名前の付け方の記事があるので、
こっちを読んでいこうかなと思っています。
はい、では本日も早速やっていきたいと思います。
プロトタイピングto learnですね。
市中郵政さん、おはようございます。ご参加いただきありがとうございます。
えー、プロトタイピングで学ぶっていうんですね。
サーキットブレーカーポッドキャストのボブとグレッグっていうのが
プロトタイピングという学問に言葉を送るということでした。
そうですね、はい。
まあこの記事自体は2022年の9月20日ですね。
先月、まあちょうど1ヶ月前ぐらいですね。
の記事だそうです。
ほい。
えーと、サーキットブレーカーポッドキャストっていうのがありまして、
まあそこのUnderstanding Prototyping to Learnというエピソードに出会いましたと。
で、一応このリンクも貼られてるんで興味ある方は聞いてみてください。
まあ多分英語だと思いますけど。
はい、でこのエピソードはマストリッスンみたいなぐらいですね。
そんなにいいやつだったそうです。
で、ボブ・モエスタっていう方とグレッグ・エングルっていう方が
ハードウェアや製造業の製品開発出身者だそうですね、お二人とも。
で、それらは全てウェブ上のプロトタイピングに当てはまります。
ボブとグレッグはプロトタイピングという学問に
必要な言葉をいくつか与えてくれています。
ボブとグレッグっていうのはそれらのために大きなバケツを持っています。
バケツなんだ。
私のバケツって書いてますもんね。
っていうところですね。
で、大きく分けて三つ書いてますね。
ラーニングプロトタイプとコミュニケーションプロトタイプと
マイルストーンプロトタイプの三つです。
はい、でこれらはプロトタイプが果たすべき役割を見事に分類をしていますと。
私はよく学習のためにプロトタイプを作成します。
へー、そうなんだ。
私のコードペンにはこのようなプロトタイプがたくさんあります。
いいな、これ見せる、見せないみたいな、教えないとか
シンプルでありながらとても効果的ですと。
で、バージョン1の隣にバージョン0を置くことでストーリーを伝えることもできます。
しかしブランチデプロイやコードペンのフォークを定期的に行うことで
03:02
このような状況に対応することができますよということですね。
最近、ちょっと余談に入りますけど
カジュアル面談させていただいたエンジニアの方ですね。
日本人の方ですけど
その方がとにかくビジネス観点がものすごく強い方で
フロントエンドエンジニアとして今は活躍されてるんですけど
同じことですね、プロトタイプを作ることが得意だと。
ゼロベースから立ち上げるときに
とにかく物を作って見せて
コミュニケーションをとって物事を早く進めていこうというところですね。
とにかくやっぱりフロントエンドエンジニアのところって
なかなかデザインがとかビジネス要件だったりとか
あとAPIとか仕様がとか
決まってやっと僕らも開発できるじゃんみたいなことがよくあるんですけど
それだとやっぱり遅いですし
そこまで待ってたら
後から後から手戻りとか調整の話をするのに
だいぶコミュニケーションとか時間がかかってしまうので
もう早く最初の要件とざっくりのデザインの
ラフぐらいとかカンプとかあると思うんで
その辺のレベルからプロトタイプを
フロントエンドだったら今ファイアベースとかあるじゃないですか
すごいファイアベースだったらお金もそんなに高くないし
それ使ってガリガリ一気にスピードよく早く
こういう物でか作りたいんですよねみたいなのを
どんどんどんどん実際に動く物を作って
見せていくっていうことを得意とされてる方がいたんですけど
まあほんとでもその方のおかげで
いろんなビジネスが生まれてたっていう話を聞いて
かなり熱いですし
このスピード感と熱量っていうのを
やっぱり今のフロントエンドエンジニアって
持つのがすごく大事だなと思ったんですね
技術がとかフレームワークが
それはもちろん大事なんですよね
そのソリューションとしてそういうツールとかを知って
それを実現するためのものとか
技術力を身につけとくってのはもちろん大事なんですけど
それを何のために使うかっていうところを
思いっきり体現されてる方で
めちゃくちゃモチベーション上がりましたし
やっぱ最後はそうやって
現実に還元していくことがやっぱ大事なので
フロントタイプっていうところの考え方は
今この読んでて思い出したなっていう感じでした
やっぱなかなかそうですよね
要件とかビジネスの話やっぱり加味したりして
いつ動くとかなかなか
初動ってフロントエンドエンジニアって結構遅かったりするんですけど
そこを逆にフロントからどんどん取りに行ってしまうっていうのは
いい観点だなっていうのはちょっと思ったっていう話でした
はいすいません余談です
では戻りますね
続いてのセクション
The types of prototypes
そうですねプロトタイプの
プロトタイプの種類ってことですね
ボブとグレッグはプロトタイプの種類と
それがどのように意思決定の促進材で
成り得るかっていうことについても探求してます
大きく二つですね
ディバージェントとコンバージェントですね
いわゆる発散型か収束型ってことです
発散型はいわゆる異なる方向性を探ります
収束型っていうのはトレード負を探りますということです
ポッドキャストで彼らが言ったように
発散型のプロトタイプっていうのは
人々が望まないっていうものを排除し
彼らが望むものの基準を構築するのを助けること
ってことですね
発散型プロトタイプっていうのは
コントラストを生み出しますと
リンゴとオレンジを比べることができる場所ですみたいな
06:02
収束型っていうのは
トレード負を最適化したり管理したりすることです
例えば軽さと強さみたいな
それをトレード負にすると
物を軽くすることはできますが
軽い素材っていうのはコストをかけなければ
一般的に強くはありませんと
お客様のニーズに応えるために
どのレバーを変えればいいのかっていうのを考え
特定の選択肢の間で収束させるんですよと
例えばそのA地点からB地点に行くというお客様の方に対して
発散型のプロトタイプっていうのは
飛行機だったり潜水艦だったり自動車を見せることになるでしょうと
収束型のプロトタイプっていうのは
プリウスだったりSUVだったり
ピックアップトラックなどを見せて
サイズや実用性と後、後続距離ですね
1ガロンあたりのマイル数とかを比較させることですと
っていうところの違いがありますよね
なんかわかりやすいですねこれは
最初から行くところは決まってたりするけど
行く手段そのものを変えるかどうかみたいなところと
全然比較が変わりますよね
これについて
ケンコセンダーさんですかね
ちょっと読み方あってるかわからないですけど
この方のiPhoneのキーボードの話っていうのを思い出します
一応この絵の別記事のリンク貼られているので
興味ある方は見てみてください
オークの発散型プロトタイプ
ひにくりもショックウェーブで作られた
発散型プロトタイプっていうのが
スティーブ・ジョブズの机の前を通り過ぎたんです
スティーブが道筋をつけると
ケンのチームは収束的なプロトタイプを作ることに反転をしたそうです
しかし通しまさかったので
必要なら手直しや後戻りも平気だった
ケンさんの言葉を借りると
デモは創造的な決断をするためのきっかけになりました
大きなキーでタップしやすいターゲットを作るか
小さなキーでソフトウェアによるアシストを加えるか
といった創造的な決断を早くすればするほど
その決断を洗練し改善する時間が増え
必要なら後戻りし可能なら前に進むことができるんです
っていうような言葉を引用してますね
さっきの記事のリンクからピックアップされている感じですね
まあちょっとここは
そういうなんか例えば一つのお話っていうところですけど
なかなかこれこれで面白いですね
iPhoneのキーボードの話は
結果iPhoneはキーボードをなくしたっていうか
ソフトウェアキーボードになったんですけど
ここの辺の裏話の一つがここで書かれてない
結構面白そうですね
あんまり僕ちゃんとそういう辺実は読んだことなかったので
気になったので明日以降これ読んでみようかな
はい思います
続いてThe Dimensions of Prototypesです
プロトタイプの次元だそうですね
プロトタイプは一様ではなく
時には異なるスコープや次元から問題を見ることができます
包括的なプロトタイプ
多くの側面がどのように組み合わせるかを検討します
あとフォーカス的なプロトタイプですね
一つのアスペクトに焦点を当てて最適化をすると
この2つのディベンチョンがあるようと言ってますね
包括的かフォーカスをするかということです
顧客は全ての部品
または複数のプロトタイプがどのように組み合わせるかっていうのを見るために
より包括的なプロトタイプを必要とする場合があります
09:01
またプロトタイプっていうのは特定の機能またはコンポーネントにズームインすることができます
それぞれの次元で根本的に異なる質問を投げかけますが
BobとGregもそれをカバーしてますよと
コンポーネントにズームインするのは確かにあるかもしれないですね
続きまして
Questions you should ask from your prototypeだそうです
プロトタイプに求めるべき質問だそうですね
良いプロトタイプは質問に答えるのに役立ちます
BobとGregが考えた質問っていうのは次のようなものでした
主に4つの質問ですね
どんな質問に答えようとしているのか
なぜそれをやっているのか
誰のためのものなのか
そこから何を学びたいのかっていう4つの問いでした
私がこれを引用するならば全てを煮詰めます
煮詰めるんですね
あなたが知るべきことは何ですかっていう1つの問いに集約をしてしまおうと
あなたが知るべきことは何ですか
物によっては急遽終了することもありますよねってことだそうです
それもありがちですよね
続いては
Is AB testing prototyping?
ABテストはプロトタイピングなのかっていう問いですね
この番組ですね
番組の最後に私が時々疑問に思うことを質問しています
ABテストっていうのはプロトタイピングの1形態なのでしょうかっていうのが問いですけど
彼らの答えはこうでしたってことです
私が育った世界ではABテストっていうのはプロトタイピングの中でも最悪のテスト方法として知られていました
ははー
プロトタイピングという世界の中ではABテストっていうのは最悪のテスト方法なんですね
これは興味深いお話ですね
So Spicyっていうふうにいきなり書かれてますね
私はABテストについて多くの考えを持っていますが
っていうところで1つの別の記事のまたリンクが貼られてますね
一般的にはツールベルトの中の1つのツールとして一応見出してはいます
ABテストの大きな問題点として
なぜそれがうまくいくのかがわからないから破綻するというニュアンスには大賛成ですと
数字が上がったから出荷しようっていうのはプロセスの指針にはなりません
理由を知る必要があるのです
定量的なものABテストと定性的なものユーザーテストの両面が必要で
並行して情報を提供し合う必要がありますと
数字が上がったから出荷しようというのは指針にはならないが確かにおっしゃる通りですね
その数字がそもそもビジネスに沿っているかとか
エンドのことに沿った答えなのかみたいなところの検証まで全然できてないと思うので
ただ単に数字が上がったっていうのは何となくよくわからなくなりますし
そもそもなぜABテストするのかみたいなところ
根本的なものを見ないままとりあえずやってみるがよろしくないなと思うので
ビジネス的には考えたほうがいいと思います
書いてある通りですけど定量的と定性的でちゃんと2つの両面で考えていくっていうのは
それは全然いいんじゃないかなと思いますね
あともう一つですね私自身のニュアンスを付け加えると
12:02
ABテストは少なくともデジタル分野においては
実際の顧客とラボの他でプロトタイプやアイデアを素早く検証するための
素晴らしい方法であるっていうのを主張しておきたいです
うまくやればデザインに関する主張を排除したり
経営人のビッグアイディアっていうのを抑制したりすることができます
私が好きなABテストは実は失敗するテストだという風に言ってます
好きなABテストは失敗するテスト
なぜならアイディアが悪いアイディアかどうかっていうのを早期に発見できるからです
しかし組織には茶葉を読みなぜ失敗したのかを記録できる人には必要ですよと言ってます
この辺海外の方の突然出てくる例えがよくわからないですね
茶葉か茶葉を読むっていうのはよくわからなかったです
なぜ失敗できるのかっていうのを記録できる人は必要だというのは完全に同感です
さっきの剣士の言葉を再びお借りしようと思います
ABテストというのはより頻繁にリンクをクリックしてもらえるような色を付けるということには有効かもしれませんが
全体として心地よく統合されていると感じられるような製品を生み出すことはできないのです
総合的なプロトタイプを作るのが良さそうですねということでした
これもまた興味深い一言ですね
確かに頻繁にリンクをクリックしてもらうとかそこにフォーカスを当てたいとか
ユーザーをそこに促したいみたいな変更をつけるためには有効かもしれないですけど
心地よさですね全体としてサービスだったりプロダクトの体験っていうところの心地よさっていうのを
統合されていると感じるような製品にはなかなか生み出すことができないよっていう風に言っているのは
ビジネスはやっぱり難しいですね
ABテスト自体が悪い手法というわけではないですけど
やっぱり使い方とか用法要領っていうのはやっぱりあるんですねということでした
じゃあ最後
So much to learn from prototyping でした
プロトタイピングから学ぶことはたくさんありますということですね
プロトタイプはあなたの製品について多くのことを教えてくれます
どこに行こうとしているのかどこに行ったのか何が変えられるのか何が変えにくいのか
どんな問題が発生するのかそして最も重要なことは
そこに到達した時顧客はそれを気に入ってくれるのかということです
私はプロトタイプが好きでそれについてよく話しますが
このエピソードから多くのことを学びました
他の業界からこれらの洞察はプロトタイピングに多くの言語構造そして目的を与えてくれます
優れたプロトタイプは意思決定を加速させるコントラストを生み出します
私はいつもプロトタイピングの楽しさや
大企業の機械の外にあるアナーキーな問題解決に焦点を当ててきたと思いますが
ボブとグレッグはプロトタイピングをボタンアップシャツにして
顧客の問題を解決してビジネスを行う準備ができているんですよということでした
ボタンアップシャツというところがまた面白いなというか
海外の方って本当に詩人の人が結構多いなというふうに僕は思ったりしました
文化かもしれないですけど
ということで締められていますということでしたね
15:00
プロトタイプについてこんな色んな側面だったり観点から見るというのは
僕はやったことがなかったのでとても興味深かったですし
改めて学び直すなというふうなことを思いましたね
というかしっかりプロトタイプを作っていきたいと思いましたね
よく新しいものを学んだりするとかツールとかをキャッチアップする時も
適当にトゥードゥリストだったりとかブログ的なものを作ったりしますけど
というよりももっとビジネス的なもの
インパクトありそうなものとかを作る方が良さそうだなという気はしましたね
それをいかに高速的に作るかという
プロトタイピングをするための訓練とか練習も日々やっていく方が
やっぱり技術力が身につくんじゃないかなというふうには思いましたね
チュートリアル結構公開されているので公式のやつがね
それをやるのも別に良いと思いますけど
またやっぱり本当に現場ビジネスの現場におけるプロトタイプっていうのは
戦略とかどういう方向に行くとかというか
どういうブラッシュアップ改善サイクルをするのかっていうのも
戦略練って作るっていうのがやっぱり大事だと思いましたね
プロトタイプが大事なことはよくわかったけど
じゃあそれをやみくもりばって作るっていうのも
作ることは別に構わないんですけど
作ったものをどう使うのかっていうところがないと
時間の無駄だったりするっていうのがやっぱりあるので
プロトタイプの役割と対象と
あと様々な種類とっていうところの話を加味して
導入していくのがいいんだろうなというふうなことでしたね
とても個人的には参考と学びが多いなっていう記事でしたね
というところで残り時間
あと8分くらいあるんですけど
もう一個のほうですね
短いのでサクッと読んでいきましょうか
ベタアクセシブルネームズですね
アクセシブルな名前をつけるためには
どのような観点で考えればよいのか
っていうところについて解説をしていくということでした
というところで早速やっていきたいんですけど
何でか知らないけど
ディープエルが日本語に翻訳をしてくれない
maybe you have used aria-labelですね
おそらくaria-labelとかラベルタグだったりとか
some other way to name controlですね
他の名前のコントロールをされているとは思いますよと
now you wonder what makes a name good, effective or useful
ただこういうことに今あなたは悩んでいると思われるということですね
どんな名前が良いというのか
もしくはそのエフェクティブ効果的なのか
またはユースフルで使いやすいのかっていうところですね
というところに今名前付けで悩んでいるんじゃないですか
みたいな問いを投げられています
以前アクセシブルネームっていうのが重要な理由と
どこにつけるかについて書いてみました
そういう記事が別の記事のリンクに貼られてますね
why accessible names matter and where to add themですね
というような記事を書いているので
これも興味があったら見てみてください
今回は実際の名前をよりユーザフレンドリーにする方法について
説明します
これらのヒントは全て私が大好きなあまり評価されていないコンテンツ
なるほど
18:00
アクセシブルとかアリアラベルとかその辺の話って
この方は大好きだそうですけど
なかなか世間では評価されていないというコンテンツだそうですね
アリアオースイングプラクティスガイドの
コンポーズイングエフェクティブアンドユーザフレンドリーアクセシブルネーム
っていうタイトルの記事があるので
そのセクションから引用しています
全てのクレジットは著者に帰属し
私は文脈と例を追加しただけですよという風に言っています
では入っていきましょう
ファンクションオーバーフロー
フローじゃないオーバーフォームですね
形より機能だと言っています
アクセシブルネームっていうのは支援技術によって
ウェブ上のものを参照するために使用されます
例えば音声コントロールを使用している場合
特定のコントロールのアクセシブルの名前を言って
それを起動させることができます
スクリーンリーダーを使用している場合は
コントロールに到達したときあるいはコントロールのリスト
表示上のリンクのリストなどを表示するときに
読み上げられる名前ですよと言っています
アクセシブルな名前を使用するため
機能的な名前にし
コントロールがどのようなものかというのを示す
名前をつけるということはやっぱり避けたいものですよね
理想的なのはあるものが何をしようとしているのか
すぐに把握できるような命令系の名前をつけることです
命令系の名前をつけることですね
で、エグザンプルがありますね
エグザンプル3つですね
1つ目はハンバーガーよりも
オープンナビゲーションとかケバブよりも
その他のオプションの方が効果的ですよと
あとは次のスライドはとか
右矢印とかですね
いわゆるネクストスライドじゃなくて
アローライトとかですね
もしくは
ライトポインティングトライアングル
右向きの三角形とかですね
そうです
というのがそのライトアローとか
右向き三角形よりも次のスライド
ネクストスライドの方がより効果的ですと
最後は
セーブドキュメントワークスベター
ザンフロッピーディスクですね
フロッピーディスクよりも
ドキュメント保存という方がやっぱり有効ですよ
という名前の話ですけど
それは確かにそうかもしれません
僕らはアイコンとか見て
フロッピーディスクって保存なんだろうなというのは
見りゃ分かるんですけど
でも普通に考えてフロッピーディスクじゃなくて
セーブドキュメントという方が
それは分かりやすいですよね
次に
最もユニークな部分を
最初に持っていきましょうみたいなことです
ボタンやリンクなどの一連の名前では
最もユニークな部分から始めます
そうすることでより簡単に区別することができますよ
例えば
たくさんのアルバムをリストアップしているような
リストページがあるとしましょう
それぞれの名前にアルバムを含めるとします
この場合
アルバムミッドナイトマローダーズとか
アルバムトゥーピンパーバタフライ
ではなく
マローダーズアルバムとか
トゥーピンプーバタフライアルバム
などと表記します
固有の名前を先に持ってきた最後に
アルバムを付けると
あとORが続きますね
または
リンクのためのアクションがありますと
リンクの編集もしくはリンクのコピー
21:00
リンクの共有とかよりもリンクの編集
リンクのコピーリンクの共有の方が
ちょっと待ってよちょっと待ってよどういうことだ
OR you have actions for a link
edit link copy link and share link
work better than link edit
link copy and link shareはいわかりました
ということですね
これも一緒ですね後ろにリンクを付ける方が
やっぱり効果的ですよねってことを言ってます
了解ですこれはウェブページの
タイトルにも当てはまりますともしタイトルの
中で会社名を繰り返している
ならばそれを最後に残してそのページ
についてユニークなことを最初にリストアップ
しましょう技術的にはアクセス
可能な名前ではありませんが同じ命名上の
アドバイスが一応適用されます
とはいえ最後にリンクとか付けてるから結果アクセス
はできると思いますよね
で続いて
ビーコンサイズですね
ビーコンサイズ簡潔であること
ってことはそうですけども
keep a name of the most important one or three
words preferred
by brevity
名前っていうのは最も重要な1から
3、5程度にとどめておいて
簡潔さっていうのを優先しましょうと
長すぎる名前はどうなのかって
やっぱ思いますよね
iOSで昔オブジェクティブ
シーンで僕一応書いたこと若干あるんですけど
まあオブジェクティブシーンの
メソッド組み込みメソッドは名前
長すぎて正直わからんってずっと
思ってましたからね
で続きます
no roles as part of the name
名前の一部としてロールを使わないように
しましょうというところですね
で
この長文を
日本語に頭の中で翻訳しながら
読むの大変ですけどでも翻訳されないんで
頑張っていこう
the things that have names in your page
will or should have roles too
ですね
物事っていうのは名前を持っています
あなたのページ上で名前を持っています
will or should have roles too
さらに名前を持っているし
ロールも持っています役割も持っていますよ
と言っています
で
the browser will should
ここは翻訳された
ブラウザーはあなたが明示的に設定した場合
例えばロールイコールボタンみたいなのですね
指定した場合もしくは
要素に無料で付属している場合
例えばボタンみたいなやつですね
確かにボタンタグはそのまま名前がついていますね
その場合はあなたに代わってロールを導き出してくれます
と
確かにそれはそうですね
もしあなたがロールを指定する場合は
for instance the word button
例えばですね
ボタンっていう名前を
例えば付けた場合ですね
to the name that is redundant
僕がわからない単語が出ました
and this can be anything
for users
そういう名前というのは
冗長であってもユーザーにとっては迷惑な話ですよ
という風におっしゃっていますね
例えばですけど
exampleでもできますね
3つあります
use close instead of close button
クローズボタンの代わりに
クローズっていうのを使うとか
もしくはuse main instead of main nav
メインナブの代わりに
メインを使うとか
use main instead of save button
24:00
セーブボタンの代わりにセーブを使うとか
なるほどでした
こういうのは結構冗長だったりするところですかね
続いて
keep names unique
行きましょう
名前をユニークにってことにしましょう
あなたが学校で働いていて
生徒の名前が全員アリスだと想像してみてください
いやだな
これはページ内のコントロールや
コンポーネントの名前についても同じで
特にページを閲覧するために
ユーザーにとっては大変なことでしょう
でもアクセシビリティの観点で
全部同じ名前だったらそれは辛いよね
例を挙げましょうということで3つですね
今回の例は2つですね
もっと読むリンクっていうのを
持つニュース項目を
表示する概要ページではなく
各ニュース項目のタイトルを
リンク名として使用しましょうとか
あとはここをクリックしてください
みたいな言う代わりに
リンク先のページ名を使用するなどですね
例えばこちらもご覧ください
これは分かりやすくていいですね
というところで
またもっと読むとか
ここをクリックしてくださいっていうのは
さっき言った全員がアリスと同じ名前ですよね
みたいな結構例としては
分かりやすいですね
ではなくてそれぞれのオリジナルのコンテンツの
名前にしましょうというところでした
続きまして
次ですね
文は名前ではないっていうやつですね
に入ります
ドキュメントの最後のヒントは次の通りです
ファインダーで発音しやすくするために
名前は大文字で始めましょうと
名前は文ではない
フィリオードで終わらせないようにしてくださいと言ってます
これがこのヒントが最初に言及した
タイプであるかどうかでは分かりませんが
アクセシブルな名前のセットの例として
次のようなものがありますと
その3つ
3つかな例として
今回の3つはないですね
そのままいきますね
タイトル説明および画像があって
全体としてクリック可能で実装されているカード
全てを一つのA要素でラップします
私はこれを
いろんなところで見たことがあります
長すぎて紛らわしい名前が作成されるため
しばしば問題になりますよね
代わりにこれを行うことをお勧めします
より便利なそして簡潔な
名前の文字列を選んで
それをAにします
次にクリック可能性の問題を
CSSで解決しますと言ってますね
雑に全部Aタグでガーンって挟むんじゃなくて
ちゃんと個別な
便利なところとか
アクセスしないところにAタグを置いておいて
それ以外のところのクリック可能性は
CSSでカバーすると
これはでも確かに実装者としてできることだし
これは確かに僕らもやっていきたいなと思いましたね
はい
ラストですねラッピングアップですね
ラップアップってやつですね
最後まとめ最後にですね
名前を提供するためにARIAを使用する
必要性はないということを保証したいと思います
例えばこの情報が
ARIAオースティングプラクティスの一部であっても
だとそうです
HTML要素例えばラベルレジェンドキャプション
ボタンAみたいですね
などなどのテキストコンテンツは問題なく機能します
追加の利点っていうのは
これらのHTML要素で目に見える名前を提供すると
支援技術を使用していない人や
支援技術のユーザーと
27:00
協力している人々を含む
より多くのユーザーがそれを使うことができるようになることです
はいはい
これで全部ですよと言ってました
前日のようにこれらのヒントっていうのは
W3CのARIAオースティングプラクティスでの
効率的で
ユーザーフレンドリーなアクセス可能な名前を
作成するからのものですね
その特定のページには
さらに多くのヒントがあり
アクセス可能な説明だったり
名前と説明の計算だったりとか
名前が必要かどうかっていうところの
役割ごとのガイダンスっていうのを
あとは多くの落とし穴っていうところも書いてあるそうですね
というのでそういうのを説明してあるので
見てみてくださいってことでした
素晴らしいネーミングをしていきましょう
っていうところで
この記事が締められています
W3Cオースティングってところで締められているのが
タイトル通りでいいなって思いました
名前については本当にね
前からもずっと意識していけない
こういうのも細かいですけど
技術力だなっていうのは僕は感じたりしますね
というところで
今日の記事 朝勝田終了したいかなと思います
ちょっと途中
グダグダしてしまって大変に申し訳なかったですけど
今日も頑張っていけたなと思います
後ほどこの2つの記事のリンクは
共有しますので
Twitterで見てみてください
では
朝勝田終了したいと思います
今日はしゅうりせんさんですね
ご参加いただき大変にありがとうございました
休日一発目のんびり過ごしていただければなと思います
では終了したいと思います
お疲れ様でした
