End the Madness - Section 508 Compliance in the Enterprise

About SSB BART Group

• Experience• Accessibility Focus• Solutions That Manage

Risk• Real World Fixes• Excellence at Scale• Knowledge That Is Up-

to-Date, All the Time

About SSB BART Group

• Fourteen hundred organizations (1452)

• Fifteen hundred individual accessibility best practices (1512)

• Twenty-three core technology platforms (23)

• Twenty-two thousand audits (22,408)

• One hundred twenty-one thousand human validated accessibility violations (121,290)

• Fifteen million accessibility violations (15,331,444)

Timothy Stephen Springer

• Founder of SSB Technologies, CEO SSB BART Group

• Fourteen years of experience in web accessibility

• Eighteen years of experience in web development consulting

• Consulted with hundreds organizations on web accessibility policies and practices

• Principal architect of InFocus, AMP and DCQL

• BS CS Stanford, AI focus• Two month old child (second, boy) at

home – slept well for the first time last night

Agenda

• Current Reality• Accessibility Initiative Phases

– Policy– Standards– Procurement and Contracting– Testing Plan– Training– Pilot Project

• Accessibility Program Office• Appendices

– Roles and Responsibilities– Implementation Plan

Current Reality

• People with disabilities face profound access challenges

• 18.7% of population has a disability

• 12.6% has a severe disability• Rates drastically increase with

age• In working age population

– 41.1% employment rate (all disabilities)

– 27.5% employment rate (severe disabilities)

Inaccessible ICT is a Huge Barrier

Current Reality

• 508 promised a huge impact on accessible ICT– Progress was made but more

remains• ADA and related legislation likely to

have a far greater impact• Our goals remain the same

– Drastically increase employment of people with disabilities

– Ensure participation in society for people with disabilities

– Fulfill the civil rights of people with disabilities

The Promise of 508

Accessibility Initiatives Phases

• Policy – Overall approach and structure• Standards – Nuts and bolts• Procurement and Contracting – Buy accessible stuff• Testing Plan - How do we validate accessibility?• Training – Who gets trained on what?• Pilot Project – Do one, learn stuff

Enterprise Accessibility PolicyRound One

• Technical Standards – 508 v. WCAG• Scope – What’s covered?• Timeline – When to conform? (Hint: Now)• Priority – What first? (Anathema! Heretic!)• Exceptions – What and how?

– Statutory - Undue Burden, Substantial or Fundamental Alteration

– Operational - Other User Provided and Generated Content, Linked Sites and Resources, External Content, Live Content, Short Term Content, Orphan Content, Low Traffic Content, Third Party Applications

• Functional Support – Level of equivalent access

Enterprise Accessibility PolicyRound Two

• Non-complianceWhat happens if we don’t comply? (Often nothing…)

• Supported ATWhat assistive technologies do we support?

• Vendors How do we address this with vendors?

Monitoring PlanAccessibility Initiatives

Metrics and Measurements

• Overall compliance score• New development

compliance score• Upgraded system

compliance score• Production system

compliance score

Issues

• Monitor inbound IT Accessibility issues

• Reporting time frame• Number of incidences • Work to resolve issues• Time to resolve issues • Are we meeting out policy

targets?

Other Key Policy Docs

Accessibility Statement • Organization wide accessibility statement

– Publish it everywhere– Required under OMB Strategic Plan, AODA

Accessibility Issue Resolution Policy • How do we resolve issue relating to accessibility?• Ideally like we resolve other issues

Technical Standards

Cover core technology platforms, generally:• Web• Flash• Multimedia• PDF• Word• Excel• PowerPoint• iOS• Android• Other platforms (desktop,

hardware) as needed

• Technical Standards• Implementation Guide

– 100 – 200 best practices– For each provide

• Description of issue• User impact• Code

– Compliant Examples– Non-compliant Examples

• Recommendations• Unit Tests• Prioritization Factors

• Decision Matrix• Compliance Checklist

Procurement and Contracting

Ideal• Make it my vendor’s

problem! (Awesome!)

Reality• Your vendors have no idea

how to do this!• Without oversight you will

get inaccessible things• VALIDATE VENDOR

ACCESSIBILITY CLAIMS

