cvs-health/ios-swiftui-accessibility-techniques

Demonstrates iOS SwiftUI Accessibility programming techniques using live good and bad examples that can be tested with VoiceOver and other AT. Includes documentation for developers explaining how to code accessible patterns for iOS.

iOS SwiftUI Accessibility Techniques

iOS SwiftUI sample code demonstrating a variety of good and bad accessibility coding techniques.

Demonstrates accessibility techniques for iOS SwiftUI apps using a collection of good and bad examples that can be tested with VoiceOver and other iOS assistive technologies.

Explains how to apply WCAG to iOS SwiftUI apps.

Using the app with VoiceOver and other iOS assistive technologies will demonstrate the right and wrong ways of applying accessibility to a SwiftUI app.

Download iOS app from the AppStore.

Read the blog post, Announcing the iOS SwiftUI Accessibility Techniques Open Source Project.

Review the project source code to see how to apply the accessibility techniques in working SwiftUI code examples.

Documentation files for each technique are listed below.

Topics

• = Completed
• Images
  • Informative
  • Decorative
  • Functional
• Headings
• Page Titles
• Announcements
  • Accessibility Notifications
  • Error Validation
• Reading Order
• Focus Management
• Accessibility UX Enhancements
  • Actions
  • Adjustable Action
  • Attributed Strings
  • Assistive Access
  • Assistive Technology Detection
  • Escape
  • Input Labels
  • Large Content Viewer
  • Magic Tap
  • Rotor
  • VoiceOver Pronunciation
• Dynamic Type
• Language
• UI Controls
  • Accordions
  • Alerts
  • Buttons
  • Checkboxes
  • Confirmation Dialogs
  • Date & Time Pickers
  • Grouping Controls
  • Input Instructions
  • Links
  • Menus
  • Pickers
  • Popovers
  • Search Suggestions
  • Segmented Controls
  • Sheets
  • Sliders
  • Steppers
  • Radio Buttons
  • Tabs
  • Text Fields
  • Toggles
• Navigation
• Data Tables
• Lists
• Cards
• Charts
• Touch Target Size
• Responding to User Accessibility Preferences
  • Dark Mode
  • Increase Contrast
  • Reduce Motion
  • Reduce Transparency
  • Smart Invert
• Progress Indicators
• Accessibility Representation Custom Controls
• Meaningful Accessible Names
• Combining Focus
• Device Orientation
• Scroll Views
• Accessibility Hidden
• Siri Shortcuts

Contributor Guide

1. Before contributing to this CVS Health sponsored project, you will need to sign the associated Contributor License Agreement.
2. See contributing page.

License

iOS SwiftUI Accessibility Techniques is licensed under under the Apache License, Version 2.0. See LICENSE file for more information.

Copyright 2023-2024 CVS Health and/or one of its affiliates

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

See the License for the specific language governing permissions and limitations under the License.

ios-swiftui-accessibility-techniques's Issues

.accessibilityHeadingLevel and VoiceOver support

Earlier today, I came across a question about heading level support on iOS in the #native-mobile channel on web-a11y.slack.com.

In the thread, "Genevieve" says

I just tested adding iOS heading levels in swift app and VO announced them. Fantastic! I didn't know we had this available

If this heading level VoiceOver support can be reproduced, I propose the following updates:

• Update Headings markdown documentation to reflect that .accessibilityHeadingLevel is now supported by VoiceOver
• Update Headings technique to include good/bad example of implementing heading levels

Error Validation: use .accessibilityValue matching the visible error message text for each invalid input

IMO, .accessibilityValue is another valid technique to expose an input's helper text and error message. Unlike .accessibilityHint, I don't think users can disable the announcement of an element's .accessibilityValue. This is why I think using .accessibilityValue may be a more robust approach.

My recommendation is to update the Error Validation coding technique (and associated documentation page) to include a "good" example that demonstrates how to use .accessibilityValue.

Add explainer on accessibility testing using XCTest

There are fantastic examples in this repo of using XCTest to perform accessibility related UI tests. I think it would be helpful to provide an overview in a separate markdown file that people can read before diving in to get a high level understanding of this topic.

This explainer could cover things like:

• types of issues can you check for: missing labels for elements, lack of support for Dynamic Type, asserting existence of specific semantic accessibility properties/modifiers, etc.
• key APIs used when writing tests
• related resources like the following WWDC video: https://developer.apple.com/videos/play/wwdc2023/10035/

Documentation files do not link to associated coding technique

I noticed that the "Error Validation" documentation file does not contain a link to the associated coding technique. I think providing a link in the documentation file would make the relevant code easier to discover and navigate to. If others agree, I could help update the documentation files accordingly. Thanks!

Accessibility Hints on Data Table rows

The data tables documentation is awesome! The only thing I hesitate on is the use of an .accessibilityHint to convey row/column information. The only reason I say that is because there are still users who choose to have hints turned off.

The feedback I have gotten from VoiceOver users is to include the association of header and row within the label for each item.
That way whether hints are turn on/off it is conveyed. Now this does cause other potential issues such as overriding the text of the item in the cell or labels being super long.

Just as a note, I do not condone having the label say "Row " or "Column <xyz". Same as what you got documented :)

Accordions, HEADING role.

Just like in web we expect accordions to have heading role. For disclosure group, we can achieve this by .accessibilityElement(children: .contain)
and then .accessibilityLabel("The disclosure group text").

This will add the heading role, to the disclosure group.

Tab Bar - Badges.

I think having badges example in tabitem would add some good value. As, most homepages that will use tab bar will use the badges to indicate notifications or new information/updates.

in the AccessibilityRepresentationView, the sliding Circle in the CustomSlider can be dragged to values less than 0 and greater than 100

bug aside, this app is wonderful! big thank you to the maintainers :)