Section 508 Refresh Understanding the New Requirements Presented

Section 508 Refresh Understanding the New Requirements Presented by: Timothy Stephen Springer Chief Executive Officer

Introductions 2 | March 23, 2017

Who is this guy? • Co-founder and CEO of Level Access / SSB BART Group • Two decades in digital accessibility • Focus on enterprise level digital accessibility initiatives • Focus on a mix of software and services to “solve” the problem 3 | March 23, 2017

Who is Level Access? Formerly Known As SSB BART Group • New Corporate Identity – Name and Branding • New Website – Coming Spring 2017!! • No Change in our Innovative Technology or Excellent Service 4 | March 23, 2017

What are we trying to accomplish today? Objectives • Define key differences between the current Section 508 requirements and the Revised 508 Standards • Understand the proposed timeline for implementation • Understand the types of testing required to ensure compliance with the Revised 508 Standards 5 | March 23, 2017

What are we covering today? Agenda • Background – A quick background on Section 508 • Key Differences – What are the key differences between the current and revised Section 508 standards • Timeline – When does this all happen? • Standards • Technical standards for Information and Communication Technology (ICT) • Functional standards for ICT • Testing and Monitoring – How do we test and monitor this at scale? 6 | March 23, 2017

Background

Section 508 Overview • Requires Information and Communication Technology (ICT) developed, purchased, used, and maintained by the Federal government to be accessible to people with disabilities (29 U. S. C. § 794 d) • The United States Access Board issues the standards • Required for all US Federal government ICT • Standards Adopted as a best practice for procurement by most US public sector organizations (states) • Standards sometimes applied to programs using Federal funds (Section 504) HHS/CMS, Education, etc. 8 | March 23, 2017

Covered Technology Includes information technology and any equipment or interconnected system or subsystem of equipment, that is used in the creation, conversion, or duplication of data or information. Examples include • Telecommunications products (such as telephones, mobile phones), • Information kiosks and transaction machines, • World Wide Web sites • Electronic documents • Multimedia, and • Office equipment such as copiers and fax machines. 9 | March 23, 2017

Revised 508 Standards • Advance rulemaking process (2006 -2016) • Initiation of process in 2006 • Two ANPRMs (2010 and 2011) • Board finalized 9/14/2016, rule sent to OMB OIRA on 10/24/2016 • OMB cleared final rule on 01/05/2017 • Access Board published 01/09/2017 and conducted Public Meeting 01/10/2017 • Published in Federal Register on January 18 th, 2017 10 | March 23, 2017

Key Differences

General Themes • Moves focus to technical standards from functional standards • Product based approach based on ICT function • Functional performance criteria limited to specific situations • Safe harbor with conforming technical implementation? • Broad use of consensus based technical standards • Normalized to WCAG 2. 0 as base standard for web, electronic content and software • Harmonizes US with other international standards notably EN 301 549 • Define clear coverage for electronic content • Define AT interoperability requirements • Define requirements of authoring tools • Generally bring the standard up-to-date with the modern era 12 | March 1, 2017

Harmonization and Standards • Focus on voluntary international consensus standards for core technical requirements • Idea – Bigger accessibility market = better, more accessible solutions • Idea – One global accessibility standard • Harmonize with other web and electronic content standards (Australia, New Zealand, Canada, Japan, Germany, France) • Harmonize with international standards such as the European Union’s EN 301 -549 standard for public procurement of ICT • Ten referenced standards 13 | March 23, 2017

Electronic Documents – Public Facing • Arguably covered under the current standards but interpretations vary • All public-facing content covered • Internal “official agency business” covered • Content is broadly defined – includes agency websites, blog posts, social media sites, e-mails and the like • Official content posted on nonagency URL seems to be covered • Alternative can be provided for inaccessible third party content 14 | March 23, 2017

Electronic Documents – Not Public Facing • Agency Official Communication -- content includes the following: • An emergency notification; • An initial or final decision adjudicating an administrative claim or proceeding; • An internal or external program or policy announcement; • A notice of benefits, program eligibility, employment opportunity, or personnel action; • A formal acknowledgement or receipt; • A survey questionnaire; • A template or form; or • Educational or training materials. • Intranet web content designed • Narrow archival exception – can’t be publicly available 15 | March 23, 2017

Electronic Documents – Technical Standards • WCAG 2. 0 A and AA • Authoring tools also covered • If PDF export has option for PDF 1. 7 -PDF/UA must be supported. • A system that can generate covered content needs to support the generation of accessible content 16 | March 23, 2017

Interoperability Requirements • ICT must be interoperable or compatible with documented features of assistive technology and accessibility features • Applies to software, tools, and platforms • Not applicable to web apps – WCAG 2. 0 safe harbor • Would apply to mobile apps • Would apply to mobile hybrid apps • General focus: use operating system APIs and standard system accessibility functions when available 17 | March 23, 2017

