CSUN 2017 Success Criteria: Dependencies and Prioritization


Published on

Sean Kelly and Bill Tyler present Success Criteria: Dependencies and Prioritization at CSUN 2017

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

CSUN 2017 Success Criteria: Dependencies and Prioritization

  1. 1. Success Criteria Dependencies & Prioritization: Implication & Use CSUN 2017, San Diego Sean Kelly, Bill Tyler March 3, 2017
  2. 2. Bill ≠ Sean (We are not related)
  3. 3. Sean Kelly Sean’s Experience Former Photographer and Print/Media Artist Web since 1996, Accessibility Since 1998 10+ Years in Public Sector and Higher Education 8 Years in State Government 3 yrs. of Ongoing Accessibility Research & Analysis at Optum Technology 3
  4. 4. Bill Tyler • 30+ yrs. of UI/UX Design & Development • 12+ yrs. in medical devices • 15+ yrs. in plans & providers • 2X dot-com survivor • Started Web 1996 • Started Accessibility 2002 4
  5. 5. We ♥ WCAG 5
  6. 6. But it’s not perfect… 6
  7. 7. We found it has… Undocumented (or under- documented) dependencies & relationships between success criteria 7
  8. 8. The default levels (A/AA/AAA) are Generic. Broad. Not tailored to specific enterprise
 or project needs 8
  9. 9. Because of this lack of fine tuning, It can be difficult to Integrate WCAG into Agile Fitting A/AA into Sprints & Releases 9
  10. 10. Dependencies 10
  11. 11. Not all success criteria are created equal Some accessibility issues “hide” other issues These criteria are “special” • Not meeting them undermines testing as well as site functionality 11
  12. 12. Some criteria must be fixed first Example: • Unless basic keyboard operations work it can be (extremely) difficult to test all accessibility checkpoints • This led us to the need for lower levels levels accessibility Essentially a level "Zero A" 12
  13. 13. Fixing those issues reveals other (hidden) issues This is the origin of our design pattern: FaR 13
  14. 14. FaR Defined FaR is an acronym for “Fix” and “Reveal” FaR is a design pattern: i.e., Fixing issues Reveals others FaR identifies critical relationships between WCAG success criteria • For example: Fixing – SC2.1.1 Keyboard – SC2.1.2 No Keyboard Trap Reveals issues in – SC2.4.7 Focus Visible Which in Turn Reveals issues in – SC2.4.3 Focus Order – and by extension through other SC all the way down to 4.1.2. [Name, Role, Value] 14
  15. 15. FaR & WCAG 15
  16. 16. Does WCAG have a Level "Zero A?" We think we found one... 16
  17. 17. Do you know CR5? Conformance Requirement 5. Non-Interference • Focuses mainly on “new technology” additions to pages – See the hypothetical “ZAP” technology example (link below) • Effectively applies to ALL technology in a web page – including HTML • Clearly lists FOUR criteria that, if not met, can undermine page accessibility: "In addition, the following success criteria apply to all content on the page, including content that is not otherwise relied upon to meet conformance, because failure to meet them could interfere with any use of the page:" (my emphasis) – 1.4.2 - Audio Control, – 2.1.2 - No Keyboard Trap, – 2.3.1 - Three Flashes or Below Threshold, and – 2.2.2 - Pause, Stop, Hide. Source: https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-conformance-requirements-head 17
  18. 18. CR5 is listed with those four criteria CR5 is clearly listed as a “note” for each of the four criteria Example: SC2.1.2 No Keyboard Trap 2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A) Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference. Source: https://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-trapping.html 18
  19. 19. CR5 items fit the FaR pattern SC1.4.2 - Audio Control • Until fixed screen readers cannot hear page SC2.1.2 - No Keyboard Trap • Until fixed keyboard users cannot get to rest of page SC2.3.1 - Three Flashes or Below Threshold • Seizures SC2.2.2 - Pause, Stop, Hide • Auto-playing and advancing content can be major distraction 19
  20. 20. Are the CR5 criteria enough? In our FaR example there are 3 crits, and only ONE is CR5 Fixing – SC2.1.1 Keyboard – SC2.1.2 No Keyboard Trap (CR5) – Can reveal issues with – SC2.4.7 Focus Visible – Which can then reveal issues with – SC2.4.3 Focus Order Our answer is “No.” 20
  21. 21. Our “Extended CR5-like Criteria List” Original CR5 Criteria • SC1.4.2 - Audio Control • SC2.1.2 - No Keyboard Trap • SC2.3.1 - Three Flashes or Below Threshold • SC2.2.2 - Pause, Stop, Hide Our Additions • SC2.1.1 - Keyboard • SC2.4.7 - Focus Visible (Level AA!) • SC4.1.1 - Parsing • SC1.3.1 - Info and Relationships (specific subset of situations) 21
  22. 22. Are these all “CR5-like” criteria equal? No. 22
  23. 23. Prioritization 23
  24. 24. Need for Prioritization FaR led to reviewing ALL criteria We re-prioritized the all criteria based up on our standards • Our ideal target is WCAG 2.0 AA+ and includes some AAA items We created a our own criteria based upon our needs We call it “Success Criteria Prioritization” or SCP “Skip” 24
  25. 25. SCP: Process Created prioritization guidelines to define relative order Walking the Crits • Analyze each criterion to answer a particular question – Prioritizing each relative to other success criteria if at same level – Try to get a very fine grain order for nearly every criterion so there are few “ties” Structure priority in ways so they are: • Easily understood • Distinct from – but easily aligned with – WCAG • Grouped logically and consistently 25
  26. 26. SCP Prioritization Guidelines 1. Safety • Example: SC2.3.1 Three Flashes or Below Threshold 2. FaR Dependencies • For testing and primary functionality (as discussed earlier) 3. General Site Needs • Examples: – Keyboard Operation before Presentation – Presentation before Forms and Error Handling 4. Business Needs • Examples: – We have a lot of forms so they come before media, navigation and language support – We use little time-based media so it is lower 26
  27. 27. SCP Levels 0 10 20 30 Level 0s 4 CR5 criteria 4 FaR “CR5-like” criteria (including one AA) Level 10s Remaining Level A criteria not in Level 0s Includes one AA criterion Level 20s All Remaining AA not in 0s and 10s
 Some AAA criteria (for “AA+” standards) Level 30s All remaining AAA criteria 27
  28. 28. SCP Levels & WCAG Leveling by Tens helps maintain alignment with WCAG • Aligns well with WCAG – Number of tens = WCAG “A-level” • Level 0s = CR5 • Level 10s = A • Level 20s = AA • Level 30s = AAA – We still need to meet and report WCAG conformance – Accommodates “WCAG AA+” target Allows prioritization outside of WCAG • Numbered to prioritize across all criteria as needed – Allows ordering across principles and guidelines – Allows ordering between WCAG A-levels 28
  29. 29. SCP Level Structure Numbering not Letters • Numbering into 4 groups of 10 reduces confusion with WCAG A/AA/AAA – Example: “Level Zeroes” not easily confused with WCAG Stratification • Groups of “guideline-related” criteria order is indexed across levels Examples – Time-Based Media at 18, 28 and 38 – Forms and Error Handling are 14, 24 and 34 29
  30. 30. Applying SCP: Project Intake Level 0s and Intake • Level 0s are a cornerstone of our practice, especially when evaluating and estimate work involved for new projects • Level 0 checklists can quickly identify major issues with – Keyboard operation – Time-based media operation and content – Alternate document formats – Problematic infrastructure platforms such as SharePoint, AngularJS – Code design issues such as complex <table> layout – Code implementation issues that may hide deeper issues for AT • Many of these can be answered by business when preparing proposals 30
  31. 31. SCP & Agile More prioritization benefits 31
  32. 32. SCP: An Agile “Success” by Itself Telling scrum masters success criteria are prioritized (using SCP) can eliminate discussions and delays when grooming remediation user stories SCP can help ensure consistency across projects for the accessibility practice 32
  33. 33. Integrating A11y Agile: MVPs Aligning Accessibility with MVPs Minimum Viable Product defined: [A] version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. • Source Wikipedia / Eric Ries: https://en.wikipedia.org/wiki/Minimum_viable_product SCP provides a clear roadmap for MVP accessibility • Incremental MVP enhancement should improve accessibility as well Accessibility should have its own MVP targets 33
  34. 34. Minimum Accessible Product Or MAP 34
  35. 35. MAP – Overcoming Initial Revulsion Minimum Accessible Products sound “awful” • It wreaks of “compromise” • It suggests agreeing to a reduced accessibility target in final product MVPs and MAPs are not target deliverables • “Some caveats right off the bat. MVP, despite the name, is not about creating minimal products.” - Eric Ries Source: http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html • Most MVPs (and MAPs) are incremental to test concepts and stepping stones to actual releases 35
  36. 36. Using MAP to Achieve A11y Goals in Agile MAP & FaR • Level 0s can be groomed into earliest sprints to fix critical issues and overcome a11y blockers MAP & WCAG Conformance • MAPs in later sprints can plan targeting Level A, then Level AA SCP & MAP to Ensure Accessible Deliverables • Using SCP to define MAP targets can help ensure meaningful accessibility increments that can be used by some/most – What good is a site with all AA criteria met but a keyboard trap on the sign in page? 36
  37. 37. Putting it all together… 37
  38. 38. Dependencies Not all criteria are equal – Some are more “important” than others FaR – Fix and Reveal • Fixing some problems Reveals new issues Existing WCAG required dependencies (CR5) • “Zero A” criteria 38
  39. 39. SCP: Success Criteria Prioritization Define and apply prioritization order 1. Safety 2. FaR (existing sites) 3. Site Operation 4. Business Needs Effective naming conventions • Aligned – but not confused – with WCAG • Fine grained, “few ties” • Already defined • Repeatable across 39
  40. 40. SCP Provides Customized WCAG Approach • Tailored to enterprise project needs • Not tied WCAG structure – Work across principles and levels – Can be refined to new needs Consistent Roadmap • Already defined • Repeatable • Can be reviewed, revised & enhanced • Can be applied and intake and early analysis 40
  41. 41. SCP & Agile Aligns well with Agile using MAP • Plan and target accessibility targets • Criteria prioritized: Ready to groom into user stories and sprint • Plan main FaR dependencies first • MAP targets can be tracked along WCAG levels – CR5, A, AA 41
  42. 42. 42
  43. 43. Thank you. Contact information: Sean Kelly Digital Accessibility Engineer sean_kelly@optum.com @sk55408 Bill Tyler Sr. Digital Accessibility Engineer btyler@optum.com
 @billtyler 43