コミュニティのハイライト: Olutimilehin Olushuyi

Olutimilehin Olushuyi さんは弁護士ですが、ユーザー補助については経験がありません。また、JavaScript との戦い、国際標準、ウェブサイトのコンテンツを読み取ることの重要性についてお話ししました。

この投稿では、ユーザー補助機能について学ぶの一環として、コミュニティ エキスパートを取り上げます。

Alexandra White: ウェブ ユーザー補助をどのように使い始めたのですか?

Olutimilehin Olushuyi さんの顔写真。

Olutimilehin Olushuyi(Shuyi): なるほど、それは面白い話ですね。私は弁護士です。 最終年度に、私は生涯にわたって法律の仕事をやりたくなかったことに気づきました。学校を中退しようとしましたが、学部長であり「学校の母」である Ayodele Atsenuwa 教授はこう言っています。最後の 1 年は、最後までやり遂げましょう。」

最終的には彼女がそう言ってくれてうれしいだけでなく、私のユーザー補助作業に役立っているので、完成したこともうれしく思います。代わりに何をしたいのかを常任教授から聞かれましたが、まったくわかりませんでした。

私は新しいキャリアの機会について探し始め、スタートアップを立ち上げたい人や弁護士を必要としていた人と連絡を取りました。この機会に適していませんでしたが、私たちが使用しているすべてのプロダクトのコードを記述していると知ったのは、そのときが初めてでした。「これを買っていいか」と思いました。HTML と CSS について独学で学び始めましたそれから JavaScript に入りました...[笑] JavaScript は JavaScript のことをやっていたので またフロントエンドのセマンティック言語に重点を置きました

私は、Andy BellHeydon Pickering の仕事を見つけました。すべてのレイアウトを購入して、人生が変わりました。Andy がユーザー補助機能に言及し続けましたが、この文脈でそれが何を意味するのかわかりませんでした。JavaScript の記述方法を知らなくても、ウェブ開発の仕事ができることに気付きました。

Heydon に問い合わせたところ、親切かつ丁寧な対応をしてくれました。ユーザー補助の分野に携わる誰もがそのように思えるので、私は感謝しています。

Alexandra: 私も確かにそのとおりです。私が話した皆さんはとても親切で、助けてくれてくれました。

Shuyi: もちろんです。現在は、支援活動により多くの仕事をしています。私はナイジェリアを拠点としています。ナイジェリアは、ウェブ アクセシビリティが法律で義務付けられていない国です。2018 年、障害者差別法が可決されました。しかし、ウェブ アクセシビリティに関する法律はなく、物理的なアクセシビリティに関する法律があるだけです。米国の障害者法(ADA)のようなものです。私たちの法律は構造化されていませんが 何もないよりはいいものです

私は違いを生み、ユーザー補助を重視するデベロッパーになるチャンスがあると気づきました。まず、エコシステムにユーザー補助のニーズを認識させる必要があるのです。私はユーザー補助の擁護に関するツイートを開始しました。私は、仕事でユーザー補助機能を利用するために同意が必要な企業やブランドに話を聞きました。

Alexandra: ユーザー補助に取り組むうえで、あなたの法的バックグラウンドがきわめて役立つことでしょう。新しい法律を読み、一般の人々には理解できない方法で理解することができます。平均的なデベロッパーも 1 人います。

Shuyi: 私の法的経歴から得られる最大の贈り物のひとつは、終わりのない背景資料や長いドキュメントを読むことができる点です。脚を折りたたんでノートパソコンを掲げて、読書を始めました。読書。読書。これには長所があります

Alexandra: そうですね。いいスキルですね。政府と協力して、デジタル アクセシビリティに関する法律の可決を求めることはありますか?

Shuyi: 正直そうとは思いませんが、政府と関わることは、別のボールゲームです。政府に何かをしてもらうには 特に個人として 時間がかかりすぎるからですこのような活動は、変革をもたらす人材やリソースを持つ NGO などの組織にとって望ましいことです。

物理的な法律の制定には多くの時間がかかり、ユーザー補助は数年前の法律で定められた範囲をはるかに超えるものでなければなりません。世界は変わったのに 最初の草稿は通過したみたいだね

結局のところ、どれだけ古くても、頼れるものがあることを私たちは嬉しく思っています。執行すべき法律がある。

アクセス可能なレイアウトを作成する

Alexandra: Smashing Magazine の記事「<article> vs. <section>: How To Choose The Right One」と、その記事に影響を与えた Twitter スレッドを読みました。ウェブ デベロッパーに求める重要なポイントを 1 つ 挙げるとしたら何でしょう

Shuyi: デベロッパーは、レイアウトのビルドを開始する前にコンテンツを読んでおく必要があります。

もともとサイトのデザインでは、あまり深く考えずに段落の数を数えて、セクションや記事にまとめていました。しかし、セクションの悪用に目が留まりました。そのことを考えたのは初めてです。コンテンツを読むことはより良い製品を 作り出すための 1 つの行動です

