Making Valid Compliance Claims VPATS, GPATs, Conformance Claims and More! Tim Springer Matt Arana

1. Making Valid Compliance Claims VPATS, GPATs, Conformance Claims and More! Tim Springer Matt Arana

2. Agenda • About SSB • Auditing Constraints • Methodology • Process Questions • Report Review • Pricing

3. About SSB BART Group • Unmatched Experience • Accessibility Focus • Implementation-Oriented Solutions • Solutions That Reduce Legal Risk • Organizational Stability and Continuity • Knowledge That Is Up-to-Date, All the Time • Published and Peer Review Auditing Methodology • Fourteen hundred organizations(1445) • Fifteen hundred individual accessibility best practices (1595) • Twenty-two core technology platforms (22) • Fifty-five thousand audits (55,930) • One hundred fifty million accessibility violations (152,351,725) • Three hundred sixty-six thousand human validated accessibility violations (366,096)

4. Introduction What is a compliance claim? An official statement of compliance of [SOMETHING] with a [STANDARD/GUIDELINE] In digital accessibility we are principally concerned with Section 508 and FCC standards and the WCAG 2.0 EU M 376 standard - EN 301 549 – is likely to be a rising need as well Section 508 does not currently define a conformance claims process WCAG has a conformance claim process EN 301 549 likely to be specific to needs of procurement

5. Introduction When are compliance claims made? Procurement - When organizations want to buy products Regulatory - When regulations or regulatory bodies require it Litigation - When an organization is getting sued, trying to avoid it or working on a settlement Causes for concern Often made without much substance supporting the claim • Product manager creates a VPAT responding to a solicitation Digital accessibility is an inherently nebulous space If we make structured claims it would be nice if they were true • Or at least defensible

6. Laws, Standards and Guidelines WCAG (International) The World Wide Web Consortium (W3C) publishes the Web Content Accessibility Guidelines (WCAG) The WCAG has two versions 1.0 (1999) and 2.0 (2009) These form the basis of most Web accessibility standards including Section 508 Section 508 (U.S.) The current Section 508 standards are based on the WCAG 1.0 standards but are structured around technical, functional and support requirements The Section 508 Refresh standards soon to be in NPRM state • Currently being reviewed by OMB • Publication date after OMB review • OMB review must be completed on or before 5/24/2014 • Section 508 Refresh expected to closely align with WCAG 2.0

7. Laws, Standards and Guidelines CVAA (U.S.) • Requires communication and video that go over the Internet to be accessible • Primarily targeted at communications software and equipment manufacturers, video service providers and producers of video content ADA (U.S.) • U.S. civil rights law • Application to IT is tricky • Employment implications • Service provider implications • Site operator implications • Non-Federal public sector impact

8. Scope of Coverage Electronic and Information Technology (EIT) • Section 508 – All EIT • ADA – Public and employee facing EIT • CVAA – Communications and video EIT • May also see Information and Communication Technology (ICT) used Digital “stuff” - if it has to do with 1s and 0s its may be impacted Examples • Web sites • Web applications • Software applications • Operating systems • Mobile applications • Computers – Desktops, laptops, tablets • Multifunction devices – Scanners, printers • Kiosks - Information kiosks, ticketing machines, ATMs • Phones – Fixed line, VOIP, Mobile • Telecom products and services – Faxes • Telecom services – Phones, voicemail • Video and Multimedia • Electronic documents • Online communication services

9. VPATs What is VPAT? VPAT® is the Voluntary Product Accessibility Template® As noted by judicious use of ® - VPAT is a registered trademark of the Information Technology Industry Counsel (ITIC) Summarize a product’s compliance level against the technical, functional, and support requirements of Section 508 Currently at version 1.3 Download from the ITIC Accessibility Policy page

10. VPATs Why is a VPAT needed? Many US Federal Government agencies require a VPAT as part of their procurement process Over half of US State Governments have Section 508-like requirements and may also require VPATs Private sector organizations are increasingly requesting some form of compliance documentation • Most private sector companies have moved to WCAG 2.0 requirements • U.S. Federal will likely follow with Section 508 Refresh

11. GPAT What is a GPAT? A Government Product (or Service) Accessibility Template (GPAT) Helps Federal contracting and procurement officials in fulfilling the Section 508 market research requirements Intent – include a GPAT in solicitations and have vendors fill it out • GSA quick links provides GPAT formats for procurement types • BuyAccessible Wizard can generate them de novo

12. VPATs and GPATs The government may accept a VPAT in lieu of a GPAT While formatted differently they contain materially the same information Fundamentally a firm is showing how they claim compliance

