Whether one is remediating a digital property (e.g., website or mobile application) or providing guidance in the creation of a new one, the order in which issues are addressed is important and affects both the work of the professionals creating the property and its end users.

1. ICT Testing Symposium
Washington, DC
October 1-2, 2019
Seán Kelly / Karen Herr
What to Fix First:
Remediation Order Matters

2. Introductions

3. 3
My Super Power
My super power is my flexibility. My ability and willingness to adapt to
what the current situation needs.
Education & Experience
20+ plus years software development - last 10 front-end and accessibility
focused; Web Accessibility Specialist certification (IAAP), DHS Trusted
Tester, Certified Scrum Master
My Accessibility Journey
I “cut my accessibility teeth” working on federal contracts where
Section 508 was the law. The importance of accessibility hit home
when my father was diagnosed with macular degeneration and
needed low-vision aids to surf the web, read his Kindle, and publicly
post humiliating Facebook messages to his grandkids.
Karen Herr
Digital Accessibility Engineer
karen.herr@optum.com
My Super Power
I can spot ALL CAPS, justified text and other typographic issues
for cognitive accessibility from low orbit
Education & Experience
Web since 1996; accessibility since 1998; 10+ years in government and
higher education
My Accessibility Journey
I’ve always been fascinated by differences in perception and cognition.
I’ve been lucky enough to have a number of jobs with direct—often in-
person—contact with users who have multiple disabilities and
remember these real life “personas” and their struggles many years
later.
Sean Kelly
Digital Accessibility Engineer
sean_kelly@optum.com
Meet your speakers

4. 4
● Our Accessibility Center of Excellence (A11y CoE) currently has 30+ staff across the
US and Ireland and are expanding.
● We have three areas of focus: assessments, consulting on development teams, and
PDF.
● We work with thousands of electronic properties in multiple countries and languages.
● One of the things that is exciting about working with this scale and variety of properties
is the opportunity to validate and refine best practices at this level.
Accessibility Center of Excellence (A11y CoE) @ Optum

5. Overview

6. 6
● Definitions of Remediation
● Prioritizations of WCAG Success Criteria
● Fix and Reveal (FaR)
● Prioritization by User Impact
● Approaches / Development Methodologies that Affect Planning
● Expense
● Conclusion
We are going to look at a number of parallel ways to look at prioritization. We advocate
using a synthesis of these methods.
Overview
What to Fix First: Remediation Order Matters

7. Remediation:
Definitions

8. 8
● In this talk we are using the terms “electronic properties” and “sites” somewhat
interchangeably and mostly for brevity.
● We are focusing here in consistencies of remediation concerns between Web sites,
mobile apps, kiosks and other electronic properties.
● We won’t spend much time with differing concerns by the type of property.
Terms: “Sites” vs Other “Electronic Properties”

9. 9
● basic design, UX or development work has been done
● you’ve passed even such early stages as color palettes and development platform selection
● any Agile task or user story has been completed without specific attention to A11y
● you’ve recently received the results of an accessibility audit and have defects to address
Remediation: not Just for Existing Sites
The first thing we think of when we hear “remediation” is existing, usually finished, sites.
You are probably in the Remediation Zone if:
You are definitely in the Remediation Zone if:

10. 10
Prioritization of accessibility defects is crucial for large-scale remediation efforts.
For example, your site has recently undergone an accessibility audit, and you have a full
report of the defects.
● How do you integrate remediation back into your site?
● How do you make your site accessible quickly and for the greatest number of users?
Large-scale Remediation

11. Prioritization of WCAG
Success Criteria

12. 12
● Examples of important distinctions that raise the priority of a Success Criteria or
individual checkpoint would be those that seek to avoid potential injury or aggravation
of a medical issue such as preventing flashing, blinking, etc., described by Success
Criteria 2.3.1, 2.3.2, and Technique G19.
● In many companies’ accessibility practices, this has been deliberately prioritized at a
level that is higher than the A/AA/AAA Success Criterion in question.
Preventing Harm

13. 13
● There are multiple places where one Success Criterion overlaps another. In many
cases, the stricter criterion or technique is actually simpler to implement and test than
the more permissive one.
● One prominent example points again to SC 2.3.1, level A, “Three Flashes or Below
Threshold” that is more-difficult to describe, measure, and test than its level AAA
equivalent SC 2.3.2 “Three Flashes”. The latter is stricter, but much easier for purposes
of definition, training and measurement.
Simplicity

14. 14
● Issues such as programmatic keyboard focus and operation of keyboard functionality
affect very wide range and large quantity of users. Multiple Success Criteria for
WCAG 2.1 are covered by Guideline 2.1 “Keyboard Accessible”.
● An approach which also prioritizes keyboard accessibility helps a large swath of the
population—with or without identified disabilities—but also improves testability, both
“manually” and with automated tools.
Foundational Issues