Alexandra: 私がデベロッパーだった頃、フリーランスのクライアントに「あれ、何か作ってくれたら、あとで補うよ」と言われることがよくありました。お問い合わせページのように 自動的にコンテキストが表示されるページもありますしかし、構築するページ数や必要なカスタム サポートの種類がわかっていた場合は、コンテンツを入手した段階でしか回答できませんでした。

Shuyi: 私が知っている前に、優秀なお客様から一般的な設計のアイデアを教えてもらい、たくさんのダミーテキストを使ってサイトを構築しました。いろいろと調べてみます。しかし、ウェブ上にコンテンツ インフラストラクチャが及ぼす影響がユーザーに及ぼす影響を知れば、ウェブで何かを構築するための標準的なプロセスには、実際にはどれほどの欠陥があることに気付くでしょう。ものは意識して構築しなければなりません。

ユーザー補助インフラストラクチャ関連の取り組みがあっても、まったく注目を集めず、心が痛くなります。

Alexandra: 記事で述べたアドバイスが正しいかどうかを確認するために、どのように調査を行いましたか?

Shuyi: まず、情報源を分離しました。これは法律で行われていることであり、一次情報源と二次情報源を分けています。一次情報源は実際の法律(ADA やナイジェリアの法律など)であり、二次的な情報源は、専門家が法律から解釈するものです。

主な情報源である HTML、WCAG、WAI-ARIA の仕様のみを参照することにしました。他の方の作品もたくさん読みました。結局のところ、意見は多岐にわたるため、私はそれらを有用なコンテキストとして捉えることができ、正しい答えを導き出しているとは信頼できないと判断しました。

誰もが利用しやすいコミュニティを構築する

Alexandra: Twitter のフィードをユーザー補助機能に変えようとしているとおっしゃいました。「Smashing Magazine」の記事が発表されて以降、X(旧 Twitter)でさまざまなやり取りをしましたか。

Shuyi: 最初の数日間は、Twitter の意味がよくわかりませんでした。200 人を超えるなど、多くの人が私をフォローしてくれました。最初はワクワクしましたが、 するとこわくなりました。私は出だしたばかりで、賢い知恵をためらってはいけません。たくさんの Twitter リストに追加されていました。

でも、私は人間なのよ。あいまいでバリアフリーでウェブ開発者に限らず 多くのことをツイートしています人をがっかりさせたくない。ユーザー補助機能を理由に 私についていくのはやめておきましょう失望しそう。

Alexandra: [笑] そうですね、多くの人がそう考えています。Twitter のペルソナは大事にしています

Shuyi: 記事自体へのほとんどの回答が肯定的でした。その記事に対する返信は 1 件ありましたが 物議を醸す内容でした私の編集者である Vitaly から直接コメントをもらい、調査を依頼しました。結局、この担当者は、すべての記事には見出し要素が必要であるという MDN のドキュメントを参照していました。仕様に基づき、セクションには見出し要素を含めることを推奨しました。

MDN のドキュメントではヘッダーを含めることが推奨されていますが、そのメリットは実際には説明されていません。

もちろん、仕様を変更する頻度はユーザーのニーズよりも低いため、ビルド方法を変更する決断を裏付けることができさえすれば、おそらく大丈夫です。

例を挙げましょう。3 つの要素を含む「Prices」という カードコンポーネントを作成しているとしますHayden Pickering は 各カードを リスト要素に入れることを提案します支援技術(AT)を使用しているユーザーがこのセクションに移動したときに、価格リストに 3 つの項目があることが通知されます。リストのスタイルは箇条書きがないように設定することもできますが、AT ユーザーが有用な情報を最初に確認できるようになります。各アイテムを div でラップすると、視覚のみが重視され、視覚障がいのあるユーザーには役立ちません。デザインの前に人物について考える。

そのアイデアをもとに、ブログページにしました。ブログ投稿は実際にはリスト要素内にあります。これにより、ユーザーがページにアクセスしたときに、そのページにある複数の投稿のいずれかにアクセスしていることが通知されます。

記事の推奨事項は、MDN が推奨する理由が理解できるまで継続します。

Alexandra: MDN のドキュメントはオープンソースです。そこで変更を提案し、更新を行いますか?

Shuyi: 正直言って、私はまだオープンソースの貢献をしたことはありません。私はこのような仕事をしたいと思っていますし 政府との連携だけでは不十分です

仕様と実装

Alexandra: 仕様には 1 つのことが示されていることもありますが、実装や他の外部ドキュメントでは別のことをするよう提案されているかもしれません。誰のアドバイスに従うかは、どのように決められるのでしょうか?

Shuyi: この件についてはよく考えます。その質問に答えるだけの 経験が自分にあるかどうかわかりませんGoogle は常に、将来を見据えた努力を続けています。ウェブの変化に合わせて継続的に機能を強化することをおすすめします。そうすることで、仕様が更新されてもサイトを改良する必要がなくなります。選択を迫られる可能性や、3 年後に仕様が変更される可能性はどの程度ありますか。

