Lessons learn from building accessible complex web apps
Download as PPTX, PDF0 likes373 views
The document outlines key lessons learned in building accessible complex web applications, emphasizing the importance of early integration of accessibility practices, usability testing, and communication among team members. It highlights that leveraging native HTML elements, understanding WCAG guidelines alongside inclusive design, and documenting issues for community feedback are vital for success. The author also stresses the necessity of testing with diverse user groups throughout the development process.
Lessons learn from building accessible complex web apps
- 1. Lessons learnt from building accessible complex web apps Sarah Pulis | Director of Accessibility Services
- 2. Two complex web apps eCommerce web app AngularJS Accessibility built in from the start Multiple rounds of usability testing Accessibility SME embedded into team Financial web app Polymer Accessibility repair after the app had been built Usability testing still to be performed Accessibility SME brought on for accessibility uplift
- 3. Lesson 1 Set yourself up for success through research and planning.
- 4. Tip 1 Find out to what extent your chosen technology has considered and included accessibility to better estimate resourcing and costs.
- 5. Tip 2 Address accessibility from the beginning and clearly define roles and responsibilities for each stage of the process.
- 6. Tip 3 Don’t assume best practice will always be followed. Ask the question. Set expectations. Make sure everyone is on the same page.
- 7. Lesson 2 Don’t focus onWCAG to the exclusion of inclusive design.
- 8. Tip 1 A complex web app may not be usable if you consider accessibility to only beWCAG conformance.
- 9. Tip 2 Agree on the degree of user experience you and your team are aiming to achieve up front.
- 10. Tip 3 Understand the intent of each WCAG Success Criterion and how it shapes a user’s overall experience.
- 11. Lesson 3 Supporting multiple screen readers when using ARIA can be a bitch.
- 12. Tip 1 Remember the first rule of ARIA use: If you can use a native HTML element or attribute... then do so.
- 13. Tip 2 (Really) understand parent/child relationships in ARIA.
- 14. Tip 3 Don't leave screen reader testing to the end.Test early, test often.
- 15. Tip 4 Find or create code samples that follow best practice for baseline screen reader results.
- 16. Tip 5 Create a decision tree for when an optimal solution across all screen readers cannot be reached.
- 17. Tip 6 Come to terms with the fact that sometimes you are just going to have to hack it to make it work.
- 18. Lesson 4 The need for usability testing only increases the more complex your app is
- 19. Tip 1 Get usability testing into your project in any way you can (bribery using baked goods or chocolate is totally acceptable).
- 20. Tip 2 Select the right mix and number of users for usability testing.
- 21. Tip 3 Test with users as early and as often as you can.
- 22. Tip 4 Listen to your users, but be careful about making generalisations.
- 23. Lesson 5 Document any decisions or issues and feed back to the community
- 24. Tip 1 Raise or submit any bugs you find or improvements you’ve made to the vendors or creators of the technology.
- 25. Tip 2 Tap into the accessibility community if you get stuck.
- 26. What we learnt Lesson 1: Set yourself up for success through research and planning. Lesson 2: Don’t focus onWCAG to the exclusion of inclusive design. Lesson 3: Supporting multiple screen readers when using ARIA can be a bitch. Lesson 4:The need for usability testing only increases the more complex your app is Lesson 5: Document any decisions or issues and feed back to the community
- 27. Happy Global Accessibility Awareness Day! Sarah Pulis sarah@intopia.digital