13. VPAT Content VPAT Structure r Impact Filing Data • Date • Product Name • Contact Information • Company Name • Contact Name • Contact Telephone Overview Content • Overview • General Compliance Overview • Compliance Initiative • Summary Table Detail Tables • Standard Text • Supporting Features • Remarks and Explanations

14. GPAT Content VPAT Structure r Impact Overview Content • Standard Text • # Applicable Provisions • Notes • Total Supported Provisions • Full, Partial, Not • Notes Detail Tables • Standard Text - The full text of the Section 508 item • Applicability – Yes / no – does this provision apply • Explanation – How does this apply? Notes on application. • Status – Fully, Partially, Not, N/A • Notes and Explanation

15. WCAG Conformance Claim • Conformance claim against WCAG 2.0 • For page or group of pages Components • Date • Guidelines Title, Version and URI • Conformance Level – A, AA, AAA • Set of Pages – What is covered? • Technology – What technology is used?

16. What do they look like? Example VPAT for SSB’s AMP • https://amp.ssbbartgroup.com/amp_vpat.php Example GPAT for a system • http://app.buyaccessible.gov/baw/Quick-Links/index.jsp Example Conformance Claim • https://bigreddesign.com/wcag2-conformance-claim/

17. Statement Creation VPATs / GPATs / WCAG Conformance Statements are formal statements of compliance by an organization Based on contract and regulatory language inaccurate claims of compliance may result in penalties or award invalidation Compliance claims should be developed by an individual who has knowledge of the relevant system andaccessibility Compliance claims should be backed by an audit trail Compliance claims should be well justified based on the demonstrable accessibility of your system

18. Auditing Requirements Requirements for Compliance Auditing Technical Requirements (§1194.21 -§1194.26) Requires a system to have a conformant technical implementation Testing requirements are split between those that can be tested Automatically (24.8%), Manually (48.3%) and Globally (26.9%) Automatic testing is the cheapest and most common testing but covers only a small fraction of legal requirements Functional Requirements (§1194.31) Requires a system to be usable to people with disabilities using current assistive technologies Functional testing coverage for sensory and mobility impairments is generally required Support Requirements (§1194.41) Requires a system to be accessible in deployment

19. Auditing Constraints Technical Testing Manual tests require extensive subject matter expertise • Many require the use of assistive technologies, API monitoring tools or other complex techniques to validate a best practice • Many require judgment calls on the part of the tester to determine if an item meets the spirit and letter of a requirement • The expertise required to make these determinations is significant • SSB recommends setting aside four hundred and eighty hours of tester time solely to become familiar with accessibility validation • Knowledge maintenance generally requires about one month of research and review per year Manual tests are expensive • WCAG A and AA conformance requires testing 177 best practices out of the box of which 133 are manual tests • Validating all 133 best practices across twenty modules (pages) would require 2655 test executions. If we assume thirty seconds per test that translates to twenty-two hours of manual testing per test cycle Formal audits are expensive and time consuming • Performing full formal audits each QA cycle is cost and time prohibitive • Perform full audits at specific gateways – use informal testing the majority of the time

20. Auditing Constraints Functional Testing Different versions of assistive technologies, drastically different results • Assistive technology support for web technologies changes drastically from version to version • Determining if the issue is an issue in the AT or an issue of operator error is significant • Signal to noise for false positive and negatives is significant – often exceeding the actual count of valid bugs • Accurate testing results require intimate knowledge of AT support and control Accurate functional testing requires a user with disabilities • User must have a high degree of familiarity with assistive technology • Accurate testing with a screen reader requires that the user: • Never see the page • Never use the mouse • Only control page elements through the screen reader and relevant reading modes • In practice SSB has never seen users without disabilities effectively test in a fashion that provides a meaningful simulation of the experience of a user with a disability

21. Audit Approach Technical and Functional Testing Approach r Impact Technical Testing Break down each section into best practices 1194.22 (a) is covered by 42 best practices Each of those best practices, in turn, are classified based on how they are tested Determine a sample set of application components or pages Test each component against relevant set of best practices Functional Testing Test with Assistive Technologies JAWS, ZoomText, Dragon NaturallySpeaking

22. Testing Audit Model Audits SSB uses a Unified Audit Methodology – a single method to create and deploy audits Benefits A single, unified process for auditing all technology platforms Ability to have third party or in house auditing capacity Testing coverage for full compliance requirements Repeatable and scalable testing methodology Code level remediation guidance Independent validation and verification of compliance Creation of custom VPAT, GPAT, Conformance Claim or “Supports Statement” Creation of recordkeeping components for CVAA covered products and services • Groundwork • Reporting Analysis Identify Modules Automated Global Manual Prioritization Authoring Identify Use Cases Assistive Technology Delivery

