Follow

Keep Up to Date with the Most Important News

By pressing the Subscribe button, you confirm that you have read and are agreeing to our Privacy Policy and Terms of Use
Contact

accessibilityShowButtonShapes Deprecated: What’s Next?

accessibilityShowButtonShapes is deprecated – discover how to handle iOS accessibility with glassEffect and new environment values.
Split-screen iPhone UI showing deprecated accessibilityShowButtonShapes conflict with modern glassEffect in SwiftUI Split-screen iPhone UI showing deprecated accessibilityShowButtonShapes conflict with modern glassEffect in SwiftUI
  • 🔄 Apple deprecated .accessibilityShowButtonShapes in iOS 17, urging developers to use contextual environment values.
  • 🧠 Users with visual impairments rely on shape, contrast, and clear cues more than decorative UI effects.
  • ⚠️ Modern effects like .glassEffect() can reduce clarity unless conditionally adapted for accessibility.
  • 💡 Environment values like accessibilityDifferentiateWithoutColor help create adaptive UIs resistant to future changes.
  • 📱 Developers are encouraged to simulate multiple accessibility configurations during testing.

Accessibility and Modern UI — A Balancing Act

Making modern SwiftUI apps look good and work for everyone is a challenge for iOS developers. Apple updates its accessibility ideas with each iOS version. This means developers must make UIs that adapt well and serve all users, especially since iOS accessibility settings are getting stronger. For example, Apple removed .accessibilityShowButtonShapes in iOS 17. This shows a shift towards interface actions that respond to what users need on different devices and with different abilities. We will look at what this change means and how to make your designs last.


Understanding .accessibilityShowButtonShapes Removal

In the past, .accessibilityShowButtonShapes let developers easily show button outlines when a user wanted them. This visual hint helped people with trouble seeing or thinking tell which UI parts they could interact with and which were just for show.

But with iOS 17, Apple no longer supports this value (Apple Documentation, 2023). Apple wants developers to use designs that know what users need and respond to different situations, instead of just saying "show button shapes." This fits with the platform's goal to make accessibility features work on their own, without developers doing extra steps.

MEDevel.com: Open-source for Healthcare and Education

Collecting and validating open-source software for healthcare, education, enterprise, development, medical imaging, medical records, and digital pathology.

Visit Medevel

Why the Change?

Apple is pushing for automatic accessibility. This means the system controls how the interface adapts, and developers focus on making things clear and giving them clear meaning. The old way asked developers to write UI code based on toggles. The new way encourages using changing values like accessibilityDifferentiateWithoutColor or accessibilityContrast. These show many different user accessibility needs.

This change means developers cannot assume users will turn on specific visibility options. Instead, they must use UI methods that adapt in a full way.


How iOS Accessibility Settings Impact SwiftUI Views

iOS accessibility settings work closely with how SwiftUI renders views. These settings are not just small visual changes. They affect how SwiftUI draws, animates, and arranges content. Some settings that are on at the system level pass down through the view setup using EnvironmentValues. This allows for very adaptive behavior.

Common Accessibility Environment Values in SwiftUI:

  • Bold Text (.accessibilityBoldTextEnabled)
    Turns on bold fonts everywhere in the system. Designers must make sure layouts can handle text growing. If not, text might get cut off or overlap.

  • Reduce Motion (.accessibilityReduceMotion)
    Cuts down on animations, transitions, and moving effects for users who get sick from motion. View modifiers like .animation() should react to this when needed.

  • Increase Contrast (.accessibilityContrast)
    Makes the difference between text and background stronger to make reading easier. This is a key hint when making layered or see-through UIs.

  • Differentiate Without Color (.accessibilityDifferentiateWithoutColor)
    Uses hints other than color for status changes, actions, or checks. For example, adding shapes or underlines instead of only using text color.

  • Reduce Transparency (.accessibilityReduceTransparency)
    Turns off or lowers visual effects like blur and opacity that can hide important content.

You can get each of these environment values in SwiftUI using the @Environment property wrapper. This lets you easily use them in view logic that responds to changes.


