A11y要素フォーカスボックス

This page is not available in the language you requested. You have been redirected to the English version of the page.

Link to this page copied to clipboard

VoiceOverのフォーカスボックスは、アナウンスする要素を完全に囲む必要があります

Not for use with personal data

チェックすること

要素のアクセシビリティパスまたはVoiceOverのフォーカスボックスは、その画面上のフレームを完全に囲む必要があります。

このルールはDequeのベストプラクティスを遵守します。このルールは、モバイルダッシュボードから、または iOS用に書かれたテストでルールを無視することによって無効にできます。

モバイルダッシュボードからルールを無効にする方法を学ぶ。

概要

このルールは、VoiceOverを利用する視覚ユーザーに中程度の影響を与えます
VoiceOverのフォーカスボックスは、アナウンスする要素の画面上の枠に合わせる必要があります
可能であれば使用を避けてください accessibilityPath または accessibilityFrame - VoiceOverは正しいフレームを自動的に計算します
フレームを上書きする必要がある場合、要素が移動するたびに座標を再計算してください（スクロール時など）

ユーザーへの影響

VoiceOverも使用する視覚ユーザーが最も影響を受けます。VoiceOverは画面上の要素の詳細をアナウンスしますが、フォーカスボックスはアナウンスされている要素の一部または全部の外側に表示されます。発言内容と見えるハイライトの間に不一致があるため、フォローし理解することが難しくなります。

A11y要素フォーカスボックスの問題を確認する

VoiceOverをオンにする
要素をフォーカスする
次のいずれかが発生します：
- アクセス不能：VoiceOverのフォーカスボックスが要素を部分的に含む
- アクセス不能：VoiceOverのフォーカスボックスが要素を全く含んでいない
- アクセス可能：VoiceOverのフォーカスボックスが要素を完全に含む

問題を修正する

このルールにより見つかった問題は、ほとんどの場合、 accessibilityPath または accessibilityFrameの誤使用によって引き起こされます。最も安全な方法はこれらを削除し、VoiceOverにフォーカスボックスを自動的に計算させることです。カスタムフレームが必要な場合、位置が変わるたびにルート要素に対して座標を再計算する必要があります。

UIKit

要素に対して accessibilityPath または accessibilityFrame を誤って使用すると、このルールで問題とされます。次の2つの方法のいずれかで修正してください：

必要がない場合は accessibilityPath または accessibilityFrame を削除してください。VoiceOverは画面上の座標を自動的に計算し、正しいフォーカスボックスを描画します。
フレームを上書きする必要がある場合は、要素のフレームをルートビュー座標に変換し、要素が移動するたびにパスを再割り当てしてください（例： UIScrollviewの場合）：

// Assuming we are in a ViewController
let button = UIButton()

// If not within a ViewController, self.view should be replaced with the rootView of the screen
let rootview = self.view
let onScreenFrame = button.superview!.convert(button.frame, to: rootview)
button.accessibilityPath = UIBezierPath(rect: onScreenFrame)

SwiftUI

この種のアクセシビリティの問題は、SwiftUIビュー内では発生しないと予想されます。

React Native

デフォルトのTouchableまたはPressable要素では、この種のアクセシビリティの問題は発生しないと予想されます。

他のタイプの要素にフォーカスを追加する場合は、その要素に直接 accessible と accessibilityElementsHidden のプロパティを設定してください：

<Image
   source={DequeLogo}
   accessible={true}
   accessibilityElementsHidden={false}
   accessibilityLabel="Deque Systems Logo"
   accessibilityRole="image"
   style={{ width: 100, height: 60 }}
   resizeMode='center'
/>

要素が含むビュー内にグループ化されている場合は、そのビュー上に Viewと accessible のプロパティを設定してください： accessibilityElementsHidden している場合は、そのビュー上に

<View
  style={styles.rowContainer}
  accessible={true}
  accessibilityElementsHidden={false}
  accessibilityLabel="Dark Mode"
  accessibilityValue={{ text: "" + secondSwitchIsEnabled }}
  accessibilityRole="switch"
  onTouchStart={() => {
    setSecondSwitchIsEnabled(!secondSwitchIsEnabled)
  }}>
    <Text style={{ fontSize: 18 }}>Dark Mode</Text>
    <Switch
        style={styles.standardSwitch}
        importantForAccessibility='no-hide-descendants'
        value={secondSwitchIsEnabled}
        onValueChange={() => {
          setSecondSwitchIsEnabled(!secondSwitchIsEnabled);
        }}
    />
</View>

このルールを無視できますか？

A11y Element Focus Boxは、ユーザーに対して中程度の影響があります。これはベストプラクティスとしてのルールであるため、モバイルダッシュボードからオフにしたり、個別のテストで抑制することができます。しかし、視覚を持つVoiceOverユーザーにとっては焦点ボックスの位置がずれていると混乱を招き、原因が誤設定の場合は修正する価値があります。 accessibilityPath 、 accessibilityFrameです。「ルールの無視」について詳しく学ぶには、こちらを参照してください。

リソース

Deque Universityのコースページ

注意：Deque Universityのリソースにフルアクセスするには、サブスクリプションが必要です。

その他のリソース

Webコンテンツ・アクセシビリティ・ガイドライン (WCAG) 2.1、W3C勧告
- 成功基準 2.4.7 - フォーカスの可視性
Apple開発者ドキュメント
- accessibilityFrame
- accessibilityPath