現在、ウェブアプリには設定ページがあり、チェックボックス付きのコントロールのリストがあるため、特定の機能を有効または無効にできます。これらの下に保存オプションがあり、前のチェックボックスが変更されるまで無効になっています。
このフォームをよりアクセスしやすいように適合させようとしています。現在のアプローチは、保存オプションを無効にせず、変更が行われていない場合はエラーをスローし、変更が成功した場合は成功メッセージをスローします。
これはもっと使いやすいの形式にはならないようですが、送信ボタンを無効にしてはいけないというアクセシビリティルールを回避するのに役立ちます。ただし、相互作用の観点からは、ボタンのdisabled外観のアフォーダンスにより、ユーザーは作業が完了していないことを知ることができます。
このシナリオで考え出された3つの解決策があります。
アクセシビリティ志向の人々が、これらのオプションのどれか(または私が考えていなかった代替案)がこのシナリオのアクセシビリティを向上させながら使いやすさを向上させると考えている場合は、お知らせください。
しかし、送信ボタンを無効にすべきではないというアクセシビリティルールを回避するのに役立つだけです。
そのような「ルール」はありません。 [〜#〜] wcag [〜#〜] には、送信ボタンを無効にできないことを意味するものは何もありません。
個人的には、SAVEを有効のままにして、変更を行わなくても誰かが保存できるようにするのが最も簡単な方法だと思います。なぜそれがエラーをスローするのですか?非常にシンプルなUIです。ユーザーが何度でもSAVEをクリックできるようにします。
もう1つの可能性は、保存するのに「費用がかかる」かどうかによって、自動保存することです。チェックボックスが選択されるたびに保存できます。とても人気のある柄です。その後、元に戻す方法が必要になる場合がありますが、[保存]ボタンは必要ありません。
質問は言う、
このフォームをよりアクセスしやすいように適合させようとしています。現在のアプローチは、保存オプションを無効にしないことです(...)。
これはフォームをより使いやすくするようには見えませんが、送信ボタンを無効にすべきではないというアクセシビリティルールを回避するのに役立つだけです。
ただし、WCAG 2.1では、無効なボタンやユーザーインターフェイスコンポーネントを禁止していません。実際、成功基準 1.4.3(コントラスト最小) 、 1.4.6(コントラスト強調 および 1.4.11(非テキストコントラスト) すべてに「非アクティブコンポーネント」の除外が含まれていますユーザーインターフェイスコンポーネントの無効化を禁止する達成基準はありません。
読み取りビューと編集ビューを使用する最初のシナリオは、学習管理システムで見たものですが、通常のフォームでは上回っています。ユーザーは、チェックボックスが他のWebアプリのチェックボックスのように機能することを期待します。
2番目のシナリオは、フォームの何かが変更されるまで、通常の保存/送信ボタンを無効なボタンのように見せることで、他の欠点があります。
aria-disabled
状態 。(それが必要かどうかについても考慮する必要があります 無効なボタンをキーボードフォーカス可能にする 。)
シナリオ3も機能しますが、2番目のシナリオにリストされている基準に準拠した無効化されたボタンを使用するよりもはるかに多くの作業が必要になります。