今私たちが行う選択はすべて、ウェブの未来がどうなるか、仕様作成者がどのような方向になると思うかについて、最善を尽くした答えです。

Alexandra: ウェブは絶えず変化しているため、1 人の人がすべての答えを知ることはできません。執筆中に仕様を変更しましたか?

Shuyi: ドキュメント概要モデルが仕様から削除される前に、記事の作成を開始しました。このモデルでは、ネストの深さに基づいて見出しレベルが自動的に計算されることが提案されていました。しかし、これは実際には実装されておらず、デベロッパーに多くの問題を引き起こしました。デベロッパーへのアドバイスは、見出しを手動で修正することでした。

仕様変更前に記事が公開されていたとしたら、おそらく戻ってその記事を編集して、Smashing Magazine に掲載されたことでしょう。しかし、もし個人のブログにあったらどうなるでしょうか?おそらく、そうではありません。これは記事を更新するだけであり、仕様の変化に応じて構築されたウェブサイト全体を更新するわけではありません。

仕様が変更された場合、デベロッパーは直ちにウェブサイトを変更する必要がありますか?答えはもちろん「ノー」であり、サイトを構築する際に何が最適かを計算し、その選択を受け入れます。仕様が変わっても その仕様には答えがないこともあります

キャリアとしてのユーザー補助

Alexandra: 世界的なユーザー補助基準の検討にどれくらいの時間を費やしていますか?基準や法律は国によって異なります。いろいろとお読みになっていると思いますが それとは逆のことをするよう指示されている法律もありますそのような場合はどうすればよいでしょうか。

Shuyi: 私は、フリーランスのユーザー補助関連業務のビジネスを立ち上げることを検討しました。私はグローバルなウェブ ユーザー補助チャット チャンネルに入り、利用を始めるためのヒントを尋ねました。Adrian Roselli さんから次の連絡がありました。「クライアントは、重大な結果をもたらす可能性のある法律を遵守し続けるために、あなたに依存しています。サービスを提供する前に 自分がどのリージョンで専門知識を持っているかを把握しますよく知っている法律を知り、自分自身で生計を立てながら、クライアントに多額の負債を残さないようにします。彼らは法律を知っていると信頼しているのです。」

当然のことながら、多くの企業がユーザー補助の支援を求めているのは、ユーザー補助が法律で義務付けられているからであって、それが正しいからという理由だけではありません。ユーザー補助が実装されている理由は 資本主義にあります結局のところ 問題の発生原因は問題ではなく プロダクトにアクセスできることが重要になります

クライアントの地域の法律について確実にサポートできると確信が持てるまで、フリーランスの活動は控えます。標準化は極めて重要であり、WCAG の取り組みと影響は計り知れません。ウェブのあり方に関する中心的なフレームワークを持つことで、政府も同じ基準に頼りやすくなります。もちろん、すべての政府がこうした基準を受け入れるわけではありません。

Alexandra: ユーザー補助機能について、多くの素晴らしい人々から多くのアドバイスをいただいています。キャリアを積む前に 他に受け取ってほしい アドバイスはありますか?

Shuyi: 私のキャリアは変わったと思いますが、ユーザー補助に関する仕事と同じくらい尊厳ある仕事は、資本主義の影響を大きく受けていると知っていたらうれしいです。

Alexandra: [笑い] そうですね。

Shuyi: 私は 3 年生です。ユーザー補助機能に関して 1 年の経験があります。特に、私のようにアフリカを拠点とする社員の場合、ユーザー補助の求人は限られています。企業は採用担当者を 1 人で 雇用していますチームで仕事をしてスキルを身に付けたいです。

JavaScript を学ばなくても、ルールを学んで、チームがルールを適用するのを手伝うことができたのはとても刺激的でした。一方、代理店の開発者には JavaScript の経験が欠かせません。新しい都市に引っ越し、JavaScript ブートキャンプに参加して 要件を満たせるようになりました。ユーザー補助に取り組むすべての人にとって、まずは開発スキルの構築に集中する必要があることを覚えておいてください。

嘘をつくつもりはないけど、JavaScript は好きじゃない。

1 つの操作: キーボード フォーカスを追加する

Alexandra: [笑] 私がデベロッパーではなくテック ライターになった理由は JavaScript なのでしょうか?はい。はい、大嫌いです。ブートキャンプでのご健闘を祈っております。

サイトにアクセスしやすくするためにデベロッパーに行ってほしいことを 1 つ挙げてください。

Shuyi: キーボード フォーカス。私は心の底から物をねだっている。今はトラックパッドが使えないので、外出中はキーボードでウェブを操作していて、ほとんどのウェブサイトが使いづらい状況です。キーボードのフォーカスは 障がいのある人にとって有益ではありません

誰にとっても使いやすいプラットフォームを構築するには、


Twitter で @shuyiolutimi の Shuyi の最新情報をご確認ください。