The Role of .glassEffect() in UI Modernization

The .glassEffect() feature came out as a way to add material design styles to SwiftUI. It makes controls and views appear translucent, like frosted glass. This adds depth and a pleasant look, which is good for current app interfaces.

But these visual effects have downsides. For users who need clear visuals more than fancy ones, this "frosted" look can hide content, lower contrast, or make it hard to tell what a user can do.

Why Glass Isn’t Always Clear

  • 💡 Glass effects use blur, brightness, and how things are layered. All of these become issues with accessibility settings like higher contrast or less transparency.
  • 🧑‍🦯 Users with low vision might not easily see a button on a frosted background if the button shapes are not clear.
  • ⚠️ When placed over busy content (like lists, pictures, or gradients), .glassEffect() might not show users what they can interact with.

Tip for Designers:

Do not think .glassEffect() can be the main background in parts of the UI that users interact with often. Instead, create backup options that change based on accessibility settings.


Replacing Removed Environment Values — The Right Way

The removal of .accessibilityShowButtonShapes shows a bigger change: your UI should respond to accessibility features in a higher-level way. Luckily, SwiftUI gives you many environment keys that support this new responsive design approach.

Use accessibilityDifferentiateWithoutColor

This environment value helps more than just color-blind users. It is an important tool for making any visual difference clearer for all users. You can use it to add borders, outlines, backgrounds, shadows, and even animated hints.

@Environment(\.accessibilityDifferentiateWithoutColor) private var shouldDifferentiate

var body: some View {
    Button("Confirm") {
        // Do something
    }
    .padding(12)
    .background(shouldDifferentiate ? Color.indigo : Color.clear)
    .overlay(
        RoundedRectangle(cornerRadius: 10)
            .stroke(shouldDifferentiate ? Color.indigo : Color.clear, lineWidth: 2)
    )
}

This separates your design from old flags. It lets the system show when more hints are needed. This keeps your structure clean and ready for the future.


Detecting System Preferences Without Old Flags

Watching several environment values helps you create a complete response to different accessibility preferences. Think of each value as a way your UI must still work and be easy to read.

Key Adaptive Environment Values:

  • @Environment(\.accessibilityDifferentiateWithoutColor) var differentiate
  • @Environment(\.accessibilityBoldText) var boldText
  • @Environment(\.accessibilityReduceMotion) var reduceMotion
  • @Environment(\.accessibilityReduceTransparency) var reduceTransparency
  • @Environment(\.accessibilityContrast) var contrastMode

By using these together, you can set up actions that change styling when accessibility needs more clarity.

Here is some code that shows how to do some of the things the old "button shape" logic did:

@Environment(\.accessibilityDifferentiateWithoutColor) var differentiate

var body: some View {
    Text("Tap Me")
        .padding()
        .background(differentiate ? Color.gray : Color.clear)
        .overlay(
            RoundedRectangle(cornerRadius: 8)
                .stroke(differentiate ? Color.primary : Color.clear, lineWidth: 2)
        )
}

Designing Accessible UI with Visual Effects in Mind

Designing a clear interface does not mean it has to be boring. It means layouts that are easy to understand and behavior that is predictable. What something looks like must help with how easy it is to use.

Visual Elements That Are Good for Accessibility:

  1. Shapes & Outlines: Use clear shapes to show users they can interact with something. Capsules and rounded rectangles work well.
  2. Shadows: Drop shadows can separate layers on screen. This works even for users who only see in black and white.
  3. Patterns: When color is off or lessened, textures or patterns (like haptics) can show active areas.
  4. Fill Styles That Use Contrast Well: Do not only use blur or opacity. Make sure the contrast is strong enough to meet WCAG (Web Content Accessibility Guidelines) rules.

Other Visuals for .glassEffect()

Instead of always using a frosted glass effect, use solid but see-through colors. Or, give users a way to make visuals simpler when accessibility mode is on:

if reduceTransparency {
    Color(.secondarySystemBackground)
} else {
    Color.clear
        .background(.ultraThinMaterial)
}

Managing Conflicts: Glass, Blur, and Button Cues

