Extreme Accessibility: Handling accessibility at scale in Agile environments.

Accessibility is unique in that it exists at the crossroads of technical quality and UX. During this session, I will provide a roadmap for Extreme Accessibility including tooling & processes for making Extreme Accessibility part of a mature, organization-wide approach to Accessible User Experience.

There have long been discussions on the accessibility industry surrounding the business case for accessibility. The Education and Outreach Working Group at the Web Accessibility Initiative of the W3C developed a large set of resources on this topic to which I posted a series of blog posts in response. At the time, however, I failed to realize what so many others also continue to overlook: accessibility issues are bugs and should be treated that way. Accessibility is unique in that it exists at the crossroads of technical quality and user experience. On the technical side of things accessibility can be seen as a quality domain. Bugs in the code result in user experience issues for specific populations of users. Resolving the bugs increases quality.

It almost seems too obvious to mention: no bugs means no money spent on fixing bugs. But bugs are inevitable. Given the inevitability of bugs, when the bugs are found and fixed is the critical factor in saving money. How much money is difficult to determine. In the 1980s, Barry Boehm estimated the expense of post-production remediation to be 100x the cost earlier in the software development process. This became known as the Boehm Curve. While the “100x” estimation has been questioned by many, what isn’t under question is that late discovery of defects is orders-of-magnitude more costly. The cost of defects is massive.

…although all errors cannot be removed, more than a third of these costs, or an estimated $22.2 billion, could be eliminated by an improved testing infrastructure that enables earlier and more effective identification and removal of software defects. These are the savings associated with finding an increased percentage (but not 100 percent) of errors closer to the development stages in which they are introduced. Currently, over half of all errors are not found until “downstream” in the development process or during post-sale software use. (Source: NIST)

Defects don’t just cost the money needed to fix them. Simple metrics like raw cost to fix a defect only take into consideration the time it takes for a developer to fix a defect. The economic benefits of avoiding defects extend into and beyond all phases of development including the maintenance phase. In total, the Cost of Quality is the Cost of Conformance + Cost of Non-Conformance and that includes typical development, remediation, maintenance, and user support costs.

Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. (https://en.wikipedia.org/wiki/Extreme_programming)

Reducing costs from software defects requires that we shorten the feedback loop for finding and fixing those defects. As indicated in the Figure above, the feedback loop is quickest when using Extreme Programming methodologies and this goes for accessibility feedback as well as other quality domains. However, accessibility professionals have shown little ability to fully integrate with extreme programming practices, which means that accessibility has, in turn, remained overly expensive, time-consuming, and ineffective. Feedback must occur at all phases of product development, with high importance placed on the earliest phases. Instead, traditional accessibility testing occurs in the last stages of the project. The most significant risk reduction and cost savings can be realized by adopting Extreme Accessibility.

The Extreme Accessibility methodology requires a cohesive approach to testing that involves creating 6 feedback points that feed into the others.

• Requirements must be defined in a way that indicate the specific business and user-interaction requirements of what is being developed. These requirements should be separated into definitions of the distinct features being developed and should be done with enough specificity that they can be used as inputs for design, development, and quality assurance feedback points. Any feature that does not make sense when documented will not make sense when used. Therefore this is the first, fastest, and easiest point in the feedback loop.
• Design must adhere to the feature requirements defined for the product. Requirement definitions are implemented here and this offers the first opportunity to verify quality of a previous feedback cycle. As before, issues discovered within-cycle should be handled within-cycle as well, to avoid polluting later phases with quality issues.
• Development is where the bulk of accessibility issues are created, often owing to a lack of appropriate tooling. Development processes within agile environments have their own unique feedback cycle. Developers can (and should) leverage code-quality tools such as linters, syntax checkers, unit testing, and other automation to check code prior to committing it to revision control. Developers should also leverage the feature requirements as an input to verifying that they’ve met the requirements for the product. Code should never be committed that doesn’t pass automated tests, because letting these defects pass into the next feedback loop will significantly increase cost and risk.
• Quality Assurance is a verification step for development’s automated tests and an opportunity to perform manual review. In this phase the same inputs that were generated during requirements and used during development will form the basis for acceptance tests. Automation scripts should use the same tests as those used in development. In cases where feature specifications cannot be fed into automation, QA engineers will utilize those specifications as acceptance test scripts.
• Continuous Integration provides an opportunity to catch regressions in code before it is deployed using the same automation scripts used by development and QA staff. This prevents critical flaws from entering production *Review provides the ability to gather up those quality flaws that slipped through the cracks, either by virtue of sheer mistake or by knowingly taking on technical debt along the way. The review process should facilitate exploring lessons learned along each cycle in order to improve future iterations.

Though much of the above sounds similar to the “test early, test often” beliefs espoused by others in the field, the specific details – including actionable guidance, job aids and, most importantly, tooling around such process have been discussed as mere concepts. During this session, we will provide a roadmap and job aids for Extreme Accessibility including tooling and other processes for making Extreme Accessibility an integral part of a mature, organization-wide approach to quality and Accessible User Experience.

I’m an engaging speaker with a over a decade of experience presenting, holding workshops, and training. I’ve spoken in 7 countries and 11 US states.

18 videos of some of my presentations can be seen at http://www.karlgroves.com/presentations/

Below is a partial the conferences I’ve spoken at:

• NationJS, Washington DC (multiple)
• Beyond Tellerand, Germany
• ParisWeb, Paris France (multiple)
• Better By Design, Madison Wisconsin (workshop)
• Fronteers Spring Conference, Amsterdam Netherlands
• Elements Web Conference at Penn State
• IEEE Information Visualization, Baltimore Maryland
• Annual Conference of the Society for Technical Communications, Baltimore Maryland
• Frontend Conference, Zurich Switzerland
• RVA JavaScript Conference