Approach• Stick core compliance

language into all IT contracts • Require vendors to submit

accessibility testing records• Have service vendors submit

testing results per organization’s testing plan

• Accessibility testing generates lots of records

• No records = no accessibility testing

Example Compliance Language

[CLIENT] expects that all vendors providing information technology products or services will provide [CLIENT] with deliverables that conform to the WCAG 2.0 AA requirements. [CLIENT] expects vendors to be able to define and deliver statements of compliance produced in accordance to a judicious, unbiased testing process as part of the procurement of the system. Statements of compliance must identify the overall compliance of the deliverable, as well as compliance of the system against each of the relevant WCAG provisions. To determine compliance with each of the provisions, a percentage can be calculated by dividing the number of tested items which do not contain violations of the guideline by the total number of items tested.

In addition [CLIENT] requires all vendors to be able to provide detailed testing records relating accessibility testing that has been performed on the system. These records must be submitted to the Accessibility Program Office for review as part of procurement and ongoing project conformance.

Example Compliance LanguageGive it teeth

VENDOR NOTES THAT FAILURE TO PROVIDE ACCURATE ACCESSIBILITY STATEMENTS WILL BE DEEMED A MATERIAL BREACH OF THIS CONTRACT AND WILL CAUSE FORFEITURE AND REFUND OF ALL SUMS PAID UNDER THE CONTRACT BY [CLIENT].

ANY BREACH OF THE ACCESSIBILITY CLAIMS MADE IN THIS CONTRACT OR FAILURE BY VENDOR TO PROVIDE ACCURATE CLAIMS IN A TIMELY FASHION WILL BE DEEMED CAUSE FOR [CLIENT] TO WITHOLD ANY OUTSTANDING PAYMENTS.

Or something that has a financial impact.

Accessibility Testing PlanAhh! So much text on this slide!

• How do we test internal stuff?

• How do we test vendor stuff?– VALIDATE VENDORS

CLAIMS• Different technology

platforms– Same testing approach– Different best practices

• Different use level – different testing approach– High use systems =

Detailed testing– Low use systems = Limited

testing• Central v. Distributed

Testing– Central testing = strong

governance, high expense– Distributed testing = weak

governance, lower costs

Accessibility Testing PlanValidation Requirements

Technical Requirements (§1194.21 | §1194.22)• Did we code it right?• Testing coverage

– Automatic (25%)– Manual (48%)– Global (27%)

• Automatic testing is cheap and commonly used but covers only a small fraction of legal requirements

Functional Requirements (§1194.31)• Can it be used by people with disabilities?

Support Requirements (§1194.41)• Is the whole thing accessible?

Accessibility Testing PlanCore Testing Methodology

Testing

ManualAutomated Global

Assistive Technology

IdentifyModules

IdentifyUse Cases

Groundwork

Prioritization

Analysis

Authoring

Delivery

Reporting

• At SSB we use a Unified Audit Methodology• One process for testing all technology platforms• Process should allow for different testing formality• Must be repeatable and scalable• Must provide concise remediation guidance• Require vendors to provide testing artifacts from the process

Accessibility Testing PlanTricky Parts

Manual Testing• Manual tests require

extensive subject matter expertise

• Manual tests are expensive• Formal audits are more

expensive

Functional Testing• Different versions of

assistive technologies, drastically different results

• Accurate testing results requires intimate knowledge of AT support and control

Accessibility Testing PlanTesting Responsibilities

General Approach

• General teams are responsible for small, targeted sub-set of requirements

• Accessibility Program Office is responsible for – Full scope testing– High risk system and component

testing• APO supported by third party

experts• Over time organization learns

more about accessibility organically versus in one disruptive and expensive push

Approach Considerations

• Accessibility program office must be developed and staffed

• For internal experts to be active they need to only be doing accessibility

• Approach requires a large amount of education and knowledge transfer for internal experts which takes a large amount of time

• Organizations may find it more effective to outsource some or all of the functions of the program office

Accessibility Testing PlanTesting Responsibilities

Team Accessibility Testing• Develop short list of core

accessibility issues for teams to test set at 90% coverage point– ~15 items

• Quick list is validated every sprint or development cycle on limited set of pages– Page test set is traffic

