1. Presented by: James Griffith Information Systems Architect, HPE Date: April 12, 2016 Section 508 and Accessibility Testing for Open Source This presentation and overview of aDesigner was prepared by James Griffith in his personal capacity. The opinions expressed in this article are the author's own and do not reflect the view of Hewlett Packard Enterprise or the Medical Assistance Provider Incentive Repository (MAPIR) multi-state collaborative.

2. The Government Services Administration (GSA) has published a PowerPoint deck that provides a high level overview of Section 508 from a Federal Policy Standpoint: http://www.section508.gov/content/508presentations http://www.section508.gov/content/508presentations The GSA also maintains a voluntary listing of U.S. State and Territory policies. Such policies are typically based on Section 508 but may also introduce unique stipulations: http://www.section508.gov/content/learn/laws-and-policies/state- policy http://www.section508.gov/content/learn/laws-and-policies/state- policy The Voluntary Product Accessibility Template (VPAT) is a Word based tool that may be optionally used to voluntarily document the accessibility capabilities of a product. For further information: http://section508.gov/content/sell/vpat http://section508.gov/content/sell/vpat http://www.itic.org/policy/accessibility/ Section 508 of the Rehabilitation Act 2

3. The following recommendations are based on my own combination of personal project experience, academic training, and informal research in this area: Define a policy that specifies the testing limitations of the supporting Open Source effort and the compliance responsibilities of downloading parties, along with any appropriate disclaimers. Perform accessibility testing at the level of Federal Section 508/ADA standards. Publish the methodology and testing results as part of release distributions (possibly based on the VPAT template described on the previous slide). – States and other third parties are then able to reference these materials when performing their own regional or localized accessibility testing. Accessibility Testing Recommendations for Open Source 3

4. Test all website screens for accessibility. Categorize test results according to severity (i.e. “green/yellow/red”): – Red: Corrections must be made and the resolution must be documented. In cases where the issue cannot be resolved immediately, document the status and track until resolved. – Yellow: Evaluation must be performed to determine if corrections are necessary. In majority of cases yellow items must be corrected. – Green: Items must be reviewed and optionally corrected. Remediate as determined based on analysis of the results. Repeat the accessibility testing to capture “after” results. Publish initial findings, rationale, remediation, and outcomes as part of release documentation. As part of implementation activities, downloading parties perform accessibility testing in accordance with applicable regulatory and contractual requirements. Generic Example of a Testing Approach 4

5. ACTF aDesigner for Eclipse (http://www.eclipse.org/actf/downloads/tools/aDesigner/)http://www.eclipse.org/actf/downloads/tools/aDesigner/ Examples of Free Testing Tools 5 ACTF aDesigner is an application that can be used to simulate visibility impairments. The tool provides detailed reports with recommendations. The application simulates “Blind Usability”, which approximates the content that would be fed by each page to a Screen Reader, and “Low Vision”, used to simulate the effects of certain types of color blindness.

6. WAVE Accessibility Toolbar (http://wave.webaim.org/extension/)http://wave.webaim.org/extension/ Examples of Free Testing Tools 6 The WAVE Accessibility toolbar is a Chrome extension that makes it possible to evaluate accessibility issues for a page. The toolbar is maintained by Utah State University’s Center for Persons with Disabilities: http://webaim.org/

7. Questions?