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はボタンにフォーカスされていますが、 focus box appears offset - ボタンの可視範囲の一部外側

強調された領域がアナウンスされている要素と一致せず、視覚的なVoiceOverユーザーにとって追従が困難になります

正しい例 ✅

VoiceOverは同じボタンにフォーカスされており、 focus box fully contains the element's visual frame

強調された領域は、ユーザーが画面で見ているものと正確に一致し、視覚的なVoiceOverユーザーに対し何がフォーカスされているかをはっきりと示します

概要

このルールは、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要素フォーカスボックスには中程度の影響がありますがあります。これはベストプラクティスルールであるため、モバイルダッシュボードからオフにするか、個別のテストで抑制することができます。しかし、フォーカスボックスがずれていると、視覚的なVoiceOverユーザーにとって混乱を招く体験となり、accessibilityPathまたはaccessibilityFrameが誤って設定されている場合は修正する価値があります。こちらを参照してくださいについて詳しく学んでください。

リソース

Deque Universityのコースページ

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

その他のリソース

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