ordered pages and high risk transaction paths

– Test most common pages first

– Basic smoke test• Test full list every major release

Automatic Testing• Early and often• Automatic tests integrated into

functional testing system and build environment

• Addresses many low hanging fruit

• Gold standard of accessibility validation every check-in

• Good enough standard is validation of accessibility as part of regression functional test script execution

• As manual testing identifies automatically testable cases add to test definition for future automatic regression

Accessibility Testing PlanTesting Responsibilities

Functional Testing• Limit functional testing to end

cycle user acceptance testing– Note: If a product falls

under CVAA requirements user testing must occur throughout the development process

• Link limited functional testing to full review of products or systems

• Provide functional testing via users with disabilities

Training PlanRequirements

• Lots of technical standards• Accessibility issues have a

power law distribution• Small set of issue types cause

vast majority of issues • Issues recur across (a)

development teams and (b) industries

• Focus on “optimal compliance”

• Mix it up over time

Power Law Distribution

Violation NumberV

iola

tion

Cou

nt

Training PlanApproach

Target high value best practices• High severity• High frequency• High noticeability• Low tractability

Change it over time based • Monitoring data• Litigation• Legislation• Technology support• AT support

WebFlashPDFJavaWindowsHardware

Section 508WCAGDDAeEuropeNFB

LawsuitsLegislationTechnology

Organization Standard Training Content

Compliance Specification

Training PlanTraining Course Matrix

Role

Accessibility Concepts

Web Accessibility Overview

Web Accessibility Basics

Web Accessibility Advanced

Accessibility for Program and Project Management 

Accessibility Testing Methodologies

Mobile Accessibility for iOS

Mobile Accessibility for Android

Product Management                Product Manager x x     x      Business Discovery x x            Concept Definition x x     x      Risk Management x x x     x x x

Program and Project Management                Project Management x x     x      Program Management x x     x      Roadmap Management x x     x      Portfolio Operations and Reporting x x     x      

Design                Design x x x x     x xCustomer Experience x x x x     x x

Development                Front-end Development x x x x     x xArchitecture / Back-end Development x x x x     x x

Quality Assurance                Quality Assurance x x x     x x xUser Acceptance Testing x x       x    

Documentation                Document Specialists x x x          

Support                Support Representative x x            

Pilot ImplementationAccessibility Initiatives

• Try it on a site or application• Look to see what the issues are• Learn what policies are working• Update things accordingly• Accessibility is a process – not a project

What is an APO?

Responsible for accessibility

Core Activities• Policy Ownership

– Development, Updates, Communication

• Technical Help Desk• Accessibility Testing• Measurement and Tracking• Reporting• Coordination

• Policy Updates• Policy Communication• Compliance Reporting• Exception Review• Plan Review• Technology Monitoring• General QA Support• Regulatory Monitoring• Regulatory Help Desk• Regulatory Reporting• Process Improvement

Management

Where does APO sit?• Must have a specific place for accessibility in the org

structure• Often in compliance or user experience• We see:  (i) compliance, (ii) product or project management

or (iii) user experience / design

Management Sponsor• Somebody in management has to own accessibility• Signs up for accessibility metrics• Receives the report of the APO

Accessibility Council

An interdepartmental team relating to accessibility that represents the various stakeholder areas of the organization that will be impacted by accessibility.

• Facilitates progress on accessibility organization wide• Identifies issues or challenges • Works to address same• Solicits management in various different areas• Strong potential to diffuse responsibility

Next Steps

• Schedule some time to speak with an SSB expert in your industry

• Sign-up for a webinar covering further topics on Web Accessibility

• Take one of our online courses covering core Web Accessibility knowledge

• Sign-up for an online AMP training sessions

• Contact the industry expert to setup a free trial of AMP

Point of Contact

Tim Springer

tim.springer@ssbbartgroup.com

(415) 624-2705 (o)

Appendix A

Roles and Responsibilities

Product or Project Manager Roles and Responsibilities

• Assess business needs for accessibility based on market needs and risks

• Understand the scope of efforts required to implement compliance and include appropriate time and costs in investment plans

• Define accessibility investments• Manage vendor accessibility with Procurement and

Contracting• Develop corrective actions or programs for projects, products

