Three Developer Behaviors to Reduce Accessibility Defects
•Download as PPTX, PDF•
0 likes•290 views
Shane Anderson and Sean Kelly present "Three Developer Behaviors to Reduce Accessibility Defects" at the 2018 ICT Accessibility Testing Symposium, November 8, 2018, in Arlington, VA.
More Related Content
Similar to Three Developer Behaviors to Reduce Accessibility Defects
Similar to Three Developer Behaviors to Reduce Accessibility Defects (20)
More from Sean Kelly
More from Sean Kelly (7)
Recently uploaded
Recently uploaded (12)
Three Developer Behaviors to Reduce Accessibility Defects
- 4. Thanks to Thomas F. Dinkel • • • • •
- 6. Optum Accessibility Center of Excellence
- 7. Outline
- 8. Intro
- 9. Why Change
- 10. How to Change
- 11. Goal
- 13. HTML is key to our approach 1. 2. 3.
- 16. HTML5 is an industry standard and should be treated as such. 1. 2. 3.
- 17. We all benefit from the standard HTML Specification (W3C) Browser Developers Assistive Technology Developers Web Site / Web Application Web Browser Screen Reader All Your Users (real people) Web Application Developers
- 18. Browser and Assistive Technology combinations (BrAT) • • • •
- 19. Overcoming Objections “It looks right in my browser.” “With HTML5, all HTML is valid” “I’ll worry about the front end once I have the backend stable.” “We’ve seen valid HTML that isn’t accessible.” “I don’t write HTML, because I use a JavaScript framework.”
- 22. Bad code example: Bad parent-child relationship
- 23. Things to Watch For
- 24. Other benefits of valid HTML • • • • •
- 30. Parallels with other types of code • • • •
- 32. Accessibility Scanning Tools: What’s What? • https://www.deque.com/products/axe/ • https://wave.webaim.org/extension/ • https://developer.paciellogroup.com/resources/wat/ • http://squizlabs.github.io/HTML_CodeSniffer/ •
- 33. Accessibility Scanning Tools: What do they find? • •
- 34. What we use to get devs started • https://www.deque.com/products/axe/ • https://wave.webaim.org/extension/
- 37. More about how these tools work
- 39. Keyboard functionality is fundamental • • •
- 40. Keyboard operation and focus issues • • • •
- 41. Keyboard testing as a window on users • •
- 42. Keyboard testing can’t be automated (yet) • • • •
- 45. Try it with a screen reader
- 48. Conclusion: Introducing developers to Accessibility
- 49. Conclusion: The Three Behaviors
- 50. Shane Anderson Senior Digital Accessibility Engineer shane_anderson@optum.com shanebanderson@gmail.com @shanderson linkedin.com/in/shanebanderson/ Seán Kelly Senior Digital Accessibility Engineer sean_kelly@optum.com sean.kelly.net@gmail.com @sk55408 inkedin.com/in/seankellyweb/
Editor's Notes
- Sean
- Shane First
- Sean
- Thomas First time at CSUN and my first time presenting. Terrible with names and faces, no official diagnosis for it, but trust me, I’m really bad so always, please feel free to approach me and (re)introduce yourself. Legally blind in one eye since birth. Early stages of glaucoma in the other.
- Sean
- Sean
- Sean
- Sean
- Shane
- Shane
- Shane
- Shane We want our developers to perform HTML validation.
- Shane
- Shane HTML is the root of most accessibility issues Assessments from 18 random websites evaluated within the meaningful access program (of over 200 web properties) Missing title, lang, alt, label, id, improper nesting Missing alt and label associations are probably the most common issues. It’s really a combination of HTML, and what ever else is included, such as SVG, DOM, etc.
- Shane Testing HTML is almost always completely ignored. The lack of error feedback by the browser is a fairly unique practice in the development world
- Shane We care about standards. Consistency is extremely helpful. Business people like measurable things. HTML and supporting technologies (e.g. CSS and DOM) are standards. Assistive technologies benefit from browsers exposing a11y API data properly Cleaner DOM
- Shane This diagram shows a number of the various participants involved in the standard; it starts with the HTML specification, and ending with the end user. Participating in the standard, means we all promise to use it consistently. If we do, we all win. This slide shows a flow chart that starts with the HTML Specification and passes through a number of participants and products before making its way to “your users”. (One line) The HTML standard starts with the specification made by the W3C—which we can all help contribute to. Based on that standard, Browser Developers build browsers that will know what to do with the stuff in the specification. Based on the specification, Assistive Technology developers build tools know what to do with what is in the browser and the HTML specification. (Two lines) Again, we start with the HTML standard, Based on the standard, Web Developers also know how to write HTML. Web developers use standard HTML to create documents that make up their web site / application. (Three lines) So when an HTML document gets parsed by the browser, UI elements are displayed in a consistent way. Then when what is in the browser gets interpreted by the screen reader, it be presented in a consistent way as well. Finally, when it gets to the user (remember, they are the whole reason we’re doing all of this in the first place): It will meet all user’s every expectation and they will love you for it. The point is, we all need this shared understanding to help make things work as expected.
- Shane The term “BrAT” is our abbreviation for Browser and Assistive Technology combination.
- Shane https://validator.w3.org/docs/why.html The JS framework we use generates the HTML, and they must know what they’re doing. Too hard / takes too much time The same could be said of “real” programming languages that are less forgiving. Many DEVs still take it a step further and do unit testing on their back-end code. HTML code quality needs to be a job requirement. Why not with HTML? Because web browsers are too forgiving. “It works in the browser I tested it with” That’s like saying: “This house is great as long as you’re less than four feet tall” Or: “It’s a good porch as long as only one person stands on it at a time” We want our web apps to work the same on as many devices/browsers as possible WCAG says “Robust” Many of the big-players’ pages don’t pass validation Maybe they can afford the risk Some valid HTML doesn’t work; some invalid HTML is accessible. It is more often the case where pages work more reliably in more BrATs when using standard, valid HTML The JS framework we’re using generates the HTML, they must know what they’re doing I hope that happens soon. We’ve heard “We can’t control the HTML that is being generated.” but have found this to be generally false.
- Shane Clean HTML code is fundamental to a successful long-term accessibility program.
- Shane
- Shane
- Shane State and dynamic content changes example: Page with a form loads: run validation Try to submit the form with no values entered and error messages are displayed: run validation Fix all the errors so all the fields look valid: run validation again.
- Shane
- Shane Clean HTML code is fundamental to a successful long-term accessibility program.
- Shane Clean HTML code is fundamental to a successful long-term accessibility program.
- Sean
- Sean
- Thomas We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
- Thomas We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
- Sean
- Thomas We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
- Thomas We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
- Thomas We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
- Thomas We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
- Thomas We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
- Thomas We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
- Sean
- Thomas We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
- Thomas We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
- Thomas We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
- Thomas We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
- Thomas We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
- Thomas
- Thomas
- Thomas
- Thomas
- Thomas
- Thomas
- Sean