Here are some common UI problems that happen when accessibility settings are on:

Common Problems

  • Transparency vs. Contrast: Glass effects make it harder for users who need high contrast to see.
  • Blur + Flat Content: Buttons do not stand out on busy backgrounds.
  • Hover Effects Without Shape: Effects used without a clear shape do not show that something is interactive.

Ways To Fix This

  • Make outlines based on shapes as backup UI layers.
  • Use solid backgrounds for buttons on views with a lot of blur.
  • Add hover/click hints using haptic or scale animations. These can be turned off if reduceMotion is on.
if differentiateWithoutColor {
    button
        .background(Color.secondary)
        .overlay(RoundedRectangle(cornerRadius: 6).stroke(Color.primary, lineWidth: 2))
} else {
    button
        .glassEffect()
}

Testing for Accessibility Compliance

If you do not test, you can only guess if your accessible interface truly works. Testing makes sure your layout works for many different user needs.

Good Ways To Test

  • Accessibility Inspector (Xcode): Try out settings like Bold Text, Reduce Motion, VoiceOver, and others.
  • System Settings Testing: Put your app on real or fake devices and turn Accessibility settings on and off there.
  • VoiceOver Walkthroughs: Use VoiceOver to try out your app. Are all buttons named? Is moving around predictable?
  • Text Size Test: Set the text size to the biggest option. Then check for cut-off text, scrolling issues, and hidden parts.

🔥 iOS Dev Weekly says developers should test at least three configurations for each big feature. Do this before your code is released.


Strategies To Make SwiftUI Accessibility Last

SwiftUI changes every year. Because of this, hardcoded visuals will break easily. Use declarative and reactive layout methods. This will make them last longer.

How to Make Your Designs Last:

  • ✅ Do not use old environment values like .accessibilityShowButtonShapes.
  • ✅ Use modifiers and symbols that make sense (like .buttonStyle() or .labelStyle()).
  • ✅ Think of Environment as the start of all display choices.
  • ✅ Make sure to build clear order and clear roles for things (for example, use Button, not Text + onTapGesture).
  • ✅ Read Apple’s Human Interface Accessibility Guidelines often.

Devsolus Community Tips

Smart SwiftUI developers build apps that work well for everyone. Here is what they suggest:

Accessibility Modifiers You Can Reuse

struct AccessibleButtonOutline: ViewModifier {
    @Environment(\.accessibilityDifferentiateWithoutColor) var differentiate

    func body(content: Content) -> some View {
        content
            .overlay(
                RoundedRectangle(cornerRadius: 6)
                    .stroke(differentiate ? Color.accentColor : Color.clear, lineWidth: 2)
            )
    }
}

🎯 Use it everywhere:

Button("Save") {
    // Action
}
.modifier(AccessibleButtonOutline())

More Tips

  • Test on All Devices: Accessibility works differently on iPhone and iPad. Test on both.
  • Focus on Structure, Not Screenshots: Design how things work, not just how they appear.
  • Design for the Hardest Case: What if color, motion, transparency, and size are all gone? Can your app still be used?

Designing with Confidence for Everyone

When Apple removed .accessibilityShowButtonShapes, it did not mark an end. Instead, it showed a new way of making UI designs that adapt and have clear meaning in SwiftUI. Do not just code for specific toggles. Instead, use what the environment tells you. Build with every user in mind. This includes people who do not see or use screens in the same way. And when you do this, you will not just follow iOS accessibility rules. You will make apps that are truly welcoming to everyone who uses them.


Citations

Apple Developer Documentation. (2023). .accessibilityShowButtonShapes

Apple Human Interface Guidelines. (2023). Accessibility – iOS

iOS Dev Weekly. (2023). Handling Conflicting Accessibility Requirements in SwiftUI

Add a comment

Leave a Reply

Keep Up to Date with the Most Important News

By pressing the Subscribe button, you confirm that you have read and are agreeing to our Privacy Policy and Terms of Use

Discover more from Dev solutions

Subscribe now to keep reading and get access to the full archive.

Continue reading