Recommended
More Related Content
What's hot
What's hot (18)
Similar to Accessibility: Putting People First in the Software Development Lifecycle
Similar to Accessibility: Putting People First in the Software Development Lifecycle (20)
Recently uploaded
Recently uploaded (20)
Accessibility: Putting People First in the Software Development Lifecycle
- 1. Accessibility Putting People First in the Software Development Lifecycle Marc Thorson and Stacy Carston Accessibility Architects Great Lakes Educational Loan Services, a Nelnet Company March 23, 2018 1
- 2. About Us The Great Lakes Accessibility Team ◦ Stacy Carston ◦ Marc Thorson ◦ We support hundreds of developers and their agile teams with the goal of continually providing state-of-the-art products and services that are accessible to everyone. Great Lakes Educational Loan Services, Inc. ◦ 50+ years of supporting student loan services for millions of borrowers and thousands of schools and lenders ◦ Technology-centric company focused on doing what’s right ◦ Recently acquired by Nelnet 2
- 3. Building software is a process. High quality software is complex ◦ Reliability ◦ Performance ◦ Maintainability ◦ Security ◦ Accessibility To make great software you need an established process ◦ Every organization is a little different ◦ Great Lakes has used both Waterfall and Agile methodologies Every product is different ◦ User base ◦ Platform ◦ Accessible features available 3
- 4. Where does accessibility fit in the software development lifecycle? Testing is a natural first step ◦ Many accessibility efforts start with an audit or evaluation But, testing is not enough ◦ Fixing issues later is most costly than building it correctly ◦ Or it gets buried in the backlog Accessibility must be part of the entire process ◦ Same as secure development practices 4
- 5. Great Lakes Development Methodology Waterfall (1 of 4) Analysis & Design Development Testing Implementation/ Post-Implementation Define Requirements Design & Content 5
- 6. Great Lakes Development Methodology Waterfall (2 of 4) Analysis & Design Development Testing Implementation/ Post-Implementation Define Requirements Design & Content Presentation Layer Code Code Reviews 6
- 7. Great Lakes Development Methodology Waterfall (3 of 4) Analysis & Design Development Testing Implementation/ Post-Implementation Define Requirements Design & Content Presentation Layer Code Code Reviews Verify Accessible Behavior ◦ Manual Testing ◦ Assistive Technology ◦ Accessibility Checklist 7
- 8. Great Lakes Development Methodology Waterfall (4 of 4) Analysis & Design Development Testing Implementation/ Post-Implementation Define Requirements Design & Content Presentation Layer Code Code Reviews Verify Accessible Behavior ◦ Manual Testing ◦ Assistive Technology ◦ Accessibility Checklist Customer Feedback 8
- 9. Great Lakes Development Methodology Agile (Scrum) Product Vision Backlog Refinement Scrum Team Process Product Release Product & Release Feedback Waterfall practices still apply, but the scope is often smaller New practices ◦ Accessibility requirements added to acceptance criteria ◦ Accessibility in the Definition of Done ◦ Demonstrate accessibility related functionality in sprint reviews ◦ Dedicated accessibility sprints Teams need a solid understanding of accessibility 9
- 10. The Toolbox: Supporting the Process Documentation & Training ◦ Standard accessibility training for new hires ◦ Additional training available to teams on request ◦ Self-help Wiki Pattern Libraries ◦ Reusable, accessible code Accessibility Checklist ◦ HTML ◦ PDF ◦ Multimedia 10
- 11. How can we incorporate accessibility into the software development lifecycle successfully? IT’S ALL ABOUT THE STAKEHOLDERS – EACH AND EVERY ONE 11
- 12. Business clients and project managers (the decision-makers) High-level approach Know who the audience is ◦ A widely distributed public website vs. a focused, internal business application Need to make accessibility a priority ◦ Legal compliance ◦ It’s the right thing to do ◦ Understand that accessible design, development and testing time is included in estimates Should know how accessible their product currently is ◦ Set the direction ◦ Make team allocation decisions 12
- 13. Designers and content creators Focus on the overall user experience Principles of Accessibility - POUR ◦ Perceivable ◦ Understandable Some Considerations ◦ Layout ◦ Color ◦ Headings ◦ Verbiage ◦ Interactive Elements (Links, Buttons) ◦ Navigation ◦ Images ◦ Alternative Text ◦ Custom Experiences Accessible design leads to more accessible code 13
- 14. Developers (the magicians) POUR ◦ Operable ◦ Robust Technical focus ◦ Accessible role, name, state, value ◦ Dynamic behavior (keyboard, screen reader, other assistive technology) ◦ Custom widgets require robust scripting ◦ Errors and Notifications ◦ Semantic elements ◦ Reading order ◦ Form input labels ◦ Native applications ◦ Unit tests for accessibility 14
- 15. Testers/quality assurance specialists (the defenders) Running automated tools (aXe, WAVE) Manual testing, including use of assistive technology ◦ Screen readers ◦ Magnification ◦ Responsive behavior / various devices Verify ◦ Reading order ◦ Keyboard behavior ◦ Checklist completed Check for understandability / edge cases 15
- 16. Accessibility expert Fill in the gaps ◦ Provide guidance where a team might be lacking expertise Training & Consulting Advocate for accessibility ◦ Help prioritize issues Can also be a member of the team who is passionate about accessibility 16
- 17. Customer service (the listeners) Interact directly with customers Require awareness of individuals with disabilities ◦ Knowledge of what we offer (such as alternative formats) Yearly accessibility training Support customer independence 17
- 18. Customers (the last word) Our goal is to provide a product that all of our customers can use Give customers a voice by providing an easy feedback method ◦ Complaints ◦ Suggestions Be aware of trends and how our customers are changing the way they access our products ◦ Mobile First / Responsive Design 18
- 20. Accessibility is a team game. A product is only as accessible as its weakest link. All stakeholders need to consider accessibility and take an active role. Whether your process is waterfall or agile, incorporating accessibility into the whole process will lead to a better end product. 20
- 21. Questions? Marc Thorson ◦ @marcoftheweb ◦ mthorson@glhec.org Stacy Carston ◦ @stacycarston ◦ scarston@glhec.org 21
Editor's Notes
- Reasons Accessibility has to be a fundamental part of the process * Teams are focused on delivery and time to market. Attention to accessibility seems to be one of the first things that is falls off when deadlines are tight, but long term costs can be a lot higher * Cost to fix later is greater than building it in at the beginning. * Reputation to the customer base if the application does not function properly for all users. * Potential legal challenges.
- Stages and how Accessibility fits in Structured, project-orientated, one step at a time
- Stages and how Accessibility fits in Structured, project-orientated, one step at a time
- Stages and how Accessibility fits in Structured, project-orientated, one step at a time
- Stages and how Accessibility fits in Structured, project-orientated, one step at a time
- About a year ago, Great Lakes made the switch from Waterfall to an Agile Scrum methodology. On this slide I have a chart depicting our process at a high level, there are 5 items arranged in a repeating cycle: Product Vision, Backlog Refinement, Scrum Team Process which includes our sprints, Product Release, and Product and Release Feedback which leads back into updating the Product Vision. For accessibility, we still need to consider accessibility at the same points we were in the waterfall process, but the scope is often smaller and more focused. We’ve also adopted some new practices: Accessibility requirements are often added to the acceptance criteria on a story level. [something about very successful meeting weekly to discuss accessibility concerns for upcoming tickets] Teams have added accessibility as one of the criteria for their definition of done We encourage teams to demonstrate accessibility related functionality in sprint reviews, such as keyboard behavior or screen reader behavior When appropriate, dedicated accessibility sprints can help teams respond quickly to a large number of findings due to an audit or other business need The agile process has really highlighted the need for the individuals in our product teams to have a good understanding of software accessibility. This need has always been there, it’s just as important in a waterfall methodology, but you can sometimes get away with throwing an accessibility expert in at the last minute and scramble to fix as much as possible. Our agile process, at least, leaves us less room to do that. And the agile methodology works to foster an increased sense of team ownership and collaboration that is really powerful when the team makes accessibility a priority.
- Highlight that we’ll be speaking about pattern libraries at 11