and procured items that are non-compliant

DesignerRoles and Responsibilities

• Review and training on accessible design requirements• If a library of reusable UI components is maintained, ensure

the library components are accessible• Include consideration of accessibility needs in design

deliverables • Creation of accessible wireframes, palettes and templates• Coordinate with Accessibility Program Office to validate

design assets account for accessibility

DeveloperRoles and Responsibilities

• Implement user facing components in conformance with organization's Accessibility Standards

• Complete training and certification on accessibility requirements

• Review reports created by Quality Assurance or Accessibility Program Office and take action to fix open issues

• Coordinate with Quality Assurance and Accessibility Program Office to perform regression and unit testing on systems

• Consult with Accessibility Program Office on implementation ideas and approaches

• Build in accessibility unit tests

Quality Assurance SpecialistRoles and Responsibilities

• Perform limited accessibility testing on systems. • Coordinate with Accessibility Program Office on testing high-

risk system. • Review and be familiar with Accessibility testing checklist for

each platform• Perform regression testing on fixed items

Content CreatorsRoles and Responsibilities

• Access to a limited set of requirements for content. • Ability to be trained and certified on sub-set of accessibility

requirements.

Content EditorsRoles and Responsibilities

• Access to a full set of requirements relevant to the content. • Ability to be trained and certified on sub-set of accessibility

requirements. • Accessible documentation creation specialists.

DocumentationRoles and Responsibilities

• Coordinate with Accessibility Program Office to complete testing on accessibility of documentation.

• For each product or services that is covered develop an Accessibility Features document defining the accessibility features of that document.

• Ensure new documentation is developed in a fashion that conforms to the Accessibility Policy.

SupportRoles and Responsibilities

• Coordinate with Accessibility Program Office to complete testing on accessibility of support systems and process.

• Ensure new Support systems conform to the Accessibility Policy. – Coordinate with Procurement and Accessibility Program Office

on purchases, products and services. – Coordinate with Development and Accessibility Program Office

on internally developed systems.

Human ResourcesRoles and Responsibilities

• As needed, engaged the human resources department or team responsible for the employee facing policy on accessible ICT.

• Employees - Who is the point of contact for IT accessibility issues relating to employees? For example, the company intranet is non-compliant and a worker with a visual impairment cannot access information about the company.

• Job Seekers - Who is the point of contact for IT accessibility issues relating to job seekers? For example, the online application system of job descriptions are inaccessible.

Appendix B

Implementation Plan

Implementation PlanActivities

• Define the timeline, milestones, activities and staff required to implement the overall accessibility plan.

• Provide a detailed schedule that defines the individual activities of the work effort and any dependency of groupings amongst activities. For each activity, the plan will identify duration, location, participants, roles and responsibilities, milestones and dependencies amongst activities;

• Define staffing requirements and job descriptions for any additional full or partial staff required to successfully implement the plan;

• Define cost estimates for any investments required to implement the plan;

• Define a risk plan outlining potential projects risks and risk mitigation strategies; and

• Define a communication plan outlining the standard communication protocols, e-mail distribution lists and communication escrow polices for the project.

Implementation PlanActivities

• Allow for changes in the scope of activities at the direction of organization with a focus on ensuring high-risk sites are addressed with appropriate alacrity.

• Use scenario modeling to explore a variety of different scenarios for addressing accessibility across time and various different sites provided at organization. – (i) various different approaches to the

accessibility roll out – (ii) quantify the cost-to-benefit tradeoff

between the approaches. • Scenario modeling will provide

organization with a quantitative model for determining which roll out ensures best value for the institution while providing support for an increasing level of accessibility

• The various different activities will be prioritized using a risk and prioritization model specific to organization. This model will define (i) what priority should be given to addressing individual portions of the site and (ii) what priority should be assigned to addressing individual accessibility violations. The prioritization model for individual pages, courses and site portions will generally be based on the core use cases for systems and the traffic for individual pages.

Appendix C

Reference Procurement Language

Reference Documents

• Government Product/Service Accessibility Template for GPS Navigation Device– GPS-Navigation-Device-GPAT-1.doc

• Solicitation Language for GPS Navigation Device– GPS-Navigation-Device-language-2.doc