Presentation on theme: "End the Madness - Section 508 Compliance in the Enterprise."— Presentation transcript:
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 Policy Round One Technical Standards – 508 v. WCAG Scope – Whats 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 Policy Round Two Non-compliance What happens if we dont comply? (Often nothing…) Supported AT What assistive technologies do we support? Vendors How do we address this with vendors?
Monitoring Plan Accessibility 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 vendors 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 organizations 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 Language Give 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 Plan Ahh! 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 Plan Validation Requirements Technical Requirements (§ | § ) 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 (§ ) Can it be used by people with disabilities? Support Requirements (§ ) Is the whole thing accessible?
Accessibility Testing Plan Core Testing Methodology Testing ManualAutomatedGlobal Assistive Technology Identify Modules Identify Use 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 Plan Tricky 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 Plan Testing 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 Plan Testing 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 Plan Testing 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 Plan Requirements 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 Number Violation Count
Training Plan Approach 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 Web Flash PDF Java Windows Hardware Section 508 WCAG DDA eEurope NFB Lawsuits Legislation Technology Organization Standard Training Content Compliance Specification
Training Plan Training Course Matrix Role Accessibility Concepts Web Accessibility Overview Web Accessibility Basics Web Accessibility Advanced Accessibility for Program and Project Management Accessibility Testing Methodologi es Mobile Accessibility for iOS Mobile Accessibility for Android Product Management Product Managerxx x Business Discoveryxx Concept Definitionxx x Risk Managementxxx xxx Program and Project Management Project Managementxx x Program Managementxx x Roadmap Managementxx x Portfolio Operations and Reportingxx x Design xxxx xx Customer Experiencexxxx xx Development Front-end Developmentxxxx xx Architecture / Back-end Developmentxxxx xx Quality Assurance xxx xxx User Acceptance Testingxx x Documentation Document Specialistsxxx Support Support Representativexx
Pilot Implementation Accessibility 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 (415) (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
Designer Roles 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
Developer Roles 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 Specialist Roles 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 Creators Roles and Responsibilities Access to a limited set of requirements for content. Ability to be trained and certified on sub-set of accessibility requirements.
Content Editors Roles 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.
Documentation Roles 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.
Support Roles 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 Resources Roles 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
Activities 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, distribution lists and communication escrow polices for the project.
Implementation Plan Activities 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