Focus vs A11y Focus


Two phones side by side. One demonstrating Switch Control focus, the other showing accessibility focus: hello there!
Focus vs Accessibility Focus

Focus vs Accessibility Focus

One of the common areas of confusion for teams when communicating about accessibility is what focus means. It seems like a pretty simple term, but it can actually mean a few different things in different contexts.

In this post we will cover:

  1. The difference between Focus and Accessibility Focus.
  2. Why it matters and how to discuss about the users these technical terms impact.
  3. Other definitions of Focus you may come across and how they relate to these two foundational terms.

Input Focus

Let's talk about the definition that you're most likely accustomed to and this is Input Focus. Input Focus refers to the need for certain controls to accept input or interaction. Here are the types of things we'd expect to accept Input Focus, which is also what people, especially engineers, are generally referring to when they just say "focus". Focusable fields include:

  1. Buttons
  2. Switches
  3. Text Fields
  4. Controls with Custom Actions
  5. Custom Controls with Appropriate Tap Recognizers
  6. etc.

Essentially: Anything that the Operating Detects as something that is interactive will accept Input Focus. Same as hitting tab on a computer keyboard.

Accessibility Focus

Accessibility Focus refers to the need for certain Assistive Technologies to focus non-interactive controls in order to share information with users.

💡
This is often simplified to the less technical "TalkBack" or "VoiceOver" focus.

These are all fundamentally referring to the same thing, which is:

  1. The need for screen readers and braille boards to share information about non-interactive controls.

Controls that are only Accessibility Focusable include:

  1. Non-interactive images with AccessibilityLabel/ContentDescriptions
  2. Views that just contain text.

Implications

This means a few important things:

  1. All Input Focusable things are also Accessibility Focusable.
    1. User Point of View: Screen Readers should focus everything.
  2. Not all Accessibility Focusable things need to be Focusable.
    1. User Point of View: Switch Control should focus interactive things.

Number two trips people up very frequently and causes confusion for Keyboard and Switch users being able to focus things that they can't interact with. Unfortunately an article by a former Google Android Developer recommended utilizing the "Focusable" properties on text only views and that solution is the predominant recommendation for fixing View Hierarchy issues involving plain text Views. Sigh...

Anyway, if you come across engineers insisting this solution is necessary... feel free to share this post!

Featured Posts

SwiftUI Design Systems

Device and Text Size

Applying WCAG 2.2

iOS Accessibility Test Plan