Safe Harbor • Used, maintained, or procured unaltered & compliant before January 18, 2018 falls under the safe harbor for Section 508 • Safe harbor applies on a component/element basis • Altered includes change of UI, data, or interoperability • Security patch for web site that doesn’t change UI/data = not altered • Previously non-compliant ICT aren't covered under Safe Harbor • ICT under development but not yet used by January 18, 2018 does not fall under Safe harbor • Individual agencies still have flexibility in implementing and regulating revised Section 508 standard under Rehab Act • Current Section 508 standards still relevant – even after January 18, 2018 for evaluating existing non-updated ICT 18 | March 23, 2017

Documentation and Support • Product supporting documentation - notably product documentation - must now clearly conform to WCAG 2. 0 A & AA requirements • Exceptions for 4 WCAG SC – bypass blocks, multiple ways, consistent identification and consistent navigation • Includes web based service and support • Provide alternative formats for individuals that are blind or low vision on request • Only applies when non-electronic documentation is provided. • Provide overview of accessibility and compatibility features • Support services support the communication needs of people with disabilities 19 | March 23, 2017

Voluntary Product Accessibility Template • Beta VPAT 2. 0 introduced by ITI • Includes revised Section 508, WCAG 2. 0, and EN 301 -549 • Includes references between shared standards • Provided updated guidance on how to complete the document • Other non-federal public sector people seeking open VPAT type document as well • GSA has GPAT document that historically has been government requirements equivalent • Likely be updated and focus just on the Revised Section 508 standards • GPAT docs helped to clarify which standards were applicable for different product functions based on product type 20 | March 23, 2017

Likely Agency Technical Approach • Update checklist (document, web, software) • Most agencies have their own checklist breaking down what the standards mean • E. g. VA, DHS, HHS, SSA • Many checklists already incorporated some WCAG 2. 0 SC • Some agencies apply current software standards to web while others do not • Federal baseline includes 1194. 21(a), (c), (h) • Simplifies approach as same standards are applied across documents, web, and software • Checklist may be used in procurement process • For most non-hardware non-authoring tool content the focus will be support for WCAG 2 A/AA and conformance requirements 21 | March 23, 2017

Timeline

Timeline • Final rule approved by Access Board and Office of Management and Budget (OMB) • Published in the Federal Register on January 18 th, 2017 • Guidelines effective on March 21 st, 2017 • Original effective date was March 18 th, 2017 • White House reset effective date for in-flight regulations to 60 days from January 20 th • Memorandum for the Heads of Executive Departments and Agencies – “Regulatory Freeze Pending Review” • Regulations that were published in FR but not effective set to become effective on March 21 st • Compliance date unchanged - January 18, 2018 • Federal Acquisition Regulations (FAR) to be updated (anticipated during July 2017) • Address procurement requirements & date by Federal agencies’ • GSA to provide guidance on GPAT and other questions 23 | March 23, 2017

Standards Structure

Standards Structure • 36 CFR 1194. 1 – Standards for Section 508 of the Rehabilitation Act. • References Appendix A, C and D • Appendix A to Part 1194 • 508 Chapter 1: Application and Administration • E 101 General • E 102 Referenced Standards • E 103 Definitions • 508 Chapter 2: Scoping Requirements • • 25 | March 1, 2017 E 201 Application E 202 General Exceptions E 203 Access to Functionality E 204 Functional Performance Criteria E 205 Electronic Content E 206 Hardware E 207 Software E 208 Support Documentation and Services

Standards Structure Appendix C • Chapter 3: Functional Performance Criteria • 301 General • 302 Functional Performance Criteria • Chapter 4: Hardware • • • • 401 General 402 Closed Functionality 403 Biometrics 404 Preservation of Information Provided for Accessibility 405 Privacy 406 Standard Connections 407 Operable Parts 408 Display Screens 409 Status Indicators 410 Color Coding 411 Audible Signals 412 ICT with Two-Way Communication 413 Closed Caption Processing Technologies 414 Audio Description Processing Technologies 415 User Controls for Captions and Audio Descriptions • Chapter 5: Software • 501 General • 502 Interoperability with Assistive Technology • 503 Applications • 504 Authoring Tools • Chapter 6: Support Documentation and Services • 601 General • 602 Support Documentation • 603 Support Services • Chapter 7: Referenced Standards • 701 General • 702 Incorporation by Reference 26 | March 1, 2017

