1

数日前、ほぼすべての種類の AJAX 要求について、WAI-ARIA に関するチュートリアルとドキュメントをインターネットで検索し始めました。

jQuery と AJAX を使用して、ネストされたドロップダウン リストをコーディングすることに慣れています。それはかなりうまく機能しますが、ネイティブにアクセスすることはできません。たとえば、AJAX などのあらゆる種類の動的なもののアクセシビリティを「有効にする」には、WAI-ARIA 固有のタグを使用する必要があります。

私の要件の1つは次のとおりです。

  • onchange イベントを使用して Region ドロップダウンを更新する State ドロップダウンがあるとします。Region ドロップダウン リストが更新されたことをユーザーに伝えるために、WAI-ARIA と jQuery を使用してスクリーン リーダーと対話するにはどうすればよいですか?
4

2 に答える 2

4

My 2c is that aria-controls may be a better fit here.

The UI you are describing here sounds very similar to the Country/State selects that you often find when purchasing a product online. A typical pattern for these is:

<label for="country">Country:</label>
<select id="country" aria-controls="state">
    <option value="">Select a country...</option>
    <option value="Andorra">Andorra</option>
    <option value="Belgium">Belgium</option>
    ...
</select>
<br>
<label for="state">State:</label>
<select id="state">
    <option value="">(Select a country first)</option>
    ... options here populated when country changes ...
</select>

A couple of things to note here:

  • I'm using 'placeholder' option entries at the start of each select. This has two benefits. First, it provides reinforcement documentation about how the user should use the UI - if they somehow end up looking at the second field first, it will direct them to the first one. Secondly, it avoids the user accidentally selecting a default value: your code can check if the default 'Select...' is the one submitted and remind the user to pick an actual value. And, additionally, it hides the fact that the contents options are changing from the user.

  • The main thing here, though, is that the relationship between these two selects should be clear from context in the form or page. Sighted or not, a user who encounters a form like this won't need to be explicitly told that the contents of the state select have changed, because they'll expect that from the form design, and from the context. People know that states are specific to a country (there's no "California" in Germany, for example), similarly with counties, so there's already an expectation of how these work.

Use of aria-live doesn't feel like it's appropriate here. It's really designed for areas of the page that update asynchronously, and which the user would otherwise have to poll continuously, reading back and forth, to scan for changes. Chat panels are perhaps the classic example: when a message appears from someone on the other end, you want the screenreader to read out the message when it appears, and not have to manually go hunting for it. By contrast, the UI here is more synchronous; when the country changes, the states are populated there and then(*), it's expected behavior.

ARIA does have an aria-controls="ids..." attribute, which seems to be a better fit: the spec says it's used for when one control affects the visibility or contents of another, which seems to describe what's happening here. I don't know offhand whether any screenreaders support this yet or what they would read out when its present - I may look into this and update this answer later. But in any case, the main point from earlier applies, the form's behavior and semantics should be apparent without this anyhow.

--

(*) There's still an issue that if you update the content asynchronously - eg. by getting the list of counties via ajax rather than from an array that's already loaded on the page, then there could be a delay between selecting the country and the results becoming available for use in the next select. aria-live doesn't feel like the right solution here again, since you don't want to read out the new content, you just want to let the user know that the select is now ready for use.

于 2012-07-06T03:56:25.390 に答える
1

この使用例では、属性とサンプル コードを追加aria-liveします。aria-atomic

<select id="foo" aria-live="assertive" aria-atomic="true">
    <option value="nw">Northwest</option>
    <option value="ne">Northeast</option>
    <option value="se">Southeast</option>
    <option value="sw">Southwest</option>
</select>

属性assertiveの正しい値だと思いますが、代わりに適切かもしれません。この属性は、変更があった場合に領域全体を表示する必要があることをブラウザー/AT に伝えるためにあります。また、最初に選択で使用することを検討してから、状態選択に関連付けられた値で更新する前に切り替えることもできます。aria-livepolitearia-atomicaria-disabled: truefalse

編集

OK、NVDA と IE9 と Firefox 13.01 を使っていくつかのテストを行いました。現時点では JAWS を利用できないので、誰かが JAWS でページをテストできるとうれしいです。 私が知る限り、VoiceOver はariaまだプロパティをサポートしていません10.7 (Lion) で Chrome + Voiceover でテストしたところ、Voiceover は実際に をサポートしているようですaria-live。

テストページはこちらから入手できます。

領域選択へのデータのロードをシミュレートする単純なスクリプトを使用しました (オブジェクトを使用):

var options = [],
    regions = {
    'nw': 'Northwest',
    'ne': 'Northeast',
    'se': 'Southeast',
    'sw': 'Southwest'
}

$(document).ready(function() {
    $.each(regions, function(key, value) {
        options.push('<option value="'+ key +'">'+ value +'</option>');
    });

    $('.block').on('change, focusout', '.states', function() {
        $(this).parent().children('.regions')
            .attr({'disabled': false, 'aria-disabled': false})
            .html(options.join(''));
    });

    window.setTimeout(
        function() {
            $('#speak').text('assertive!');
        },
        3000
    );
});

これで少し遊んだ後のいくつかの観察（スクリーンリーダーに関しては私は確かに専門家ではないので、何か見逃した場合はお知らせください）...

  • HTMLdisabled属性の使用はお勧めできません。状態選択がフォーカス アウトされるまで領域データをロードしたくないためです。関連する領域選択はフォーカス アウトの時点で無効になっているため、次のコントロールにタブ移動するとスキップされます (これは、以下の録音で聞くことができます。) 奇妙なことに、Firefox は、フォーカスしていなくても、領域選択の値を通知します。

  • politeとの間の動作に違いは見られませんでした。属性assertiveのない例では、さらに言えば。aria-liveFF13 も IE9 も に対応していると思っていaria-liveたのですが、コード ( $('#speak')...) の最後から見ると IE9 には対応していないように見えますか?

  • おそらく、AJAX を介した読み込みをシミュレートするための遅延を追加するのは良いことです。

録音を聞くことができます: IE9 , Firefox 13

于 2012-07-05T21:29:21.603 に答える