記事は上記記事を意訳したものです。
※当ブログでの翻訳記事は元サイト様に許可を得て掲載しています。
HTML
読み取り専用（readonly）属性は、テキストフィールド（<input>と<textarea>）にのみ許可されています。
WHATWG HTMLの仕様では、他のコントロール（ボタン、チェックボックスなど）を読み取り専用にすることは、無効化することと実質的に区別がないと主張しています。もちろん、フォーカス可能であるという点は除きます。
フォーカス
読み取り専用のフィールドとコントロールはタブ順序に含まれます。明確な手がかりがないため、ユーザーにはフィールドを編集できない理由が不明確です。明らかなスタイルがあっても、依然として編集できない理由は不明確です。
もちろん、ブラウザ間で一貫性のない部分もあります。Windows and Androidの Firefox（執筆時点で132）では、読み取り専用の日付、日時、または時間の入力フィールドにフォーカスを当てることができません。機能的に無効化されたように扱われ、悲しげな灰色の無効化されたテキストも表示されます。
スタイル
読み取り専用のテキストフィールドのデフォルトスタイルはありません。ブラウザは何も割り当てず、CSSも提供していません（例：CSS Basic User Interface Module）。ユーザーにとって意味のあるスタイルを自分で考える必要があります。CSS Selectors Level 4 Working Draftには、:read-onlyの疑似クラスセレクターが用意されています。以前は（今でもかもしれませんが）[readonly]属性セレクターに頼る必要がありました。WCAG（Web Content Accessibility Guidelines）のコントラスト要件は読み取り専用コントロールにも適用されるため、薄暗い灰色のテキストは使用できません。
Material Designが研究不足なフィールドスタイルを導入するまで、シンプルな下線が最悪ではないと考えていました。これについては、「Under-Engineered Text Boxen」の記事で触れています。
先述のように、WindowsとAndroidのFirefoxは、日付、日時、時間の入力フィールドの値を悲しげな灰色のテキストで表示します。その理由については調査していません。
Android版Chromeは、Firefoxの悲しげな灰色テキストに負けじと、日付、日時、時間の入力フィールドの値を灰色で表示し、さらに月と週の入力フィールドも同様にします。ただし、これらはフォーカス可能です。
編集可能？
HTMLの読み取り専用テキストフィールドはフォーム送信に参加するため、ブラウザの開発者ツールを使用して簡単に回避できます。何度か、問題のあるフォーム（少なくとも1回のログイン）を、開発者ツールでreadonlyを削除し、オートコンプリートやパスワードマネージャーに処理を任せることで対処しました。これは、開発者がHTMLフォームを尊重し、肥大化したJavaScriptのゴーレムでフォームを処理していないことを前提としています。
ARIA
ARIAで<div>をウィジェットまたは問題のあるフォームコントロールに役割付けする場合、aria-readonlyは実質的に何もしません。おそらく（常にではありませんが）スクリーンリーダーユーザーにフィールドが読み取り専用であることを伝える程度です。作者は依然として、入力を禁止するスクリプトを書く（または機能しないようにスクリプトを書かない）必要があります。
ただし、HTMLとは異なり、aria-readonlyはチェックボックス、コンボボックス、グリッド、グリッドセル、リストボックス、ラジオグループ、スライダー、スピンボタン、テキストボックスの役割で許可されています。これはユーザーがこれらのコンテキストで理解できることを意味するわけではないため、不要なグリッドや複雑なリストボックスを読み取り専用にする招待状ではありません。また、これがスクリーンリーダーユーザーに公開されることを意味するわけでもありません。
スクリーンリーダー
デフォルトや業界全体で共通のビジュアルデザイン言語がないため、サイトを問わずコントロールが読み取り専用であることを合理的に知る唯一の一貫したユーザーは、スクリーンリーダーユーザーです。読み取り専用は、プロパティ（readonlyとaria-readonly）であるため、公開されます。時々は。
JAWS
JAWS 2024とChrome 131では、テキスト、メール、数字、パスワード、検索、電話、URLの入力とtextareaが読み取り専用として通知されます。これはreadonlyが許可されているフィールドのサブセットであることに注意してください。
HTMLのテキスト入力とtextareaは、aria-readonly="true"で読み取り専用として通知されます。
ARIAウィジェットでは、チェックボックス、スピンボタン、テキストボックスの役割のみがaria-readonly="true"を報告します。これもaria-readonlyが許可されている役割のサブセットです。
NVDA
NVDA 2024.4とFirefox 132では、テキスト、メール、月、パスワード、検索、電話、URL、週の入力とtextareaが読み取り専用として通知されます。これはreadonlyが許可されているフィールドのサブセットであることに注意してください。また、日付、日時、時間の入力は依然としてフォーカスを取得できません。
HTMLのテキスト入力とtextareaは、aria-readonly="true"で読み取り専用として通知されません。
ARIAウィジェットでは、チェックボックスとテキストボックスの役割のみがaria-readonly="true"を報告します。これもaria-readonlyが許可されている役割のサブセットです。
VoiceOver / macOS
macOS 15.1.1とSafari 18.1.1のVoiceOverでは、テキスト、メール、月、数字、検索、電話、URL、週の入力とtextareaが選択可能として通知されます。VoiceOverは「読み取り専用」とは言わず、フィールド値、選択状態、名前、フィールドタイプ、妥当性の後に「選択可能」と発表するだけです。
HTMLのテキスト入力とtextareaは、aria-readonly="true"で読み取り専用として通知されません。
ARIAウィジェットでは、テキストボックスの役割のみがaria-readonly="true"を報告します。これもaria-readonlyが許可されている役割のサブセットです。選択可能なテキストにいることを通知します。
これは、iPadOS版のVoiceOver / Safariとは異なることに注意してください。
TalkBack
TalkBack 15.1とChrome 131では、テキスト、メール、数字、パスワード、検索、電話、URLの入力とtextareaが無効として通知されます。これはreadonlyが許可されているフィールドのサブセットであることに注意してください。また、TalkBackはフィールドを「無効」として通知し、「読み取り専用」とは通知しません。
HTMLのテキスト入力とtextareaは、aria-readonly="true"で無効として通知されます。つまり、間違った状態を通知します。
ARIAウィジェットでは、チェックボックス、コンボボックス、リストボックス、ラジオグループ、スライダー、スピンボタン、テキストボックスの役割がaria-readonly="true"を「無効」として報告します。TalkBack / Chromeはテストした全ての役割に対応していますが、間違った状態を報告します。
VoiceOver / iPadOS
iPadOS 18.1.1とSafariのVoiceOverでは、テキスト、メール、数字、パスワード、検索、電話、URLの入力とtextareaが読み取り専用として通知されます。これはreadonlyが許可されているフィールドのサブセットであることに注意してください。
HTMLのテキスト入力とtextareaは、aria-readonly="true"で読み取り専用として通知されません。
ARIAウィジェットでは、テキストボックスの役割のみがaria-readonly="true"を報告します。これもaria-readonlyが許可されている役割のサブセットです。
これは、macOSのVoiceOver / Safariとは異なることに注意してください。
デモ
CodePenのデモ（およびデバッグバージョン）を作成しました。ARIAウィジェット用の基本的なテキストスタイルとフォーカススタイルのみを設定しています。
ARIAウィジェットは機能しません。アクセシビリティAPIに公開されているかをテストするためにのみ存在し、認識されるための最小限の属性、状態、値を持っています。
HTMLのNuチェッカー（HTMLバリデーター）にリンクしているので、バリデーターが提供するエラーを確認できます。どの入力タイプが読み取り専用になれるかについて、HTML仕様よりも詳細な情報を提供します。
結論
簡単に言えば、読み取り専用のコントロールをスタイル設定し、スクリプト化し、適切に公開することが面倒だと感じるなら、使用するのがどれほど面倒かを想像してみてください。おそらく避けるべきでしょう。