15. 15
The WCAG Success Criteria have some built-in prioritization suggested by the
Conformance Levels—A, AA, AAA.
However, it doesn’t cover the idea that issues of perceived lower priority can have an
enormous impact on your process by
● obscuring other issues
● taking up disproportionate testing bandwidth by mis-timing testing
● under-addressing expectation management around the need
for multiple remediation passes
What about the Interconnectedness of Issues?

16. Fix and Reveal (FaR)

17. 17
● A further case for prioritization of concerns comes into play with the concept Seán
coined as “Fix and Reveal.”
● While the idea that any given bug might conceal another problem (or set of problems)
is not new to anyone who has participated in the software development process, there
appears to be a broad lack of appreciation of how this applies to electronic accessibility.
Fix and Reveal

18. 18
Simply stated, Fix and Reveal describes a design pattern where some issues are likely to
obscure other issues.
FaR identifies critical relationships between WCAG Success Criteria.
Fix and Reveal (continued)

19. 19
A lack of programmatic focus (SC 2.1.1 / 2.1.3) obscures
● Visible focus (SC 2.4.7)
● Keyboard trap (SC 2.1.2)
Fixing these items reveals issues such as
● Sufficient contrast on visible focus (SC 1.4.3 for text, 2.1.11 for non-text)
● Focus order (SC 2.4.3)
This example is a particularly useful one as it can take various paths
right through SC 4.1.1 “Parsing” and SC 4.1.2 ARIA “Name, Role, Value”
Unless basic keyboard operations work it can be (extremely) difficult
to test all accessibility checkpoints
Fix and Reveal: Most Cited Example

20. 20
We needed a way to describe levels of issues that didn’t conflict with the WCAG
conformance levels (A, AA, AA) or the impact descriptions of Critical, High, Medium, Low.
Fix and Reveal: Levels 00, 10, 20, 30

21. 21
● Effectively applies to ALL technology in a web page – including HTML
● Clearly lists four Success 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:”
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
WCAG “Conformance Requirement 5 Non-Interference” (CR5)

22. 22
CR5
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.
Plus four more Success Criteria
2.1.1 - Keyboard
2.4.7 - Focus Visible (Level AA)
4.1.1 - Parsing
1.3.1 - Info and Relationships (specific situations)
FaR: Level 00

23. 23
FaR: Levels 0, 10, 20, 30
0
10
20
30
the rest of the level A Success Criteria that aren’t already in 0
+ a few AA ones that we selected as more important
the rest of the level AA Success Criteria
AAA Success Criteria
Foundational issues that interfere with use or are most likely to hide other
issues.
Overlaps WCAG 2.0 CR5

24. 24
● In an initial evaluation pass, if FaR level 0 items have issues, fix these before doing a
more thorough evaluation. Usually this will save considerable time in retesting.
● The worst obscuring issues are generally exposed at that point and a more thorough
evaluation can be much more productive. It is still but it is best to expect some hidden
issues to be exposed as level 10 issues are resolved but at that point the trend on the
number of defects usually starts to slope down.
Test, Fix, Rinse, Repeat

25. Remediation:
Prioritization by Impact

26. 26
We encourage you to think about any prioritized list, by anyone, and consider whether the
prioritization aligns with
● Your development processes
● Your testing methods and your remediation workflow
Question Your Checklist Prioritization

27. 27
● A11y practitioners are, for good reason, in the habit of thinking
about prioritizing by impact to users.
● What will have the greatest negative effect on the greatest
number of users, categories of disabilities and assistive technologies?
● One common example is keyboard-only functionality covering both sighted keyboard-
only users and users of many Assistive Technologies such as screen readers.
Prioritizing by Impact—to Users

28. 28
Typical Impact Levels
Categories
Critical
High
Medium
User is completely prevented from accomplishing a task. There is no work-around.
User can perform task only through alternate path or workaround. Accomplishing the task
likely only possible for power users.
User can perform task, but doing so will be frustrating or time consuming. User may require
assistance from co-worker or support staff.
Low User experiences inconvenience or moderate frustration.

29. 29
● Look at the traffic that a page or section gets and remediate the high traffic areas first.
● Think about key workflows, such as searching for a product, adding it to a shopping
cart, entering payment data, and completing a checkout.
● Along with other prioritization schemes, this reduces the risk of most users
encountering inaccessible content.
Target high-traffic pages and important workflows
Look at Your Analytics

30. HTML Validation

31. 31
While the specification talks about “well formed” HTML, WCAG SC 4.1.1 specifically
mentions only
● opening and closing tags not missing
● unique HTML ID elements on the page
There are a considerable number of other issues with non-validating HTML that negatively
impact assistive technology (AT) use.
Observation: HTML Validation—More Important
than One Would Think

