Mais conteúdo relacionado

Similar a Accessibility In Mobile Dev LifeCycle.pptx(20)


Accessibility In Mobile Dev LifeCycle.pptx

  1. Accessibility In The Mobile Development Lifecycle
  2. Name: Mark Steadman Title: Director, Mobile Accessibility Company: Fidelity Investments Name: Zach Gadoury Title: Senior Accessibility Engineer Company: Fidelity Investments Hi There!
  3. Why Does Mobile A11y Matter? • Global traffic on mobile devices has increased from 6% in 2011, to 54% in 2021 • Anything and everything has a mobile app now. • Some sites even force you to USE the mobile app • Quick, easy access: • Communication • Ride Sharing • Banking • Food delivery/Grocery Delivery Source Credit:
  4. Assistive Technology Usage A study was done on Assistive technology usage in the Netherlands: Android • 59% of users have one or more accessibility setting on. • 22% have more than one accessibility setting on. iOS • 45% of users have one or more accessibility setting on. • 15% have more than one accessibility setting on. Source Credit:
  5. The Problem: Mobile & A11y In Development No Information Standards? Slows Down Dev • Difficult to find a11y info • Resources are scattered • Trying to mimic web in mobile • WCAG Applied to mobile • UAAG • HIG • Testing takes too long • Applying a11y is difficult • Too hard to learn it all
  6. The Solution: Keep Velocity, Add A11y • Introduce accessibility into the development lifecycle without slowing down the development process • We achieve this by breaking it into phases. • Piece by piece, bit by bit accessibility gets introduced and ACCEPTED as a practice • We want to make it so “I will get to Accessibility later” is no longer a statement being made!
  7. Small Wins, For Big Gains
  8. Phasing In Accessibility • Phase 1: Automation • Linting • Automated Testing Tools • Automated Testing Libraries • Phase 2: Quick Manual Tests • Visual Testing • Quick Assistive Technology Checks • Phase 3: Definition of Done • Phase 0: ‘Ten minutes a day’ Accessibility learning
  9. Phase 1: Automation
  10. Linting • A linter is a tool that statically analyzes source code to flag programming errors and bugs • This includes Accessibility! • Benefits of Accessible Linting • Catching issues as you build HTML content • Building accessibility knowledge for your developers • Allows your team to build an accessible gate on commit • Customizable to the framework you are developing in
  11. Linting • Linting is built directly into Android studio using the Android Testing Framework to check for issues as you code • Quick and reliable • Helps developers learn from general accessibility mistakes as they code • Linting for accessibility issues is a bit more difficult in iOS • Very few linters have accessibility checks • SwiftLint • Two accessibility checks • Only for SwiftUI • Xiblint (By Lyft) • Storyboard accessibility checker Android iOS
  12. Linting Demo
  13. Automated Testing Tools • Google Accessibility Scanner • Application that can scan your content for accessibility issues • Has around 14 or so checks • Easy to use and very simple to run after your application is built • Xcode Accessibility Inspector (Audit) • Built into Xcode • UIKit and SwiftUI • Allows you to run an audit of your content and catch accessibility issues Android iOS
  14. Automated Testing Libraries • Accessibility Test Framework • An Espresso testing library that checks for accessibility issues in automated UI tests • Simple setup, and easy to implement for each different UI test case • A11yUITests • Open source testing library by Rob Whitaker • Super easy integration • Allows you choice of testing suite and what views to test • Works with both UIKit and SwiftUI Android iOS
  15. Automated Testing Libraries
  16. Phase 2: Quick Manual Tests
  17. 'Minute to win it’ Test Cases • Quick screen reader tests: • Roles for Actions • Headers • Appropriate Accessible Text • Image Descriptions • Quick visual tests: • Persistent and Visible Labels • Use of Color • Images of Text • Text Resizing • Heading and Structure • Flashing Content Testing doesn’t have to take forever! ”Minute to win it” test cases can help create a much more accessible app, with very little effort! Here are some examples!
  18. Demo: Screen Reader Test
  19. Demo: Visual Test
  20. Phase 0: Ten Minutes of A11y a Day
  21. Ten Minutes a Day • As simple as the title, take 10 minutes a day for accessibility knowledge gathering. • Taking an accessibility training course • W3 Accessibility Foundations (Free) • Udacity Web Accessibility (Free) • Deque University (Paid Subscription) • Reading accessibility article: • The A11y Project • A11y Weekly • WebAIM News Letter 10 minutes 20 minutes 40 minutes 1 Hour
  22. Phase 3: Build Definition of Done
  23. Building a DOD for A11y • The ultimate goal is to have accessibility be apart of definition of done • Truthfully, it may take some time to get to this point. • Working with Product Owners to get buy-in for adding more to definition of done is a fight in and of itself • This can come in a varying different ways, however in its simplest form we want it to enforce the phases we have laid out previously
  24. Example Definition of Done
  25. Bringing it home • Following these simple phases can help ensure: • Enforce the importance of accessibility • Not slow down delivery velocity • Not overwhelm developers to “do accessibility now” • Build developer knowledge of accessibility • At the end of the day the goal is to create developers that truly care about the content that they create and build a culture of accessibility that is lasts and endures
  26. Name: Mark Steadman : @Steady5063 : Mark Steadman (Mark-Steady) Connect With Us Name: Zach Gadoury : @ZachGadoury : Zach Gadoury(Mark-Steady)

Notas do Editor

  1. Video Description: Video starts with the text view code from an android app. Three errors are presented under “Problems” The first is: ‘clickable’ attribute found, please also add ‘focusable’. The second: Should use ”sp” instead of “dp” for text sizes. The last: Missing ‘contentDescription’ attribute on image. Developer adds the line of code to the text view: android:clickable=“true”. The developer then adds: android:focusable=“true”. The developer then changes the text size measurement unit from dp to sp, the final code line reads “android:textSize=“35sp” The final code added reads: android:contentDescription=“@id/imageDescription”. As the developer adds the lines of code, the errors disappear, until there are none left. The Video ends.
  2. The video starts at a view of an android emulator and android code, the code includes 3 functions: setup, firstFragDisplayDefault, and loginInfoEntered. The user compiles and runs the app, at first it runs, but then the app crashes and errors are thrown: The error presented is on the text view, the error states “the height of the component is 47dp, consider making it 48dp. The video ends.
  3. The video starts in the Apple App store on an iphone, voice over is turned on on the phone and captions appear. Voice over reads: “Voiceover on, Appstore. Search. Heading.“ The focus moves to the profile button and voice over reads: “My account. Button.” The focus moves to the search input and reads: “Games, Apps, Stories, and more. Search Field. Double tap to edit. The video ends.
  4. The video starts recording the screen of an iphone, in the settings app. The text size is default. The user navigates to the accessibility settings, then to display and text size, then to larger text. The user turns on larger text and the text is increased to the largest size. The font of the screen enlarges and the user returns to the previous setting screens and does a visual check to make sure no content has been cut off or truncating. The video ends.