個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお
まとめ 住所フォームの作り方 住所フォームを作るときには以下の4つを押さえましょう。 オートコンプリート機能に最適化する 郵便番号フィールドは1フィールドにしてハイフン有無どちらも対応する モバイルUX優先なら郵便番号が入力されたら即座に補完。精度優先なら郵便番号補完ボタンを設置 住所フィールドは「都道府県」「市区町村」「町名以下」の3フィールドが基本。「建物」フィールドはオプション 本文 地域SNSのユーザー登録、ECサイトの配送先入力、資料請求、自治体サイトでの電子申請など、ウェブサービスを活用する上で住所入力は欠かすことができません。 住所入力をシンプルかつ正確に行えるような入力インタフェース（住所フォーム）は、離脱率を減らし、コンバージョン率を向上させる上で重要です。 郵便番号を入力すると対応する住所を自動入力する機能（郵便番号による住所補完）は、住所フォームの改善方法として最も効
「SEO に強い HTML の書き方」というツイートがそこそこバズっていて、その内容に対して駆け出しエンジニアの方たちが「参考になった」などと称賛の声を挙げていたのを見かけて思うところがあったのでこの記事を書きました。 元ツイの概要は次の通り。 body > main > article > sectionに h1は 1 ページに 1 つ（要キーワード） 見出しタグは毎度 section で囲む ヘッダーメニューは nav で囲む 画像に適切な alt を設定する title / description を書く 階層を意識して書く div はあまり使わない 画像は p で囲む この記事は元ツイおよび元ツイの投稿者を批判する意図で書いたものではなく、あくまで挙げられている内容に対する個人的見解をまとめたものです。 正しいか正しくないかをそれぞれの項目のはじめに書いていますが、あくまで僕個人の
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog TL;DR:2022にフロントエンド開発で最も考慮すべきユーザー環境は、パフォーマンスでは低スペックのAndroid端末、標準仕様では2年前のSafari、そしてネットワークでは４Gです。それに対してはJSへの過剰依存などが原因で主にパフォーマンスの面でのウェブ全体の対応がよくありません。 こんにちは！LINEフロントエンド開発室のダバロス アランです。この記事のタイトルを見て「釣りタイトルですね〜」と考えている方がいると思いますが今回に限ってはそれを大目に見てください。それはなぜかと言いますと、2021年から2022年にかけて私たちフロントエンドエンジニアが全体的に考え方を改める必要が出るほど大きな変化がありました。 その変
皆さん、フォーム作ってますか？ Webサイトやアプリを作るにあたって避けられないのがForm作成、多くの方が autocomplete を設定するなど、より使いやすいフォームを作成するために尽力されていることと思います。 一方で、悪気なく書いたコードでより使いにくいフォームになってしまっている例が世の中には多く見られます(特に銀行系) 今回は、よくあるフォームの実装を例に、(特に日本語話者にとって)より使いやすいフォームにするためのちょっとした仕様や私が考える対策を書いていこうと思います。 忙しい方のために最初に書いておくと、この記事に書いてあることの多くは autocomplete の仕様を意識した実装をしましょう の一言に集約されます。 多くの方にとっては「何を当たり前のことを」と思われる項目も多いかとは思いますが、当たり前のことがされていないフォームが世の中には多すぎるので、少しでも
伊是名夏子♿︎コラムニスト @izenanatsuko JRで車いすユーザー乗車拒否にあいました。「階段しかない駅なので案内はできない」と。今の時代でも悲しいかな、よくあること。バリアフリーって全然進んでいない、むしろ無人駅が増え後退してる。味方が必要なので、長いですが、どうか読んでください、シェアしてください。 blog.livedoor.jp/natirou/archiv… pic.twitter.com/XjkSTNxnPh 2021-04-04 11:29:49 中島るも💉×4 PPAP @ginozafarm001 @izenanatsuko せっかくJRが対応しようと「事前連絡の協力」をお願いしているのに、協力しないで当日突撃するクレーマーは、他の車イス利用者にも迷惑。 社民党所属らしいですが、こんな自己中心的な方は社会福祉に関わって欲しく無いです。 jreast.co.jp
ブラインドライターズのスタッフは9割が視覚障害者。 先日、みんなで「どうやって服を買うか」の話になりました。 マネキンの服は見えないので、コーディネートが分からない 下着を買いたいけど、店員さんの性別が分からないので声をかけづらい ロービジョンなので黒なのか紺なのかわかりにくく、店で買いづらい などと、たくさんの悩みごとがありました。 確かに、異性の店員さんに下着の相談はしにくいですよね。 タグが読めなければ、サイズも分からない。リアルでの買い物は一人ではけっこう難しそうです。 そんなときに便利なのがECサイトです。 色もデジタル表記になっていればPCが読み上げてくれるので選びやすい 下着も人に頼まなくていいので買いやすい マネキンのコーディネートは見えないので、サイトで確認したい また「リピ買いするならサイト」という意見もありました。確かに見えていないと広い店内のどこにあるのかサッパリ分
If users ever need to log in to your site, then good sign-in form design is critical. This is especially true for people on poor connections, on mobile, in a hurry, or under stress. Poorly designed sign-in forms get high bounce rates. Each bounce could mean a lost and disgruntled user—not just a missed sign-in opportunity. Here is an example of a simple sign-in form that demonstrates all of the be
先日、任天堂の株主総会が行われた。例によって詳細をまとめているので前回の記事をご覧いただきたい。 任天堂株主総会レポート2024 | N-Styles 株主総会レポートでも記載したが、質疑応答で最初に指名された質問者が「任天堂は視覚障害者対応が遅れているのではないか」と指摘し、私はこの質問に非常に驚いた。 なぜなら、私自身が株主総会参加の半年以上前から用意していた質問とほぼ同じだったからだ。 この質問内容を7月1日に任天堂が掲載した議事録から引用する。 Q1 ゲームを遊びたいと思っている視覚障がいを持つ人も、世の中にはいると思う。任天堂がこうした方に向けて取り組んでいることがあれば説明してほしい。 A1 代表取締役社長 古川俊太郎： 当社では、世界中の多くの方々に当社のゲームを遊んでいただきたいと考えています。この場で具体的な取り組みを申し上げることは控えさせていただきますが、視覚障がいの
俺は、爺さんと親父と２人の車いすを押してきた人間として、映画館の対応で炎上している今の騒動を複雑な気持ちで見ている。 少し愚痴を書き込みたい。 単純な話として、もし自分の働いているところにああいう車いすユーザーが来たら、表面的な対応は別としても内心では腹が立つ。これはもうしょうがない。 クソみたいなクレーマーは多いし、ちょっとこっちが仏心を出すとそこにつけこむクソ客も多い。 とりあえず言ってみて通ればめっけもん、一度通ればそっからはソコを最低ラインとしてさらに言う、対応できなきゃ文句を言う。対応する側としてはクソ客以外の何物でもない。 ただ、そういう対応する側からすると速やかにおかえり願えないかなと思うようなゴリゴリ押してくる車いすユーザーが先陣を切ってくれなければ、変わらなかっただろうな、とも思う自分が居る。 爺さんの時は、俺も車いすを押したが、主に調べたのは親父やおふくろだった。 何を
この記事は 「Webアクセシビリティ Advent Calendar 2020」 5日目の記事です。 アクセシビリティ Advent Calenderの記事を寄稿するにあたり、少しの工夫であらゆるユーザーに対して優しいWebサイトを作れるようなHTML/CSSコーディングの方法についてまとめました。より多くの人にとって優しい・使いやすいWebサイトを作ることは訪れてくださるユーザーの方々だけでなく、クライアントにとってもユーザーの機会損失を防ぐことができるので多大なるメリットがあります。（よくコードが適当でもデザインが見えていれば良いって意見を聞くけれどそんなことはない） ただ、アクセシビリティを意識したHTML/CSSコーディングについてのまとめだと内容量が非常に多くなりZennなら記事より本で出したほうがベターになってしまうので、今回は数あるアクセシビリティの視点から「キーボード操作で
All-in-one color tool for creators
少数色覚者にとって黄緑とオレンジは見分けづらい組み合わせの一つです。この記事のタイトル画像とかなかなか最悪です。 WEB、アプリや印刷物などのメディアではだいぶカラーユニバーサルデザインの考え方が浸透してきており、デザイナーも多様な色覚でも読み違えないように配慮してデザインすることが当たり前になってきていると思います。 Photoshopなどのグラフィックツールには簡単に少数色覚の見え方を確認できるプレビューモードがありますし、AdobeColorを使えば無料で少数色覚の人が混同しやすい色かどうかをすぐに確かめられます。https://color.adobe.com/ja/create/color-accessibility 少数色覚が見分けづらい色の組み合わせだと「-」が表示されるしかし、工業製品の世界では少数色覚にとって見分けづらい緑とオレンジの組み合わせのLEDインジケータ（表示）を
デジタル庁では「誰一人取り残されない、人に優しいデジタル化」を実現するため、継続的に「ウェブアクセシビリティ」の向上に取り組んでいます。この度、ウェブアクセシビリティに初めて取り組む行政官の方や事業者向けに、ウェブアクセシビリティの考え方、取り組み方のポイントを解説する、ゼロから学ぶ初心者向けのガイドブックを公開します。 優しいサービスのつくり手になる一助として、ぜひご活用ください。 公開の背景ウェブアクセシビリティの向上に取り組むには、非常に専門的な複数の規格とガイドラインをそれぞれ確認する必要があります。そのため、適切なやり方がわからないままに、現在は間違っている対応の踏襲、不要・過剰な対応、不適切な対応をしてしまうことがあります。ウェブサイトだけではなく、申請・手続等のデジタルサービスの重要性が増す中で、最新の技術動向を踏まえた、初心者が学習できる行政機関向けの研修資料が不足していま
先日のアップデートでシャニマスのUI周りに色々と手が加えられた。 その中でも個人的に嬉しかったのは、ソートに関連するチェックボックスのON/OFFが見やすくなっていたことだ。 大多数のユーザーにとっては「まあ確かにね」くらいのものかもしれない。しかし私は「これでようやくまともにソート機能が使える」とひそかに歓喜した。一部のユーザーも共感してくれるのではないだろうか。 なぜなら私の目に映った変化は以下のようなものだったから。 チェックの光沢の有無でかろうじて判別していた（ひよこ鑑定士か？）この見え方の差異は、私が『色覚マイノリティ』、いわゆる『色弱者』であることに起因する。 『色弱者』って何？光（色）を感じる視細胞が何らかの原因により欠損、または十分に機能しないことによって色の見え方が一般とは違う人のことを、本記事では『色弱者』という呼称で表記する。 日本人男性の5％、女性の0.2％がこの色
全国の中高生を対象にした発明コンクール「自由すぎる研究EXPO」で岡山市の女子高校生が最多となる5つの金賞を受賞しました。考案したのは「納豆を片手で食べられる道具」です。一体なぜそのような道具を？そこに…
側弯症の女性が主人公の芥川賞受賞作「ハンチバック」。その作者で自身も側弯症である市川沙央さんに「ハンチバック」の作品に込めた思いなどを尋ねました。作品についての質問から、世間の障害者観についての質問まで、幅広くお答えいただきました。特に、障害者の権利やヘイト言説についての質問には、とても気持ちのこもった痛快な回答でした。 あれでも相手役だった「田中さん」 (c)撮影：深野未季（文藝春秋） ──様々な固有名詞や専門用語などが実名で登場していますが、そこに意図はおありでしょうか。 「医療用語、医療機器名に関してはリアリティとともに、日常感を示すためです。特別なものではないということですね。WEB小説用語もそうですね。いや、『ナーロッパ』とかは、単純に『ナーロッパ』というワードを純文学の文芸誌に載せたかった、WEB小説界からそのように殴り込みをかけたら面白いじゃんと思って書いていたかもしれません
「当時としては、ワガママとされ、暴力的とされ、迷惑とされ、非常識とされ、だけどその騒ぎのおかげで後輩達が恩恵を受けている」 私はいつも「川崎バス闘争」を思い出す。 公共交通機関に「車椅子の人を一人で乗せろ」として、「闘争」があったのだ。
Search, watch, and cook every single Tasty recipe and video ever - all in one place! News, Politics, Culture, Life, Entertainment, and more. Stories that matter to you.
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog はじめに こんにちは。フロントエンド開発センター UIT Accessibilityタスクフォース 岡﨑です。私たちは、Webサイトのアクセシビリティに関するガイドラインの策定・推進、社内に向けたアクセシビリティの勉強会やe-ラーニングを通じて、LINEとそのファミリーサービスのアクセシビリティ向上を目指しています。 色に対する配慮 アクセシビリティの国際規格となっているWCAGでは、テキストにおける色の取り扱いで以下のことが求められています。 色に依存した表現にしないこと コントラスト比を確保すること なぜ、色に対する配慮が必要なのでしょうか？ 困っているのはロービジョンユーザーだけではない LINE STYLEの"Alwa
この文章について これは 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業界で「エンジニア」の肩書で仕事して
この記事は Front-End Study #3 で発表されたライブコーディングの内容を記事にしたものです。記事中のソースコードは GitHub でご覧いただけます。 この記事は、これまで一般的なフロントエンドエンジニアだった私が一年ほどアクセシビリティーについて勉強する上で 「最初に教えてくれればよかったのに〜！」と思った内容 を React と Next.js を用いて紹介するものとなっています。 読み終わった後に次にコードを書く際にふと意識できるようなアクセシビリティーの普遍的な事実を紹介し、最後に今後の React の動きについて軽く触れるものになっています。目次は次のとおりです： 基本事項 SPA のルーティングによる問題 リッチなコンポーネントでの例 Jest + React Testing Library でのテスト Reactとアクセシビリティーの今後の動き 役に立つweb
MdN Bau-ya “「わかりやすさ」をデザインする 情報アーキテクチャ（IA）必修入門” (2023/1/18開催) https://www.street-academy.com/myclass/149720 上記イベントで使用したスライドを公開用に編集したものです。 作者：森田 雄 / …
2024年1月9日にboardの有料登録社数が5000社を突破したので振り返りです。 boardの正式リリースは2014年8月20日なので、約9年半ほどで、推移はこんな感じでした。 ＊「社数は累計ですか？」と聞かれることがよくあるのですが、累計ではなくその時点のアクティブな数です。 1000社刻みで定点観測的に書いているので、過去の記事も貼っておきます。 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入1000社に行くまでの経営・受託とのバランス（BPStudy発表時の補足） 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入2000社に行くまでの振り返り 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入3000社に行くまでの振り返り 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入4000社に行くまでの振り返り boardとは 見積書・請求書
はじめに 私はデザイナー兼フロントエンドエンジニアというような立ち位置で、勤務するfreee株式会社のアクセシビリティガイドラインの作成に関わったり、アクセシビリティまわりの仕組みの整備や社内エバンジェリストみたいなことをしています。 もともと私はWebアクセシビリティという分野が、重要なものである以上に技術や考え方として面白いと思ってやっているうちに気付いたら仕事で大きなウェイトを占めるようになってしまったタイプの人です。しかし、そうではない人たちにその重要さを説明したり、対応をお願いしたり、そのための資料を作ったりしているうちに、「やっぱWebアクセシビリティって難しいんだなぁ」と思うようになってきたので、それについて書いてみようと思います。 なお、背景を説明するうえで必要なので社名を出しましたが、あくまでこの文章は個人の見解であり、所属組織とは関係がありません。 誰のためにやるのかが
こんにちは。伊原 力也（@magi1125）と申します。業務アプリケーションのデザイナー、デザインチームのマネージャー、アクセシビリティ関連のコンサルタントなどをやっています。 ウェブアクセシビリティを普及啓発する活動を始めて10年が経ちました。おかげさまで興味を持ってくれる人はかなり増えたと感じています。しかし、人が増えると声は届きにくくなります。「アクセシビリティをどこから学び始めていいかわからない」という意見も目にするようになってきました。 また、私はこれまでにアクセシビリティに関する書籍を何冊か書いていますが、専門書ってちょっと高いので、興味があるぐらいの段階で本を買うのはちょっと……という気持ちもわかります。 ということで、これまで自分が発信したり関わったりしたコンテンツのうち、ウェブアクセシビリティの理解の助けになりそうものをベストアルバム的に一度まとめてみることにしました。
近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します（あくまで執筆現在の脳内アウトプットになりますのでご了承ください） フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの？」と思うこともあるので、とくに要望がなければ、筆者は「
車椅子ユーザーのコラムニスト、伊是名夏子さんが4月4日に投稿した「JRで車いすは乗車拒否されました」とのブログ記事が炎上し、いまも燃え続けています。 炎上が続く背景には、JRの駅員に対して合理的な配慮を求める伊是名さんが、自身は合理的な配慮をまったくしていないことにあると分析します。 炎上したブログの内容とは？ まず初めに、炎上している記事の内容について紹介します。詳細はブログを読んでいただくとして、まとめると 無人駅の来宮（きのみや）駅で降りたいため現地での車椅子対応を当日に乗車駅の小田原駅で依頼したところ、駅員は熱海駅までの乗車を提案。 1時間ほど「来宮駅での対応をして欲しい」と交渉したのちに熱海駅に向かうと、熱海駅では駅長ふくめて4人で対応をしてくれた。 帰路では事前連絡をお願いされていたため前日に連絡したところ、来宮駅で駅員が待機してくれており、希望の時間の電車に乗れた。 という内
Zホールディングス株式会社
Web アプリケーションエンジニアのためのウェブアクセシビリティの基礎 2023.02.18 ウェブアプリケーションエンジニアを対象に、アクセシビリティの対応について解説した記事。アクセシビリティを向上させるためには、正しいHTMLの書き方が必要である。HTML要素には、アクセシビリティに関する機能が元々備わっているため、適切なHTMLを選択し使用することが大切だ。複雑なUIの場合はWAI-ARIAを使用し、ARIA Authoring Practices Guideに基づき適切に実装する必要がある。UIライブラリ選びの際には、WAI-ARIAに従った実装を行っているかが基準の1つとなる。 この記事は、ウェブアプリケーションエンジニアとして仕事をされているほうを対象に書かれています。日々のウェブフロントエンドの開発の中で意識しておきたい基礎的な内容をメインに記載しています。 そのため、ここ
以前にも少し書いたのですが、ウェブブラウザーで使えるページ内検索による体験が阻害されるのが本当にストレスで、その例を残しておこうと思います。 採用側の気持ちも分かりますので、どうなると皆が幸せになるのか分からないという種類のものなので困ったところです。 省略されたテキストoverflow: hiddenとtext-overflow: ellipsisまたは-webkit-line-clampによってテキストが省略された場合、その省略部分がページ内検索にヒットすると非常に探しづらいです。 特に、グリッドで区切られたアイテムが複数列・複数行で並んでいる際に顕著です。 以前の記事のとおり、わたしはYouTubeでよく遭遇します。 下記のデモは、1000個のアイテムを並べたものです。 このうち、「Red Rose」というワードは12個のアイテムに含まれています。 デモを開いて「Red Rose」で
イギリス行った時、「日本よりたくさん車椅子の人がいるな」と思ったのです。イスラエルでも同じ事を思いました。美術館にもゲームショップにも本屋さんにもパブにもいる。でも、これは違うわけで、人口比は大差ないはずなのです。「これがバリアフリーの差かあ」と、自分の認識の甘さを恥じ入りました
見えない人はWebをどう閲覧？ 本紙サイトの課題にがくぜん、求められる「不十分と認める勇気」【動画も】
こんにちは、 freeeでデザインシステムを作っていたりアクセシビリティーのいろいろをやっていたりする id:ymrl です。 freeeではfreeeアクセシビリティー・ガイドラインを策定して、誰でも使えるアクセシブルな製品開発ができるよう取り組んでいます。これまでも、開発者（エンジニア、プロダクトマネージャー、デザイナー）向けには実習を含むアクセシビリティー研修を行ってきました。 そしてこのたび10月から 対象を全新入社員向けに拡大 してアクセシビリティー研修を行うようになり、あわせて開発者向けの研修も内容を整理したので、今回はその紹介をします。 なぜ全員に研修をするのか これまでのアクセシビリティーの取り組みは、プロダクト開発を中心に進めてきました。「だれもが自由に経営できる統合型経営プラットフォーム」をビジョンに掲げている以上、まずは提供しているSaaSが誰でも使えるものになってい
この手の話では「前もって連絡しろ」とぬかすやつが大勢出てくるが、そもそも健常者が気にしないことを車椅子ユーザーが多大な負担でもってクリアしなければいけないこと自体が差別であるという理解がいつになったら共有されるのだろうか。 https://t.co/xjQmdF7Nm8
フロントエンドエンジニアの嶌田です。今回が LIFULL Creators Blog への初めての投稿です。 「サービス共通ヘッダ・フッタ」は、ただのヘッダ・フッタではありません。ソースコードはいくつものサイトやサービスで使いまわされます。組込み先が持っている CSS によっては表示が崩れてしまうかもしれません。ブレークポイントやコンテンツの幅がそろわないかもしれません。サービス共通で使えるヘッダ・フッタには相応の強さや柔軟さが求められます。 この記事では、LIFULL HOME'S のサービス共通のレスポンシブ版ヘッダ・フッタを実装するために動員した「強く・堅牢に実装するためのノウハウ」を紹介します。 どこにでも組み込めるように実装する 重複しないクラス名ルールを設定する 詳細度や継承とうまく付き合う プレーンな技術を使う ブレークポイントや z-index 等をカスタマイズ可能にする
■ はじめに <div>要素にonClickを渡すべきではない、ということ聞いたことはないでしょうか？ ただ、なぜ渡すべきでないのか？ 理解してなかったので今回調べてみました。 サンプルコード 今回動作確認に利用したサンプルリポジトリのコードはReactで書いています。 ■ 結論：<div>にonClickを定義するのがなぜダメなのか？ ユーザーにとって操作性の低いボタンになってしまうから、です！ 要するに UX が悪くなってしまうから！ その理由を解説していきます！ ■ 操作性の低いボタンになってしまう理由 大きく３つあると考えています。 div要素は focus を持たないから returnキー, spaceキーをonClickに変換しないから スクリーンリーダーが認識しない要素だから ◎ focus を持たないから <div>要素はfocusを持ちません。 なので、tabキーで要素に
まずはこちらをお聞きください。 技術的解説: ボタンを a 要素で作るな a 要素は URL などへのリンクをつくるためのもので、button 要素はなんらかの処理を起動するボタンをつくるためのものです。 配置されるものがリンクなら a 要素で実装し、ボタンなら button 要素で実装すべきです。 これに違反すると、意図しない動作や、アクセシビリティ上の問題が発生します。 これは MDN でも詳しく説明されています。 onclick イベント -- \<a>: アンカー要素 - HTML: ハイパーテキストマークアップ言語 | MDN よく見られる誤った使い方として、擬似的なボタンを作成するためにアンカー要素を使用し、href を # または javascript:void(0) に設定してページの再読み込みを防ぎ、click を待ち受けするようにするというものがあります。 これらの偽の
ツイッターでアクセシビリティ向上日誌２【目視試験編】‐Akira Tsuda Portfolio and Blogというのを見かけて、そういえばアクセシビリティチェックって何をどうしているのかという話をウェブ上でほとんど見かけない（というか自分は知らない）ので、思い切ってチェックの過程や考え方を書いてみようかなと。 チェック対象のサイトを作った@HeldaForStudy氏に尋ねたところ、題材として使ってよいという返事をいただいたので、「アトリエ金工やまぐち」のサイト1ページをチェックしてみることにします。 対象ページはBasic認証がかかっているので、アクセシビリティ向上日誌１【各種ツール評価編】からたどってください。 @HeldaForStudy氏はレベルはA*1でチェックしたとのことなので、チェック基準はWCAG 2.1レベルAでチェックすることにしましょう。 わたしは普段はCOB-
アクセシビリティとは アクセシビリティは、サービスや情報をどんな利用者も円滑に利用できるかの度合いです。 アクセシビリティが高いほど、より多くのユーザーが円滑に利用でき、アクセシビリティが低いほど、より多くのユーザーが利用できないということです。 アクセシビリティ向上は、障害当事者だけでなく、さまざまな環境や状況にいる人、高齢者、日本語以外を得意な言語とする人など、すべての人のためのものです。人だけでなく、サービスや情報にアクセスする機械(ロボット)もアクセシビリティの影響を受けます。 SmartHRの開発方針 SmartHRは「well-working 労働にまつわる社会課題をなくし、誰もがその人らしく働ける社会を作る。」というミッションを掲げ、働くすべての人を後押しするプラットフォームをつくっています。 誰もがその人らしく働ける社会を実現するため、SmartHRはアクセシビリティの向上
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く