23. Scoring Claims Technical Items Review the current compliance score Determine the level of compliance for a given paragraph • Full / Supports - Product has a 90% or greater compliance with the relevant paragraph • Partial / Supports with Exceptions – Product has 50 - 90% compliance • Not Supported / Does not Support – Product has less than 50% compliance with the relevant paragraph • Not Applicable – Relevant mode of operation is not impacted by the product Not Applicable or Supports?

24. Scoring Claims Functional Items Review use case scores or auditing with the relevant AT Determine level of compliance for a given paragraph • Full / Supports – 90% or greater compliance with relevant paragraph • All use cases passed with scores of three, four, or five • At least 50% of use cases passed with scores of four or five • Partial / Supports with Exceptions – 50 - 90% compliance with relevant paragraph • All use cases passed with scores of three or above • Not Supported / Does not Support – Less than 50% compliance with relevant paragraph • Any use case scored a one or two • Not Applicable – Relevant mode of operation is not impacted by the product • Note the specific areas of compliance and non-compliance and versions of assistive technology tested

25. Compliance Claim Notes Assign a qualified person or use a qualified third party to audit the application and develop the claim Perform an audit against all relevant accessibility requirements – technical, functional, and support Record the results Review the general support levels and ensure they have been properly set Review individual notes and extend detailed descriptions of the issues to relate to the features provided by a product or system Document the compliance level of the application in the conformance claim

26. Appendix A Additional Information

27. Procurement Process The ideal Based on the need for a procurement, the officer: Researches available market solutions Determines which is most compliant Selects the product which provides the best value weighing compliance Documents the level of compliance found in the research Submits the procurement

28. Procurement Process Reality Procurement takes either or both routes Internal Validation Agency will do testing for compliance Testing often independent of vendors claims Agency will handle their own testing reports and escrow External Validation Agency will request VPAT VPAT will be construed as statement of compliance

29. Procurement Process Compliance Validation General Vendor Statement • Voluntary Product Accessibility Template (VPAT) Procurement Specific Validation • Government Product Accessibility Template (GPAT) External Validation • Third party audit • Third party VPAT and compliance statement • Certification Evaluation Databases • Section508.gov Buy Accessible database

30. VPAT Request Process When a customer requests a VPAT, get the most up-to-date copy Process • Request VPAT from Marketing Manager • If VPAT is on file it is sent out • If VPAT is not on file create it based on an assessment of the application

31. VPAT Creation Applicable 508 Requirements for VPAT Software 194.21, 1194.31, 1194.41 Web Sites and Applications 1194.22, 1194.31, 1194.41 Flash/Flex Applications 1194.21, 1194.22, 1194.31, 1194.41 PDF 1194.21, 1194.22, 1194.31, 1194.41 Hardware 194.25, 1194.31, 1194.41

32. VPAT Creation Support Levels r Impact • Supports – When you determine the product fully meets the letter and intent of the Criteria • Supports with Exceptions – When you determine the product does not fully meet the letter and intent of the Criteria, but provides some level of access relative to the Criteria • Supports through Equivalent Facilitation – When you have identified an alternate way to meet the intent of the Criteria or when the product does not fully meet the intent of the Criteria • Supports when combined with Compatible AT – When you determine the product fully meets the letter and intent of the Criteria when used in combination with Compatible AT

33. VPAT Creation Support Levels r Impact Does not Support – When you determine the product does not meet the letter or intent of the Criteria Not Applicable – When you determine that the Criteria does not apply to the specific product Not Applicable: Fundamental Alteration Exception Applies – When you determine a Fundamental Alteration of the product would be required to meet the Criteria (see the Access Board standards for the definition of "fundamental alteration")

34. VPAT Creation Support Levels r Impact

35. Unit 3: VPAT Creation Paragraph Review – Example Bad Example

36. Unit 3: VPAT Creation Paragraph Review – Example (cont.) Good example

37. Resources http://www.access-board.gov/508.htm http://www.section508.gov/section-508-standards-guide https://www.ssbbartgroup.com/services/audit/vpat_creation.php https://amp.ssbbartgroup.com https://reference.ssbbartgroup.com

38. Questions?

39. Thank You Contact Us Tim Springer CEO tim.springer@ssbbartgroup.com Matt Arana Account Manager matt.arana@ssbbartgroup.com SSB Contact Information info@ssbbartgroup.com (800) 889-9659 Follow Us Twitter @SSBBARTGroup LinkedIn www.linkedin.com/company/ssb-bart-group Facebook www.facebook.com/ssbbartgroup Blog www.ssbbartgroup.com/blog