Some people have been asking me to keep going with #365DaysIOSAccessibility, and I will! I promise!
But the other big ask was to have them all in one place. So here they are, in their new home:
accessibilityupto11.com/365-days-ios...
There's an RSS feed you can subscribe to.
#iOSAccessibility
Calendar of Advent of iOS Accessibility. Day 22. Dynamic Type Support. The Mastodon app in two sizes, the default one (large) and the fifth accessibility text size (the largest). Some things you can do to support dynamic type: support it even when using custom fonts, save asset's vectorial data, scale icons and buttons too, adjust sizes automatically, tweak the layout if necessary, implement large content viewer. You can test in the SwiftUI variants preview, with the accessibility inspector, in the simulator, using environment overrides...
Day 22 - #adventOfIOSAccessibility. Make sure you support Dynamic Type up to the largest text size available. Take into account that there are five extra accessibility sizes available from the Accessibility Settings. It can make a huge difference for lots of users.
#365DaysIOSAccessibility
Calendar of Advent of iOS Accessibility. Day 21. Honoring users' settings. Display & Text Size Accessibility Settings Screen. There are two examples, Apple's podcast app playing an episode of Swift by Sundell and FaceTime. There are arrows pointing from some of these settings to how they take effect in these apps. When Reduce Transparency is on, in FaceTime you don't see the front camera being previewed and blurred in the background, instead, it is just opaque. When bold text is on, all text in both apps is bold. When Increase Contrast is on, the New FaceTime button is darker. When Button Shapes is on, the button for the podcast show or the playback speed (both consisting of just text with the app's tint color) is underlined so it is easier to be identified as buttons. The sleep timer button, which is an icon, gets some borders around it too. When smart invert is on, the artwork of the podcast doesn't get inverted.
Day 21 - #adventOfIOSAccessibility. There are a few accessibility settings you can check for, or get notifications in case these preferences change. This is especially important when developing custom components as they will mostly work with UIKit and SwiftUI controls.
#365DaysIOSAccessibility
Calendar of Advent of iOS Accessibility. Day 20. Reduce Motion. Three examples. In the App Store app, Apple sometimes has tiles with icons from apps or games that continuously moves for the user to get a sneak peek of all the icons. The second one is the Weather app, where there are quite realistic animations of the weather conditions in the background. The third one is the Stocks app. If you open one of your symbols, there is a banner at the top where your symbols keep automatically scrolling mimicking what you see on tv. In all these three cases, Apple completely stops the animations if Reduce Motion is on.
Day 20 - #adventOfIOSAccessibility. There is an option for the user to request an experience with Reduce Motion, and we should honor it. If your app has animations, make sure to check if the user has this setting on. Here are three examples where Apple does a great job.
#365DaysIOSAccessibility
Calendar of Advent of iOS Accessibility. Day 19. User input labels. One example shows Apple's Podcast app in the 13 letters podcast page. There is a button in the top right corner with a + icon. The default label is "Follow". That might not be everyone's first guess on how that button is named. You could add "Plus" and "Add" as alternative labels. The second example is some episodes of that same podcast. The default label is very long consisting of a few details about each episode like the publication date and title. That might be a bit long for Voice Control. You can use just the title, or the word "Episode" as possible input alternatives.
Day 19 - #adventOfIOSAccessibility. Accessibility labels might not be the best input labels, used for example to find or interact with elements with Voice Control or Full Keyboard Access. In those cases, you can provide accessibility user input labels.
#365DaysIOSAccessibility
Three examples of traversal order for three pieces of data in three columns. The first one says Followers and 550 underneath, the second one Following with 340 underneath, and the third one Posts with 750 underneath. In the first one, the order is: Followers, Following, Post, 550, 340, 750. This order is incoherent. For the second one, the order is: Followers, 550, Following, 340, Posts, 750. This one has a logical order. The third one's order is: Followers 550, Following 340, Posts 750. Where both name and number for each one of the pieces of data is grouped. It is clearer and the navigation is easier.
Day 17 - #adventOfIOSAccessibility. Check the traversal order of elements in your app. Sometimes the default top-left to bottom-right order might not be the most logical one. Sometimes you may consciously want to tweak the order. Other times, grouping is the answer.
#365DaysIOSAccessibility
Calendar of Advent of iOS Accessibility. Day 16. Multimodal information. One example shows an app where you need to introduce a 6-digit pin. When it is the wrong pin, it does a shake animation on the pin field. It is using one mode: animation. If reduce motion is enabled, or for VoiceOver users, this information will not be perceived. The second example shows the same app but it adds a warning icon and a message that says "Incorrect pin" in red and the device also vibrates and does a sound to indicate the error. It uses several modes: animation, iconography, messaging, color, sound, and haptics. This is preferred.
Day 16 - #adventOfIOSAccessibility. A reminder that the more modes we use to convey important information, the more sure we'll be that it will be perceived by all our users. Consider a combination. of color, icons, messages, sound, haptics, animations, etc.
#365DaysIOSAccessibility
Calendar of Advent of iOS Accessibility. Day 12. Failing to update the user of changes. Three examples over the Apple TV app on the Ted Lasso page. The first one has a hud saying “Episode added to Up Next”. Toasts, snackbars and huds can be conveyed to VoiceOver usersa using accessibility announcements. The second one is a drop down to select the season which changes the episodes visible in the carrousel underneath it. A layout changed notification can help with changing content in the screen. The third one shows an episode with a download indicator. The updates frequently trait could help with that.
Day 12 - #adventOfIOSAccessibility. Sometimes we may fail to update users of things changing on the screen in a perceivable way. Toasts and similar should be announced. We may want to make clear that some content on the screen changed or to update on a task's progress.
#365DaysIOSAccessibility
Calendar of Advent of iOS Accessibility. Day 11. Confusing custom modals. There is a groceries app. It has some text that says "Sorry, we don't deliver there yet" a search field, a search button, a text that says "or" and a login button. When presenting a modal view on top of it, VoiceOver still focuses through the elements of the previous screen. To avoid that with UIKit, you can set accessibilityViewIsModal to true for the modal view. With SwiftUI there is an accessibility trait for that, .isModal.
Day 11 - #adventOfIOSAccessibility. Have you ever seen VoiceOver randomly focusing on elements of the previous view when presenting a custom modal view? That can be fixed by letting the system know that the presented view is modal in terms of accessibility.
#365DaysIOSAccessibility
Calendar of Advent of iOS Accessibility. Day 10. Bad experience with toggles. Very often toggles or UISwitches are not grouped together with the label preceding them or lack of the right values, traits and hints. Three examples. With the first one VoiceOver just says "Shared accomodation" and it is not even actionable. The second one focuses first on the label and then on the switch. VoiceOver says "Event cancellations" and then "Switch button, on, doublet-tap to toggle setting". The third one does a similar thing but treats the switch as a button. VoiceOver says: "Like" and then "Button". All quite confusing. With UIKit you can configure your UISwitch as the accessoryView for a table view cell. With SwiftUI you can use a named Toggle that lets you specify an associated label.
Day 10 - #adventOfIOSAccessibility. Toggles or UISwitches are often found separated from the label that precedes (and describes) them; with an unclear label; missing a value, trait, or hint; or even not being actionable at all.
#365DaysIOSAccessibility
Calendar of Advent of iOS Accessibility. Day 9. Hidden actions not being accessible. Find alternative ways of actioning hidden interactions or that require complex gestures or gestures that conflict with VoiceOver's. Two examples. The first one is swiping left in a table view cell to unveil a delete option. That could be fixed by adding delete as a custom action. Second example is a bottom sheet menu with a grid of options. You need to swipe down to dismiss it. You'd probably need to implement the escape gesture for VoiceOver and it would be a good idea to add a close button anyway.
Day 9 - #adventOfIOSAccessibility. With interactions that are hidden, or require complex gestures to be performed, or that may conflict with VoiceOver, you need to provide alternative ways of executing these actions. Custom actions can help a lot of times, but not always.
#365DaysIOSAccessibility
Calendar of Advent of iOS Accessibility. Day 8. Inaccessible buttons within accessible views. Example of the Mastodon app. If we make the table view cell representing a post an accessible element so it is easier to navigate, the subviews, including the buttons, won't be accessible anymore. So how can a VoiceOver, Keyboard, Voice Control, or Switch Control user interact with them? Custom actions to the rescue. In SwiftUI there is a new modifier, since iOS 16, called accessibilityActions. Before, you had to add the actions one by one. In UIKit, there is an accessibilityCustomActions property, which is an array of UIAccessibilityCustomAction.
Day 8 - #adventOfIOSAccessibility. If a view has isAccessibilityElement to true, assistive tech won't look for any of its subviews. That means that if there are any buttons inside, they won't be accessible. You can add custom actions to be able to 'interact' with them.
#365DaysIOSAccessibility
Calendar of Advent of iOS Accessibility. Day 7. Grouping elements for easier navigation. There is an example using the Foursquare app. There is a list of restaurants. Each restaurant has a name, type, location, and rate. By default, you'd need four swipes to the right with VoiceOver to go from one restaurant to the next one. That's 32 swipes to go through 8 restaurants. If we group all these, it is just a single swipe to go from one item to the next one, easing navigation a lot. There is another example showing Next Door. The post in the example would require 9 swipes. So you can see how things can quickly get worse for more complex views. In that case, each post has a more options, like, reply, and share buttons that would repeat for every single item causing lots of redundancy.
Day 7 - #adventOfIOSAccessibility. Grouping elements when it makes sense can make a huge impact on easing navigation with some assistive technologies like VoiceOver, Switch Control, or Full Keyboard Access. It also helps on reducing redundancy.
#365DaysIOSAccessibility
Day 5 - #adventOfIOSAccessibility. Ensure images are either decorative or have descriptive accessibility labels to enhance user experience. #365DaysIOSAccessibility
Calendar of Advent of iOS Accessibility. Day 5. Images: with a description or decorative. iOS app with Disney+ showing the "How I met your mother" screen. The header has two images, one of them in the background, with the characters, that could be considered decorative. The other one is an image with the title of the series, which needs a description. In UIKit images are not accessible by default. So in the case of images that need to be accessible, you need to make the accessible elements. In SwiftUI images are by default accessible. You have an Image constructor with a decorative parameter, where you pass the name of the image.
Day 5 - #adventOfIOSAccessibility. Images should either be decorative or have a proper accessibility label or alt text that describes them. If they're decorative you can make it so they get skipped by assistive tech so it doesn't get in the way of the experience.
#365DaysIOSAccessibility
Calendar of Advent of iOS Accessibility. Day 4. Visual cues missing from VoiceOver's announcement. Four examples. The first one is a button with a person silhouette and a checkmark. VoiceOver announces it as "Collaborate, button". It is missing the fact that you are already collaborating with someone. Represented by the checkmark. Second example shows a tab with the title "Coming soon" and a badge with the number 6. VoiceOver announces it as "Coming soon, Tab 2 of 5". It is not conveying that there are 6 new movies and shows. Represented by the badge. Third example shows a chart's title: "Daily Average 1h 55m", an arrow pointing down, and "55% from last week". VoiceOver says "Daily average, one hour fifty-five minutes. 55% from last week". The user wouldn't know if it went up or down. Represented by the arrow pointing down. Fourth example, episode download. The stop button is surrounded by circular progress bar. VoiceOver says "Stop downloads, button" but not how much is left.
Day 4 - #adventOfIOSAccessibility. Important information is often conveyed visually through icons, badges, or progress bars... These details can easily be overlooked. Please make sure they're part of your UI's components' accessibility labels or values.
#365DaysIOSAccessibility
Calendar of Advent of iOS Accessibility. Day 3. Missing header trait for headings. BBC News app shows two sections Technology and Science & Environment. These sections consist of a horizontally scrollable carrousel of at least 5 elements. If the titles of the sections have the header trait, a single swipe down brings you from one section to the other, compared to 6 swipes to the right needed otherwise. At the top of the app, there's the BBC logo. Screens should start with a heading so the logo could also have the header trait. In UIKit you can insert the header accessibility trait to the accessibilityTraits property of the UI element representing the heading. In SwiftUI, you can use the accessibilityAddTraits modifier and pass isHeader as parameter.
Day 3 - #adventOfIOSAccessibility. Anything representing a heading in the app should have the header trait. It allows for a faster way of exploring a screen and quickly jumping to the part of the app you are interested in. Screens should also start with a header. #365DaysIOSAccessibility
Calendar of the Advent of iOS Accessibility. Day 2. Better accessibility labels. A music player with some examples of how to improve your accessibility labels. Don't add the element type: for the like button, if the label is "Like button", VoiceOver will say "Like button, button". So just "Like" is perfectly fine. Avoid redundancy and verbosity. For the repeat button, the label "Repeat This is the last time from Kean" would be too long, and if we specify the song and band for every action, it would be too verbose. Localize. For the next track button, try to use a localized string instead of a plain string so VoiceOver speaks in the correct language. Start with a capital letter and don't end with a period. This helps with VoiceOver's inflection.
Day 2 - #adventOfIOSAccessibility. Some recommendations for improving your accessibility labels: don't add the element type, avoid redundancy and verbosity, localize...
#365DaysIOSAccessibility
Calendar of the Advent of iOS Accessibility. Day 1 crossed in a calendar with Santa Klaus above it. Buttons with no labels (especially buttons with an icon, but no title). Button with a bell, that intends to let the user see the notifications. If the button has no accessibility label, VoiceOver could say things like: button, bellIcon, possibly notification... far from ideal! A good accessibility label would be "Notifications". In UIKit, you can just assign a localized string to the accessibilityLabel property for the button. In SwiftUI, you can use the accessibilityLabel modifier and pass in a Localized String Key.
Day 1 - #adventOfIOSAccessibility. One of the accessibility issues I see more often in iOS apps, believe it or not, is unlabelled elements. This happens especially for buttons with an icon but no title. In those cases, you need to configure an accessibility label manually.
#365DaysIOSAccessibility