32. 32
One of the Web Content Accessibility Guidelines (WCAG) principals is dedicated to code quality and standards.
P O U R – Perceivable, Operational, Understandable and Robust
4. Robust
Content must be robust enough that it can be interpreted by a wide variety of user agents, including
assistive technologies.
Guideline 4.1 Compatible
Maximize compatibility with current and future user agents, including assistive technologies.
HTML Validation—POUR Principal 4 “Robust”

33. 33
Keep in mind that browsers make assumptions to “fix” faulty HTML and a page rendering in a browser
will often not be a good proxy for how that code base will perform with AT.
Some issues relating to attributes:
• Role and ARIA attributes must be
correct
• Unquoted attribute value
• Duplicate attribute
• Bad attribute value
• Actual attributes used as custom
attributes
• Broken tags (missing start or end tag, stray
end tag)
• Bad nesting (tag open or close order)
• Bad parent-child relationship
(e.g., <li> under non-list tags, block level
elements inside inline elements)
• Duplicate HTML IDs
HTML Validation: Many issues cause AT and testing problems

34. 34
https://validator.w3.org/nu/
HTML Validation

35. 35
We co-presented with colleagues in this topic
(“Three Developer Behaviors to Eliminate 85% of Accessibility Defects”) at CSUN and ICT.
We are going to mention it briefly (and link to it) as it represents another tool for
prioritization.
1. HTML Validation
2. Scanning Tool (aXe or WAVE)
3. Keyboard Testing
Shrinking the developer feedback loop with these three actions before code commits
eliminates the vast majority of simple defects and allows focus on more complex issues
and more important “teachable moments.”
SlideShare.net: http://bit.ly/2018-ict-3-behaviors
Please feel free to contact us if you need this in an alternate format
Three Developer Behaviors

36. Remediation:
Development Methodologies

37. 37
• If you use a content management system, pull out the text-related changes
and give them to your content manager.
• Send the rest over to the software team.
First Things First

38. 38
Waterfall vs. Agile
Waterfall Agile
Benefits
only if your organization doesn’t do Agile
Risks
● lack of iteration cycles increases the risk that
fixes will be out of date by the time that
they are finally released
● fewer passes for fine tuning
Benefits
gives an opportunity to address higher priority items
in an earlier pass
Risks
your project might actually get done :-)

39. 39
Workstreams: Main vs Separate Workstreams
Agile: A11y Remediation in Main Workstream Agile: A11y Remediation in Separate Workstream
Benefits:
● integration into main workflow and practices and includes
the whole development team
● A11y concerns get appropriately worked into tasks and user
stories for ongoing work—more sustainable
● leverages the idea that A11y is better to bake in
from the beginning vs. bolting it on at the end as an
afterthought
Risks:
● slower—getting more people ramped up takes longer than a
subset of the design, UX, and development group
Benefits:
● provides an opportunity to focus on A11y with fewer
competing concerns
Risks:
● additional overhead of integrating
remediated material / devs less familiar with fixes might not
succeed with code merges
● can fail to socialize the idea that A11y is better
to bake in form the beginning vs bolting it on at the end
(i.e., how the property developed issues in the first place)
● can focus too much on developers and QA
but not enough on Design and UX

40. Remediation Expense

41. 41
● The reputation that accessibility has for being “expensive and difficult” is largely from large scale
remediations where both can be the case compared to having created an accessible product
from the outset.
● Investing in design, development, and test teams to create an accessible product from the very
beginning is far less costly than remediation after accessibility issues have been built into a
product. Not to mention the cost to your credibility when you need to go back to client and ask to
change their designs and/or branding.
● Remediation for the recently added WCAG success criteria has the potential to be much more
costly. For example, if your site is not currently responsive, WCAG 1.4.10 Reflow, will require a
complete redesign effort.
● This additional effort may be a factor for clients’ decisions on when to adopt WCAG 2.1 vs 2.0.
Remediation is Expensive

42. Conclusion

43. 43
By re-thinking the prioritization and order of operations in addressing accessibility issues,
digital properties can be made accessible with greater economy of effort, while making an
iterative approach to remediation more effective in earlier stages of the process and initial
releases of fixes.
Summary

44. slideshare.net:
[link]
temporary link to PPT file:
[link]
karen.herr@optum.com
karen.herr.a11y@gmail.com
linkedin.com/karen-herr-a11y
Karen Herr
Digital Accessibility Engineer
sean_kelly@optum.com
sean.kelly.a11y@gmail.com
linkedin.com/in/seankelly-a11y
Seán Kelly
Digital Accessibility Engineer
Thank You!