Advanced (Undocumented) iOS accessibility techniques (iOSDevUK, September 2019)
•Als PPTX, PDF herunterladen•
0 gefällt mir•296 views
Perhaps you know some accessibility basics, but what about the more advanced stuff? iOS provides a powerful API for creating accessible user experiences, and some implementations certainly have their quirks. This talk covers this trickier end of the spectrum.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Empfohlen
Empfohlen (20)
Advanced (Undocumented) iOS accessibility techniques (iOSDevUK, September 2019)
- 1. iOSDevUK 4 September 2019 Jon Gibbins .j { } Dotjay Ltd
- 2. iOSDevUK 4 September 2019 Jonny I’ve no idea why I’m doing this! .j { } Dotjay Ltd
- 3. iOSDevUK 4 September 2019 Jonny I’ve no idea why I’m doing this! .j { } Dotjay Ltd
- 10. Source: Giphy
- 12. 👨👩👧👧
- 13. 👨👩👧👧 + (age < 5)
- 14. 👨👩👧👧 + (age < 5) + ⏰ @ 4am
- 15. Source: Giphy 👨👩👧👧 + (age < 5) + ⏰ @ 4am =
- 16. Source: Giphy
- 18. Source: Giphy
- 36. accessoryView
- 40. • • • • 40
- 41. • • • • • 41
- 43. • • • • • 43
- 59. …you do
- 60. …you do …or Google does
- 61. …you do …or Google does …sometimes
- 62. • • • • • •
- 64. Photo credits: LG, Gould, Larson, DiC, Apple
- 66. Photo credit: Jon Gibbins with thanks to Drake Music Project
- 67. “Getting your own experience of accessibility helps you to put yourself in the shoes of others and keep accessibility in mind when building and testing your sites and applications” – Jon Gibbins, Nov 2007
- 68. 68
- 69. Experiencing digital accessibility using your smartphone https://tinyurl.com/yy7mnppu
Hinweis der Redaktion
- I’m a digital accessibility consultant on web and mobile. My name is Jon Gibbins.
- Except I’ve changed my name to… Jonny I’ve no idea why I’m doing this!
- And I’ve decided I can equally rename this talk: “Undocumented iOS accessibility techniques” (which actually takes the pressure off a bit compared to “Advanced iOS accessibility techniques”)
- Who loves working with iOS?
- Who hates working with iOS? …I’m hoping for some honest people who raise their hands to both of those questions.
- Who has done some level of coding for accessibility?
- I’m up here on stage and I’m accessibility angel, right?
- Well, I’ve got a confession to make.
- I’m always saying, “accessibility is easy.”
- But when I’m trying to get the accessibility techniques I know work to work
- I find myself swearing at my computer
- And I have 2 beautiful little female humans back home…
- …under the age of 5…
- …who like to wake me up at some unholy hour…
- …so I’m like kinda sleepy…
- …but I’m in the zone… …and then…
- Boom!
- And I throw my computer across the room!
- Sometimes accessibility is frustrating even for me.
- This talk is a bit intimidating for me. You guys are all iOS devs.
- I am not an iOS developer. I have developed on several platforms, Web mainly. But I'm an accessibility nerd. And have worked with iOS code since version 6. I’ve done a lot of app testing with accessibility features. By the time I get to an app is typically too late in the day. Clients tend to want accessibility tested and not baked into their process. And they tend to not let you at their codebase. I mostly see your app as a black box making it difficult to debug and diagnose issues. So my work is often exploratory. Sometimes it's guess work.
- But I’m here to say that accessibility is easy… …in theory.
- It's the implementation that can be frustrating. Because it's not well documented. WWDC videos are great, practical sources on iOS accessibility information. But the platform evolves. The advice and code examples goes out of date.
- I can’t go much further without talking about SwiftUI. As Rob said in his talk: SwiftUI will bring improvements to the accessibility baseline of your apps. What I'm going to talk about is UIKit. So it will go somewhat out of date once SwiftUI becomes the norm in the coming years. But I’m certain we'll still see some of the same problems we've seen in accessibility for decades. Because I feel like accessibility is still quite “opt in” in SwiftUI. “You can do it doesn't mean you do it” Accessibility often gets forgotten about. I hope Rob's right about SwiftUI making accessibility easier to implement and that we will see improvements.
- Seen loads of talks cover the basics so I won’t dwell on them. accessibilityLabel Traits To cover just a few common issues…
- Missing accessibilityLabel accessibilityLabel classes as “you can do it doesn't mean you do it” Inappropriate accessibilityLabel You can still describe an image button instead of using a verb. So to borrow Rob’s example from this morning: Setting a label of “heart” instead of “like”.
- Missing or incorrect accessibilityTraits Setting user’s expectations of your UI behaviours, state information, etc. Related to this: Making images as “decorative“ is another “you can do it doesn't mean you do it”
- Hidden elements receiving focus If off-screen elements are receiving focus, check: isAccessibilityElement layoutChangedNotification screenChangedNotification
- Poor focus management This one can be tricky, but this first things to check are… If focus does not move to a new screen, likely that a screen changed notification has not been fired. If focus does not move to a modal, likely that a layout changed notification has not been fired.
- Moving on from those basics, though. I’ve chosen a few of the most quirky implementations and techniques I've worked on. Stuff that’s either poorly documented or are not obvious where accessibility is concerned. I won’t have time today to live code everything, but I'll try to do some.
- Let’s start with an easy example: UISwitch
- I see custom switches like this occasionally. UISwitch is designed to work together with UITableViewCell. Without the TableViewCell, it’s hard to make accessible, but not impossible.
- You start with a switch…
- …and you add a label. But that’s not enough to make it work…
- …you set the switch as the UITableViewCell’s accessoryView.
- Much like the anatomy of an HTML checkbox. When this is done, the control provides several accessibility enhancements automatically: 1. The row's label text (or accessibilityLabel property) is associated with the UISwitch. 2. The whole row becomes a tappable area, rather than just the UISwitch frame. 3. The on/off state of the switch is conveyed to VoiceOver. This also establishes a standard layout for switch controls, where the UISwitch is positioned to the right hand side of the label text, which helps to avoid confusion for users. Rob mentioned the idea of Semantic Views this morning. This is an example of a single accessibility element being responsible for communicating accessibility information of multiple UI elements.
- Many basic issues come down to a lack of understanding of accessibility foundations.
- A dialog takes place between an application and assistive technology.
- Apple sometimes refer to this as the Accessibility User Interface.
- Since role / state is handled by the standard UIKit components, ensuring appropriate accessibilityLabel properties are set is the main bulk of the work.
- accessibilityElements can be used to reorder elements within an accessibility container view, or to completely customise the experience for users of accessibility features. accessibilityFrame has its quirks and operates better as a method override than a property that you set.
- There are some confusing recommendations in the iOS Human Interface Guidelines. For example, they suggest that using accessibilityHint is adequate for labelling fields, but relying on hint alone presents accessibility issues. In Apple’s own apps, UIAlertView tends to be used for errors. Designers tend not to like that, so error strings appear on the screen next to fields (like with Apple Pay) where they tend not to be easy for VoiceOver users to identify and understand because they haven’t been coded with accessibility in mind.
- 1. Initial awareness Ensure user is immediately aware there is a message. This may be visually indicated using a message that is out of context. This can be made accessible using UIAccessibility.Notification.announcement. 2. Form error summary When a user reaches a form, it is helpful to summarily indicate that there are errors in the form. Depending on the length of the form, this may be as simple as informing the user of the number of errors, or as much as a list of the errors. For short forms of just a few fields, this is unnecessary. 3. Form control error state Each individual form control must indicate that it is in an error state and clearly inform the user what the error is in text by appending it to the accessibilityLabel.
- For websites, you are encouraged to use an aria-describedby relationship to connect error message text to a form control so that assistive software knows to connect these UI elements. In iOS, this relationship is most akin to accessibilityHint. However, hints can be switched off by users, so do not rely on them for essential information or messages.
- Don’t just be the accessibility person Shared responsibility Raise awareness Teach Learn
- Think about accessibility as early as possible Bake it into your process, wireframes, etc. Fix accessibility before it hits the screens Documenting accessibility as you go will help future iterations Accessibility more likely to: get baked into prototypes persist through development make it into production at an acceptable level
- Accessibility in continuous integration: code linting, checks as part of release procedures, etc. BS 8878 Not a set of development guidelines Project management roadmap for ensuring that web products are built in an accessible way
- I think disability is difficult for some people to think or talk about. I think this is down to poor understanding, social stigmas, lack of experience.
- You know your work better than I do. You understand the context better than I do. You are better placed to find solutions. I can guide you, but it’s better if you can teach yourself.
- When I started as an engineer in the late 90s, my mentor told me that being an engineer was not about knowing everything. It’s about knowing what to look up and where.
- As I said, some things are not well documented. (Which I hope to change soon!)
- Solutions are contextual – accessibility is contextual. Context is King, especially on mobile. It’s not necessarily about what you know; it’s about knowing what to look up and where.
- Why is getting your own experience important? Passionate about accessibility – why? I don’t have a disability as such (wears glasses, APD, bad back) Let me tell you the story of my journey to working with accessibility in mind
- Jon’s earliest experience of “geek” Smart watches / phones: Jon first saw these in a book in the 80s and thought, “Woah, that’s pretty cool!” Technology is cool! But also enabling! LG watch phone: 1.3 inch full touch screen, 3G+ connectivity, video call capabilities, Voice recognition software, Bluetooth v2.1 with A2DP, MP3 player.
- Jon’s first experience of accessibility – a talking clock used by his blind mother.
- Jon has a passion for music. He plays guitar, sings, writes songs… At university, he got to work with disabled musicians to develop accessible music composition and performance software. The point is that we need to think outside the box a little. We need to find ways to empathise.
- November 2007 Started assembling my accessibility video tour. Needs updating, but still helpful to understand how the technology is used. https://lab.dotjay.com/notes/assistive-technology/videos/
- After all, digital technology should be for everyone.
- Check out my talk at Bristol ID&D in June 2019 for more on this.
- Questions?
- I have free copies of the Mobile Developer’s Guide to the Galaxy to give away.