Requirements Technical • Defined in Chapters 4 - 7 of Appendix C • Primary method of determining compliance • Theoretical safe harbor for products that are technically compliant but not usable by people with disabilities • Practically unlikely to be the case • In practice should make conformance easier to validate 27 | March 1, 2017 Functional Performance • Defined in Chapters 3 of Appendix C • Only applies in situations where: • A technical requirement does not exist to address the situation • When testing equivalent facilitation claims • Remaining functional performance criteria tweaked for clarity • Added a cognitive functional performance requirement

Hardware Requirements Chapter Four • “A tangible device, equipment, or physical component of ICT, such as telephones, computers, multifunction copy machines, and keyboards” • Requirements • • • Speech output Volume control Displayed text Biometrics Pass-through of accessibility information 28 | March 1, 2017 • • • Flashing limitation Standard Connections Operable Parts Display Screens Transactional Outputs Two-Way Voice Communication • Closed Caption Processing Technologies • Audio Description Processing Technology • User Controls for Captions and Audio Description

Software Requirements Chapter Five • “Programs, procedures, rules, and related data and documentation that direct the use and operation of ICT and instruct it to perform a given task or function. Software includes, but is not limited to, applications, non-Web software, and platform software. ” • Web = WCAG 2. 0 AA • “Level A and Level AA Success Criteria and all Conformance Requirements” • Native • WCAG 2. 0 AA as applied to native applications and platforms • Respect platform accessibility settings • Non-disruption • Support for user settings of color, contrast, font type, font size, and focus cursor 29 | March 1, 2017

Support Documentation Chapter Six • “Where an agency provides support documentation or services for ICT, such documentation and services shall conform to the requirements in Chapter 6” • Must provide a list of accessibility and compatibility features • If content is provided in electronic format must conform to WCAG 2. 0 A & AA requirements • If content is provided in non-electronic formats must be provided on request 30 | March 1, 2017

Support Services • Examples - Help desks, call centers, training services, and automated self-service technical support • Required to provide information on accessibility and compatibility features • Support the communication needs of people with disabilities • Direct or indirect support models are okay • Unclear if this requires support services to be directly accessible 31 | March 1, 2017

Standards Technical

Technical Standards • Assuming this audience is broadly familiar with WCAG 2. 0 AA • We will highlight differences between current 508 approach and that standard • More information on difference between current 508 standards and WCAG 2. 0 AA • https: //www. access-board. gov/guidelines-andstandards/communications-and-it/about-the-ictrefresh/background/comparison-table-of-wcag 2 -toexisting-508 -standards 33 | March 23, 2017

Standards in current Section 508 not in/ different from WCAG 2. 0 Section 508 1194. 22 Web WCAG 2 Level A/AA Comments Twice per second flashing limit – no exception for size. Allows for flashing in the range from 56 -59 times per seconds WCAG’s is 3 times per second also allows for small areas to contain flashing content. Practically equivalent Require that documents are readable without associated style sheets Only requires that content is in a meaningful sequence More flexibility Requires that embedded and linked non-HTML media provide a link to an accessible plug-in 34 | March 23, 2017 Most agencies will likely still Indicates that the technology be providing links to plug-ins relied upon for conformance – if not on every page on are accessibility supported. some general page

Standards in current Section 508 not in/ different from WCAG 2. 0 (cont. ) Section 508 1194. 22 Web WCAG 2 Level A/AA Comments Requires that alternative pages are not used unless cannot be made accessible WCAG allows for alternative pages to be used but has no bar to determine when or where they are not allowed Unclear how strictly this was followed previously. Could be addressed by agency requirements. In our experience most US Federal agencies require that link text is meaningful when taken out of context even though it’s not explicitly in Section 508. WCAG AA allows for it to be understood in context. Out of context is a WCAG AAA requirement. Some agencies will likely want to address this in their checklists. 35 | March 23, 2017

Applicability of WCAG 2. 1 • WCAG 2. 1 FPWD just published (Tuesday 2/28/17) • 28 Proposed SC target mobile, low vision, and cognitive, e. g. • Touch target size • Gesture with assistive technology • Accidental activation • Conformance with WCAG 2. 1 means conformance w/ WCAG 2. 0 • WCAG 2. 1 would not be required by revised standards unless included by reference by the US Access Board • Process for inclusion would be straightforward due to the way the standards are referenced 36 | March 23, 2017

Applying WCAG Conformance and functional requirements • Key take away for electronic content, web, software, documents, use WCAG 2. 0 Level A and AA • Also includes WCAG Conformance Requirements • Compliance-Level, Full-Page, Complete process, Accessibility Supported, and non-interference (guidance on alternatives) • Applies to non-web docs & software (desktop or mobile) through lens of Guidance for applying WCAG to non-web ICT document • 4 primary exceptions (multiple ways, bypass blocks, consistent navigation, & consistent navigation) some differences such as set of documents rather than set of pages. • Keyboard interface support is required even for mobile • Don’t actually have to make a formal WCAG conformance claim • Examine sufficient techniques and documented failures 37 | March 23, 2017

