everything ▸ Tap targets should be no smaller than 44x44 points ▸ All text should have a minimum contrast ratio of 4.5:1 (http:// webaim.org/resources/contrastchecker/) ▸ Keep color schemes simple ▸ Never indicate meaningful content with color alone
to discover gestures ▸ Again, keep touch target sizes at/above 44x44 points ▸ Test your interface using switch control; a simple, hierarchical interface will play well with switch control ▸ Avoid screen clutter - favor navigation to clutter
Swipe items behind cells are “visible” to VO ▸ Grouping of items is poor ▸ Compose items aren’t labeled ▸ Doesn’t respond to back gesture. ▸ And much more…
NO for everything except UIControl objects and labels/text ▸ Setting to NO tells the Accessibility system recursively look at this elements subelements to find something that is accessible.
view ▸ A description of the view in (few) words. ▸ Defaults to the text already present (but sometimes this isn’t enough) CHRISCONNOLY REFRESH 9 MINUTES AGO
view ▸ Should never be the same as the label ▸ Should never be used to store “debug information” AIRPLANE MODE ON TRACK POSITION 1 MINUTE 17 SECONDS OF 4 MINUTES 45 SECONDS
the effect of interacting with the view is non-obvious ▸ Explains how to use costume / power-user gestures ▸ Can be disabled by users, so shouldn’t contain required content SOUND VOLUME 45 PERCENT. ADJUSTABLE. SWIPE UP OR DOWN WITH ONE FINGER TO ADJUST THE VALUE
system interacts with an elements ▸ Button trait will add the word “button” to the label of your element ▸ Link trait will add the word “link” to the label of of your element ▸ Summary trait tells VO where to go when the app launches
a bitmask and can be combined. ▸ Modifying traits in UIControls should always be done with |= unless you explicitly want to override a behavior ▸ Some traits have corresponding actions such as UIAccessibilityTraitAdjustable.
▸ Apps with a default nav bar will go back with this gesture ▸ Modals should dismiss with this gesture ▸ Generally maps to any “BACK” or “CLOSE” or “DISMISS”
two fingers ▸ In Springboard, this will play/pause music ▸ Generally maps to most common action in an App ▸ In Twitter, was configurable in settings to either offer Tweet Actions or go to Compose.
object with an adjustableTrait (single finger swipe up/down) ▸ accessibilityActivate is the default double-tap action. Only need to override if you are NOT behaving as a non-VO tap would ▸ accessibilityScroll handles a 3 finger swipe to trigger scrolling (generally)
have specific accessibility delegates ▸ UIPickerViewAccessibilityDelegate lets you a label/hint for each item in your picker. ▸ Useful for pickers with images ▸ Useful for pickers with numbers that might need more context ▸ UIScrollViewAccessibilityDelegate let’s you control the status update as your scroll view scrolls. ▸ “Tweets 1 to 20 out of 300”
control how VO speaks text. ▸ UIAccessibilitySpeechAttributePunctuation pronounces all punctuation (great for reading code) ▸ UIAccessibilitySpeechAttributeLanguage controls the language of VO ▸ Useful when content is tagged with language ▸ UIAccessibilitySpeechAttributePitch modulate VO’s pitch ▸ Useful to convey system action such as “post deleted” ▸ Useful to differentiate content in long strings ATTRIBUTED STRINGS
notifications ▸ UIAccessibilityLayoutChangedNotification and UIAccessibilityScreenChangedNotification trigger the system to rebuild the Accessibility tree ▸ UIAccessibilityAnnouncementNotification let’s you make an announcement to the user without user action ▸ “Refreshing content” ▸ “Notification received” NOTIFICATIONS
non-UIView based UI (UIAccessibilityContainer is the old solution) ▸ Dig around in the headers! ▸ UIAccessibility.h ▸ UIAccessibilityConstants.h ▸ UIAccessibilityZoom.h ▸ UIAccessibilityAdditions.h ▸ UIAccessibilityIdentification.h (for automation purposes)
are becoming more dynamic and gesturally-driven ▸ iOS 8 marked the point at which accessibility caught up with these trends ▸ More support for custom behaviors ▸ More support for accessibility tools beyond VoiceOver (such as switch systems)
When objects had gesture-based actions such as flicks or swipes, we had to create custom tap-based gestures for our users on VO ▸ After ▸ We can now wrap these actions into the accessibilityCustomActions property on a view and VO will give the user direct access
EDIT DETAILS. SWIPE UP OR DOWN TO SELECT A CUSTOM ACTION.THEN DOUBLE-TAP TO ACTIVATE. BUY A SPATULA. DOUBLE-TAP TO EDIT DETAILS. ACTIONS AVAILABLE. …Or…
Making custom drawing and non-UIKit objects accessible on screen meant implementing the somewhat buggy and heavy-anded Accessibility Container Protocol ▸ After ▸ Any view can simply set an accessibilityElements array to define objects within it that should be accessible
When switch support on iOS was introduced, it depended only on accessibility already present via VO. ▸ After ▸ Using accessibilityNavigationStyle, you can now control how the focus selects elements ▸ Switches also interface with any accessibilityCustomActions you add
STATE ▸ Before ▸ Impossible to tell what AX features were in use. ▸ After ▸ Notifications and state checking functions for when the device enters/leaves various accessibility modes such as grayscale, reduced transparency, color inversion, and more. ▸ Allows you to change the appearance of your app, if necessary, given these modes
Actions ▸ For pre iOS 8, you should still provide a custom gesture and a hint to help that user find said gesture ▸ Often a good solution is using accessibilityPerformMagicTap to trigger an action sheet ▸ Containers ▸ Stick to old UIAccessibilityContainer Protocol until you drop iOS 7 support
spanage
chou500
eijikominami
takumiogawa
lmi
stajima
niwatakeru
iotengineer22
isaoshimizu
shujisado
shonansurvivors
akexorcist
uhyo
orderedlist
jakevdp
afnizarnur
garrettdimon
eileencodes
trishagee
paulrobertlloyd
iamctodd
jeffersonlam
reverentgeek
tammyeverts
sergeychernyshev
![SOMMER PANAGE [email protected] www.sommerpanage.com](https://files.speakerdeck.com/presentations/8c85c78619e44115a4103c6fb4e43416/slide_56.jpg){kind=link}