Standards Functional

Functional Performance Criteria • Functional performance requirements only apply in situations where: • A technology standard/guideline does not exist to address the situation • As an equivalent manner to meet the standards when a technique standard cannot be met • Theoretically a safe harbor for products that are technically compliant but not usable by people with disabilities • Practically unlikely to be the case • Remaining functional performance criteria tweaked for clarity • E. g. With Limited Vision. Where a visual mode of operation is provided, ICT shall provide at least one mode of operation that enables users to make use of limited vision. 39 | March 23, 2017

Functional Performance Criteria New Criteria • Without Perception of Color. Where a visual mode of operation is provided, ICT shall provide at least one visual mode of operation that does not require user perception of color. • With Limited Manipulation. Where a manual mode of operation is provided, ICT shall provide at least one mode of operation that does not require fine motor control or simultaneous manual operations. • With Limited Reach and Strength. Where a manual mode of operation is provided, ICT shall provide at least one mode of operation that is operable with limited reach and limited strength. • With Limited Language, Cognitive, and Learning Abilities. ICT shall provide features making its use by individuals with limited cognitive, language, and learning abilities simpler and easier 40 | March 23, 2017

Testing and Monitoring

Testing Approach Types of Testing • Technical Testing • Automated • Stuff a computer can test • 25% testing coverage • Manual • Stuff a person needs to test • 75% testing coverage • Functional Testing • End-to-end use of the system • Does it work for people with disabilities? 42 | March 23, 2017

Testing Approach Example Testing Tools • Automated, Manual and Functional Testing Accessibility Management Platform (AMP) • Manual Testing - Color Contrast Checker • Manual Testing Inspect 32 • Functional Testing JAWS Screen Reader 43 | March 23, 2017

A quick detour Accessibility APIs 44 | March 23, 2017

Key Accessibility APIs • Microsoft Active Accessibility (MSAA) • MSAA is a set of Component Object Model (COM) interfaces and API elements that provides a reliable way to expose and collect information about Microsoft Windows-based UI elements and web content 45 | March 23, 2017 • Microsoft UI Automation (UIA) • Application programming interface (API) that allows one to access, identify, and manipulate the user interface (UI) elements of another application. UIA is targeted at providing UI accessibility and it is a successor to MSAA

Underappreciated Testing Tool Inspect 32 • Bundled with the accessibility API SDK • Allows you to see exactly what is exported to assistive technology • Amazingly helpful in diagnosing where things are going wrong 46 | March 23, 2017

Testing Approach Technical Testing Automated Testing • Common Approaches • Put in a URL – diagnose a page or scan a site • Diagnose a single page in the browser • Launch a unit test • Review the results • Fix the valid issues • Be wary of false positives! • Tends to be a development time activity 47 | March 23, 2017 Manual Testing • Diagnose a page in the browser based testing environment (toolbar) • Open a page in the browser using manual code review • Run through the manual checklist • Ideally integrated into your browser based testing environment • Log any issues into the relevant system of record • Tends to be a QA time activity

Testing Approach Functional Testing 1. Define use cases 2. Assign use cases to people with disabilities using representative assistive technologies 3. Have the users execute the use cases 1. Note what works 2. Note what doesn’t work 3. Score the task and overall experience 4. (Fix the stuff that doesn’t work) 48 | March 23, 2017

Qualitative Functional Tests What Should You Test? • Consistency throughout application • Keyboard operability • ARIA landmarks • Heading structure • Grouping relevant items • Graphics • Forms 49 | March 23, 2017

Questions? 50 | March 23, 2017

Contact Information Tim Springer Chief Executive Officer tim. springer@ssbbartgroup. com Follow @SSBBARTGroup linkedin. com/company/ SSB-BART-Group facebook. com/ SSBBARTGroup. com/blog 51 | March 23, 2017

Resources • Web Content Accessibility Guidelines (WCAG) 2. 0 • https: //www. w 3. org/TR/WCAG 20/ • Guidance on applying WCAG to Non-Web ICT • https: //www. w 3. org/TR/wcag 2 ict/ • Comparison Table of WCAG 2. 0 to Existing 508 Standards • https: //www. access-board. gov/guidelines-andstandards/communications-and-it/about-the-ictrefresh/background/comparison-table-of-wcag 2 -to-existing-508 standards • Understanding WCAG 2. 0 • https: //www. w 3. org/TR/UNDERSTANDING-WCAG 20/Overview. html • Techniques for WCAG 2. 0 • https: //www. w 3. org/TR/WCAG 20 -TECHS/Overview. html#contents • VPAT Beta 2. 0 • https: //www. itic. org/policy/accessibility/ 52 | March 23, 2017